#OpenClaw browser failed

1 messages · Page 1 of 1 (latest)

fallow hollow
#

Hey there!

Once I ask my agent to look up for anything in the browser, or ask him to find some exact page, there is such an output in the console:

**[tools] browser failed: Can't reach the OpenClaw browser control (rotate/reissue device token) service. Restart the OpenClaw gateway (OpenClaw.appmenubar, or "openclaw gateway"). Do NOT retry the browser tool - it will keep failing. Use an alternative approach or inform the user that the browser is currently unavailable. **

Then it starts asking me to install a relay extension (idk which one, maybe the one it coded). So it adds this to the error:

(Error: Error: Chrome extension relay is running, but no tab is connected. Click the OpenClaw Chrome extension icon on a tab to attach it (profile "chrome").)

It also constantly tries to restart a gateway for no reason. If I allow it do that, it just just dies until I restart the gateway manually

How can I fix this please? 🙏🏻 I have a Windows 10 machine, Chrome installed.

hybrid quailBOT
#

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

ancient topazBOT
#

That combo of errors usually means OpenClaw is trying to use the chrome browser profile (Chrome extension relay), but either:

  1. you didn’t attach any tab with the extension (so it says “no tab is connected”), or
  2. you actually don’t want the extension at all and should switch the default to the managed openclaw profile.

Option A (recommended): use the managed openclaw browser (no extension)

This runs a separate, agent-only Chrome/Edge/Brave profile.

In a terminal on the Windows machine running the Gateway:

openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start

Then set it as the default so the agent stops trying to use the extension relay:

# 
openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/browser

Option B: control your existing Chrome tab (requires extension + manual attach)

  1. Install the OpenClaw Browser Relay extension files:
openclaw browser extension install
openclaw browser extension path
  1. In Chrome:
  • open chrome://extensions
  • enable Developer mode
#
  • Load unpacked → pick the folder printed by openclaw browser extension path
  • pin the extension
  1. Attach a tab:
  • open the tab you want controlled
  • click the extension icon
  • badge should show ON

Then test:

openclaw browser --browser-profile chrome tabs

Docs: https://docs.openclaw.ai/tools/chrome-extension

The “keeps restarting the gateway” part

That’s your model “panicking” after the tool failure. Don’t let it restart things repeatedly—fix the profile/setup first (steps above), then the browser tool should stop failing.

#

Quick questions so we can pinpoint what’s broken

Reply with these outputs (and tell me whether your Gateway runs on the same Windows 10 machine as Chrome, or in Docker/WSL/another PC):

openclaw --version
openclaw gateway status
openclaw browser status
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile chrome status

If the Gateway is remote (not on that Windows box), the fix is usually: run a node host on the Windows machine so browser control + extension relay are local.

fallow hollow
#

Done everything you told me in the option A. No errors in the output.

The gateway runs on the same machine as the Chrome browser.

Here are the outputs you wanted to see:

PS C:\Windows\system32> openclaw --version
2026.2.15

PS C:\Windows\system32> openclaw gateway status

🦞 OpenClaw 2026.2.15 (3fe22ea) — I can't fix your code taste, but I can fix your build and your backlog.

|
o
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-02-18.log
Command: C:\Program Files\nodejs\node.exe C:\Users\admin\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

openclaw browser status

🦞 OpenClaw 2026.2.15 (3fe22ea) — Because the right answer is usually a script.

|
o
profile: openclaw
enabled: true
running: false
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: chrome
detectedPath: C:\Program Files\Google\Chrome\Application\chrome.exe
profileColor: #FF4500

openclaw browser --browser-profile openclaw status

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

|
o
profile: openclaw
enabled: true
running: false
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: chrome
detectedPath: C:\Program Files\Google\Chrome\Application\chrome.exe
profileColor: #FF4500

openclaw browser --browser-profile chrome status

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

|
o
profile: chrome
enabled: true
running: false
cdpPort: 18792
cdpUrl: http://127.0.0.1:18792
browser: unknown
detectedBrowser: chrome
detectedPath: C:\Program Files\Google\Chrome\Application\chrome.exe
profileColor: #00AA00

ancient topazBOT
#

Your Gateway + browser config looks fine — the big clue is: you’re in a Discord channel/thread, and a lot of setups run sandbox mode = "non-main".

In that mode, Discord sessions count as “non-main” → tools run in a Docker sandbox, and then the browser tool defaults to target="sandbox" (not your host Windows Chrome). Result: it can’t reach the host browser control service and the model starts flailing / suggesting the extension.

1) Confirm (paste this output)

openclaw sandbox explain

If it says sandboxing is active for this session, you’ve found the cause.

2) Quick fix (recommended): turn sandboxing off

openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart
#

3) Then verify the managed browser actually starts

Right now running: false just means “Chrome isn’t launched yet”.

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

If that works, the agent browser tool should stop trying the extension path.

If you want to keep sandboxing on, you can, but you’ll need to allow host browser control and ensure the agent uses target:"host" with profile:"openclaw":

openclaw config set agents.defaults.sandbox.browser.allowHostControl true
fallow hollow
# ancient topaz Your Gateway + browser config looks fine — the big clue is: you’re in a **Discor...

here is the sandbox explain output

openclaw sandbox explain

