no browser tool even though openclaw browser status is ok

[half fable]

My openclaw agent says there is no browser available. openclaw browser status outputs:

enabled: true
running: true
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: custom
detectedPath: /usr/bin/google-chrome-stable
headless: false (default)
profileColor: #FF4500```

but when I ask my agent, it says this: 

Still no browser tool available. Here's what I have right now:

**read, write, edit, exec, process, web_search, web_fetch, cron, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status, image, image_generate, memory_get, memory_search, music_generate, update_plan, video_generate**

No dedicated browser tool. If you're trying to set one up, the browser-automation skill has instructions — I can read through it for you. Otherwise, **web_fetch** handles basic URL fetching, and **exec** could run something like `curl` or a headless browser if needed.

What's the goal?

[alpine herald]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[west adder]

That status means the browser service itself is up. The missing piece is probably tool policy, not Chrome/CDP.

Your agent’s tool list looks exactly like the default tools.profile: "coding" set: it includes runtime/fs/web/sessions/media, but not group:ui, and browser lives in group:ui.

First, please grab the version since this area has changed a bit:

openclaw --version

Then check your tool/plugin config:

openclaw config get tools
openclaw config get plugins

[west adder]

Likely fix if you’re using tools.profile: "coding":

openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart

If you already have tools.allow set, don’t also set tools.alsoAllow; add browser or group:ui to the existing tools.allow list instead.

One more check: if you have a plugins.allow list, it must include "browser". Since openclaw browser status works, the plugin is probably loading already, but this is still worth checking:

{
  plugins: {
    allow: ["browser"]
  }

[west adder]

}

Docs:
https://docs.openclaw.ai/tools/browser#missing-browser-command-or-tool
https://docs.openclaw.ai/tools#tool-configuration

[half fable]

what are the valid tools.profile values? and how do I set that?

[west adder]

Valid tools.profile values are:

• minimal - basically session_status only
• coding - fs/runtime/web/sessions/memory/media/cron, but not browser/canvas
• messaging - message + session tools
• full - unrestricted / same as unset

Set the global profile like this:

openclaw config set tools.profile coding
openclaw gateway restart

For your browser case, I’d usually keep coding and add browser explicitly:

[west adder]

openclaw config set tools.profile coding
openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart

Or if you want all UI tools, add group:ui instead of just browser.

Docs: https://docs.openclaw.ai/tools#tool-configuration

[half fable]

