fix(browser): auto-start configured browser plugin

This commit is contained in:
Peter Steinberger
2026-04-27 09:36:58 +01:00
parent e792f96a84
commit f97cc58760
15 changed files with 259 additions and 23 deletions

View File

@@ -85,8 +85,8 @@ Notes:
If `openclaw browser` is an unknown command, check `plugins.allow` in
`~/.openclaw/openclaw.json`.
When `plugins.allow` is present, the bundled browser plugin must be listed
explicitly:
When `plugins.allow` is present, list the bundled browser plugin explicitly
unless the config already has a root `browser` block:
```json5
{
@@ -96,8 +96,9 @@ explicitly:
}
```
`browser.enabled=true` does not restore the CLI subcommand when the plugin
allowlist excludes `browser`.
An explicit root `browser` block, for example `browser.enabled=true` or
`browser.profiles.<name>`, also activates the bundled browser plugin under a
restrictive plugin allowlist.
Related: [Browser tool](/tools/browser#missing-browser-command-or-tool)

View File

@@ -249,6 +249,7 @@ change correctness while legacy manifest ownership fallbacks still exist.
"onCommands": ["models"],
"onChannels": ["web"],
"onRoutes": ["gateway-webhook"],
"onConfigPaths": ["browser"],
"onCapabilities": ["provider", "tool"]
}
}
@@ -261,6 +262,7 @@ change correctness while legacy manifest ownership fallbacks still exist.
| `onCommands` | No | `string[]` | Command ids that should include this plugin in activation/load plans. |
| `onChannels` | No | `string[]` | Channel ids that should include this plugin in activation/load plans. |
| `onRoutes` | No | `string[]` | Route kinds that should include this plugin in activation/load plans. |
| `onConfigPaths` | No | `string[]` | Root-relative config paths that should include this plugin in startup/load plans when the path is present and not explicitly disabled. |
| `onCapabilities` | No | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Broad capability hints used by control-plane activation planning. Prefer narrower fields when possible. |
Current live consumers:
@@ -271,6 +273,8 @@ Current live consumers:
embedded harnesses and top-level `cliBackends[]` for CLI runtime aliases
- channel-triggered setup/channel planning falls back to legacy `channels[]`
ownership when explicit channel activation metadata is missing
- startup plugin planning uses `activation.onConfigPaths` for non-channel root
config surfaces such as the bundled browser plugin's `browser` block
- provider-triggered setup/runtime planning falls back to legacy
`providers[]` and top-level `cliBackends[]` ownership when explicit provider
activation metadata is missing

View File

@@ -104,7 +104,7 @@ turns do not pay the full token cost.
## Missing browser command or tool
If `openclaw browser` is unknown after an upgrade, `browser.request` is missing, or the agent reports the browser tool as unavailable, the usual cause is a `plugins.allow` list that omits `browser`. Add it:
If `openclaw browser` is unknown after an upgrade, `browser.request` is missing, or the agent reports the browser tool as unavailable, the usual cause is a `plugins.allow` list that omits `browser` and no root `browser` config block exists. Add it:
```json5
{
@@ -114,7 +114,7 @@ If `openclaw browser` is unknown after an upgrade, `browser.request` is missing,
}
```
`browser.enabled=true`, `plugins.entries.browser.enabled=true`, and `tools.alsoAllow: ["browser"]` do not substitute for allowlist membership the allowlist gates plugin loading, and tool policy only runs after load. Removing `plugins.allow` entirely also restores the default.
An explicit root `browser` block, for example `browser.enabled=true` or `browser.profiles.<name>`, activates the bundled browser plugin even under a restrictive `plugins.allow`, matching channel config behavior. `plugins.entries.browser.enabled=true` and `tools.alsoAllow: ["browser"]` do not substitute for allowlist membership by themselves. Removing `plugins.allow` entirely also restores the default.
## Profiles: `openclaw` vs `user`