my clawdbot looses browser relays connection

[candid lake]

my clawdbot looses browser relays connection

[tardy yacht]

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

[lusty harbor]

Browser Relay drops usually come from one of these 3 links breaking:

1. The tab isn’t attached anymore (extension badge not ON)
2. The local relay isn’t reachable (badge !)
3. The browser host (Gateway or node host) restarted / slept → relay restarts and the extension detaches

Quick checks (when it “loses connection”)

• What does the extension badge show on the tab?
  • ON = attached
  • … = trying to connect
  • ! = relay not reachable (most common)
• Open the extension Options page — it will explicitly say if the relay is reachable (docs: https://docs.openclaw.ai/tools/chrome-extension)

Most common causes + fixes

• Gateway is remote (VPS) but Chrome/Arc is local: you must run a node host on the browser machine (so the relay lives locally).
  • On the browser machine: openclaw node status (or openclaw node install … / openclaw node run …)
  • Node docs: https://docs.openclaw.ai/cli/node

• Arc/Chrome “Memory Saver” / tab discarding / sleep: the tab gets suspended → debugger detaches → relay drops.
  • Try disabling Memory Saver (or excluding that site), and keep the attached tab/window alive.
• Port mismatch (if you changed gateway.port): browser relay ports are derived (gateway.port+2 for control, +3 for relay; defaults 18791/18792). Make sure the extension is pointing at the right relay port. (Docs: https://docs.openclaw.ai/tools/browser)

Useful debug info to paste here

1. openclaw --version
2. openclaw status --all
3. Right when it drops: openclaw logs --limit 200 (and tell us whether you’re using Arc vs Chrome, and whether your Gateway is local or remote/VPS)

With those, we can usually pinpoint if it’s tab-discarding vs node/gateway restarts vs relay reachability.

[candid lake]

[tools] browser failed: Can't reach the OpenClaw browser control service. Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or openclaw gateway) and try again. (Error: ref is required)
01:38:42 [tools] browser failed: Can't reach the OpenClaw browser control service. Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or openclaw gateway) and try again. (Error: ref is required)
01:47:18 [tools] browser failed: Can't reach the OpenClaw browser control service (timed out after 20000ms). Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or openclaw gateway) and try again.
02:00:14 [tools] browser failed: Can't reach the OpenClaw browser control service. Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or openclaw gateway) and try again. (Error: Error: tab not found)
02:00:34 [tools] browser failed: Can't reach the OpenClaw browser control service. Start (or restart) the OpenClaw gateway (OpenClaw.app menubar, or openclaw gateway) and try again. (Error: Error: tab not found)

[lusty harbor]

Those 3 errors are actually 3 different failure modes, so it helps narrow it down:

• timed out after 20000ms ⇒ the Gateway (or node host) couldn’t reach the browser control service (the loopback service, default 127.0.0.1:18791).
• tab not found ⇒ the control service was up, but no attached tab exists anymore (extension got detached, tab got discarded/closed, Arc changed the underlying tab, etc.).
• ref is required ⇒ that one is usually just a bad browser tool call (model tried to click/type without a valid element ref). It’s often version/model related, but we should still focus on the control-service + tab attach first.

1) First question: is your Gateway local or remote?

• If the Gateway is on a VPS/other machine, you must run a node host on the same machine as Arc (so the relay+tab live locally and the Gateway proxies to it). Otherwise you’ll see exactly these “can’t reach browser control service” / “tab not found” patterns.
  • Docs: https://docs.openclaw.ai/tools/chrome-extension + https://docs.openclaw.ai/cli/node

2) Quick checks to run (paste outputs)

On the machine where the Gateway runs:

openclaw --version
openclaw gateway status
openclaw browser status

openclaw browser --browser-profile chrome tabs

Also, check whether something is actually listening (on the gateway host):

lsof -nP -iTCP:18791 -sTCP:LISTEN
lsof -nP -iTCP:18792 -sTCP:LISTEN

Notes:

• Browser control service defaults to gateway.port + 2 (so usually 18791), and the relay is the next port (18792). If you changed gateway.port, these shift.

3) For the “tab not found” part (Arc/extension)

When it breaks, look at the extension badge on the tab:

• ON must be present, otherwise OpenClaw has nothing to drive.
• If Arc is discarding/suspending the tab in the background, the debugger detaches → you need to re-attach (and consider testing in plain Chrome/Brave to rule out Arc tab lifecycle quirks).

If you paste the outputs from (2) and tell me whether your Gateway is local vs VPS, I can tell you exactly which branch (node host vs ports/service vs Arc detaching) you’re hitting.