I set tools.profile to full. and restarted gateway. here is the snippet of my openclaw json with some relevant bits

    "profile": "full",
    "web": {
      "search": {
        "provider": "exa",
        "enabled": true
      }
    }
  },
  "plugins": {
    "allow": [
      "browser",
      "openrouter",
      "exa",
      "memory-core"
    ],
    "entries": {
      "openrouter": {
        "enabled": true
      },
      "browser": {
        "enabled": true,
        "config": {}
      },

Still my agent says:

Still no browser tool in my current toolset. Here's the exact list:

read, write, edit, exec, process, web_search, web_fetch, cron, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status, image, image_generate, memory_get, memory_search, music_generate, update_plan, video_generate

No change since last check. If you're expecting one to appear, it might need to be enabled in the config — want me to look into that?

[west adder]

That config snippet looks right for plugin loading. If the agent still sees the exact old coding-profile tool list, I’d check these in order:

1. Make sure the running gateway is using the config you edited:

openclaw --version
openclaw gateway status
openclaw config get tools.profile

2. Check for per-agent or provider overrides. These can override the global tools.profile: "full":

openclaw config get agents.list
openclaw config get tools.byProvider

[west adder]

Look for things like:

agents: {
  list: [
    {
      tools: { profile: "coding" }
    }
  ]
}

or:

tools: {

[west adder]

  byProvider: {
    "...": { profile: "coding" }
  }
}

3. Start a new session/thread after the gateway restart. Some session/runtime prompt state can stay stale across config changes, and your reported list is suspiciously identical to the previous one.

4. If it still fails, check the latest gateway log for tool-policy/plugin warnings:

tail -n 300 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | rg "browser|plugins.allow|tools:|tool policy|plugin tool|unknown entries"

One useful extra test: set the tool explicitly even under full:

[west adder]

openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart

If agents.list[].tools.profile or tools.byProvider.*.profile is forcing coding, though, fix that override first. Global full won’t win against an agent/provider-specific profile.

[half fable]

still does not work. from my agent who's examined the config:

Config is perfect:

• ✅ tools.profile: "full"
• ✅ tools.alsoAllow: ["browser"]
• ✅ browser.enabled: true
• ✅ plugins.allow includes "browser"
• ✅ plugins.entries.browser.enabled: true

Everything is configured correctly.

also, I can run commands through the gateway like openclaw browser open https://google.com and it works just fine. however agent still has no browser tool.

[west adder]

One important wrinkle: openclaw browser ... working only proves the browser plugin’s CLI/service is loaded. The agent tool is plugin-registered, and some agent runtimes don’t expose plugin tools by default.

If this is an ACPX/Codex/Claude-Code-backed agent, enable the plugin-tools bridge:

openclaw config set plugins.entries.acpx.config.pluginToolsMcpBridge true --strict-json
openclaw gateway restart

Then start a fresh agent/session and run:

/tools verbose

That should be more authoritative than asking the model to self-report from memory.

[west adder]

Useful checks:

openclaw --version
openclaw plugins inspect browser
openclaw plugins inspect acpx

Docs: https://docs.openclaw.ai/tools/acp-agents#plugin-tools-mcp-bridge

If this is not an ACPX-backed agent and /tools verbose still omits browser with your config, I’d treat it as a bug and file with the version plus those plugins inspect outputs: https://github.com/openclaw/openclaw/issues

[half fable]

Here's a conversation I had with my agent:

Me:

when I run '/tools' I see:

Available tools

Profile: full

Built-in tools
agents_list, cron, edit, exec, gateway, message, nodes, process, read, sessions_history, sessions_send, session_status, sessions_list, sessions_spawn, subagents, tts, update_plan, web_fetch, web_search, write, sessions_yield

Connected tools
browser (browser), memory_get (memory-core), memory_search (memory-core)

Use /tools verbose for descriptions.

My Agent:

Ah, interesting! So the browser tool IS registered at the gateway level — the /tools command shows it as a connected tool. But it's not in my available tool list for this session.

This is a session-level issue. The tool exists, is connected, but isn't being exposed to my current session. This could be:

1. Session filter — something in my session is filtering it out
2. Tool resolution — the tool factory runs but returns nothing for this session context
3. Model/tool mismatch — the model I'm using might not be compatible with the browser tool's requirements

The fact that browser appears in /tools as a connected tool means the plugin is working correctly. The issue is specifically that my session can't access it.

Is there a way to check what tools are actually resolved for this specific session, or to force the browser tool to be included?

[west adder]

/tools is already the check for “what tools are actually resolved for this specific conversation.” If it shows:

Connected tools
browser (browser)

then OpenClaw has resolved browser for that session. Your agent’s prose answer saying “no browser tool” is likely just the model being wrong or reading an old/self-reported list. The real test is: ask it to use the browser tool, not to list tools.

Try something concrete like:

Use the browser tool to open https://example.com, take a snapshot, and tell me the page title.

If it still refuses, paste the refusal plus the latest logs around that turn. I’d search for browser/tool schema/provider errors:

[west adder]

tail -n 500 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)" | rg "browser|tool schema|provider tool|plugin tool|tools:"

One caveat: if /tools was run in Discord/OpenClaw but “my agent” is a separate ACP/Codex/Claude session, those are different runtimes. In that case run the equivalent tool inventory inside the ACP-backed session, and make sure the ACPX plugin-tools bridge is enabled.

Docs for what /tools means: https://docs.openclaw.ai/tools/slash-commands#tools

[half fable]

it is not a separate acpx session, this is the 'main' agent.

[west adder]

For the main agent, /tools is the authoritative runtime inventory for that conversation. If it shows browser (browser) under Connected tools, there isn’t another “force include” switch to flip — it’s already included.

I would not trust the agent’s diagnosis there. It’s reasoning from its own text, and that can be stale/wrong. Test an actual call:

Do not list tools. Call the browser tool with action="open" and url="https://example.com", then call browser snapshot and report the title.

If it says it can’t, try a fresh session in the same thread:

/new
/tools

Then ask the direct browser action again.

[west adder]

Two checks that would help pin it down:

/context detail
openclaw --version

/context detail should show whether the browser schema is actually in the model context. If /tools shows browser but direct browser calls still fail after /new, that’s likely either a provider/tool-schema/tool-calling issue or a bug. At that point I’d file it with:

• openclaw --version
• /tools output
• /context detail tool section
• the exact failed prompt/reply
• relevant log lines matching browser|tool schema|provider tool|tools:

Issue tracker: https://github.com/openclaw/openclaw/issues

[half fable]

ok /context detail did not show the browser tool. I did a /new and then context detail showed the browser and the agent was able to use it.