🦞 OpenClaw 2026.2.15 (3fe22ea) — Less clicking, more shipping, fewer "where did that file go" moments.

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: C:\Users\admin.openclaw\sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: webchat
allowedByConfig: false
failing gates: allowFrom (tools.elevated.allowFrom.webchat)

Fix-it:

  • tools.sandbox.tools.allow
  • tools.sandbox.tools.deny
  • agents.list[].tools.sandbox.tools.allow
  • agents.list[].tools.sandbox.tools.deny
  • tools.elevated.enabled
  • tools.elevated.allowFrom.webchat

Docs: docs.openclaw.ai/sandbox

what do I do eventually?

fallow hollow
ancient topazBOT
#

That output is useful, but it’s for your main “webchat” session (sessionKey: agent:main:main) and it already says sandbox mode is off + runtime: direct. So my earlier “Discord sessions are sandboxed” theory may not be what’s biting you (or we’re looking at the wrong session key).

What to do next (in order)

1) Check the actual Discord session key + sandbox status

List recent sessions and find the one that corresponds to your Discord thread/channel:

openclaw sessions --active 240

Then run:

openclaw sandbox explain --session "<PASTE_SESSION_KEY_HERE>"
#

If that one shows sandbox mode: non-main/all, then we fix sandbox. If it’s also off, we move on.

2) Force managed browser mode (avoid extension relay)

Make sure the agent stops choosing the chrome relay profile:

openclaw config get browser.defaultProfile
openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

3) Start the managed browser once and verify it works from CLI

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot
#

If this works, the tool should work too (and the “no tab connected” relay message should disappear).

Two important notes from your sandbox explain

  • It shows sandbox tool policy denies browser by default. That only matters if your Discord session is actually sandboxed. If it is, you either disable sandboxing or explicitly allow group:ui / browser in tools.sandbox.tools.*.
  • If your Gateway is running as a Windows Scheduled Task in a non-interactive way, a non-headless Chrome may fail to launch. If start behaves weird/invisible, try:
    openclaw config set browser.headless true
openclaw gateway restart

Paste these and I’ll tell you exactly which branch to take

  1. openclaw sessions --active 240 (just the lines showing the Discord session + its sessionKey)
  2. openclaw sandbox explain --session "<that key>"
  3. If CLI start fails: the exact error from openclaw browser --browser-profile openclaw start and the last ~50 lines of openclaw logs --follow during the attempt.
fallow hollow
#

Well, I have done - openclaw config set agents.defaults.sandbox.browser.allowHostControl true

And restarted the gateway

Then the openclaw browser --browser-profile openclaw start outputs:

openclaw browser --browser-profile openclaw start

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your inbox, your infra, your rules.

|
o
|
o
🦞 browser [openclaw] running: true

My chrome opened (about:blank) and there is also a notice - Вы используете неподдерживаемый флаг командной строки: --disable-blink-features=AutomationControlled. Стабильность и безопасность будут нарушены.

fallow hollow
ancient topazBOT
#

That sandbox explain is actually good news: for that session (agent:main:main) you are not sandboxed (mode: off, runtime: direct).

Two clarifications first:

  1. “Sandbox tool policy: deny browser …” does not apply when mode: off. It only matters if a session is actually running in a sandbox.
  2. The “Elevated … failing gates … webchat” bit is only about host exec escape hatch; it’s unrelated to the browser tool.

What you should do “eventually” (stable setup)

A) If you want the easiest/most reliable: use the managed browser profile

  1. Force the default profile to openclaw (so it stops trying the extension relay):
openclaw config set browser.defaultProfile openclaw
openclaw gateway restart
  1. Start + test from CLI:
# 
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com

If it still times out and your Gateway runs as a Windows Scheduled Task

Chrome often can’t launch properly in a non-interactive session. In that case either:

  • run the Scheduled Task as “Run only when user is logged on”, or
  • switch to headless:
openclaw config set browser.headless true
openclaw gateway restart

B) If you specifically want to drive your existing Chrome tab(s): use the extension relay

Then you must use profile="chrome" and manually attach a tab by clicking the extension icon (badge ON). Otherwise you’ll keep getting “no tab is connected”.

#

One last check (because your output is for “main”)

If the browser works in CLI but fails only from Discord, run:

openclaw sessions --active 240

Find the Discord session key, then:

openclaw sandbox explain --session "<that-session-key>"

Paste:

  • the output of openclaw browser --browser-profile openclaw start (success or error)
  • and the Discord-session sandbox explain (if different)

…and I’ll tell you exactly which branch you’re in.

#

“Discord session” is OpenClaw’s internal name for the conversation thread you and I are talking in (each Discord channel/thread becomes a separate session key in the gateway’s session store). You’re not “an agent” — it’s just debugging jargon. You can ignore it unless we’re trying to prove whether this thread is running sandboxed vs not.

The important part: your managed browser is now starting correctly.

What your latest output means

  • openclaw browser --browser-profile openclaw start → running: true and Chrome popped up
    That means the OpenClaw-managed browser profile is working.
  • The Chrome warning about --disable-blink-features=AutomationControlled is normal in automation setups. It’s just Chrome telling you “this flag is unsupported”; it’s annoying but not a failure.

What to do next (to stop the “extension relay / no tab connected” loop)

Make OpenClaw default to the managed browser profile:

openclaw config set browser.defaultProfile openclaw
openclaw gateway restart