#Chrome Relay says “no tab is connected” even after reinstall + same-profile checks

1 messages · Page 1 of 1 (latest)

fierce verge
#

Hi team — I’m hitting a persistent Chrome relay attach failure.

Environment

  • OpenClaw gateway local mode (127.0.0.1:18789)
  • Browser control service up (127.0.0.1:18791)
  • Chrome relay endpoint reachable (127.0.0.1:18792)
  • Chrome extension installed/pinned in same active Chrome profile

Versions

  • macOS: 15.6 (Darwin 24.6.0)
  • Google Chrome: 145.0.0.0
  • OpenClaw: 2026.2.23

Symptom

OpenClaw browser tool always returns:

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

What we already tried

  • Restarted gateway multiple times
  • Removed/reinstalled extension
  • Confirmed same Chrome profile
  • Clicked extension on normal web tab (https://example.com)
  • Verified extension options show relay reachable
  • Confirmed this is not token/auth mismatch in Control UI

Result

Still cannot attach tab via profile="chrome" relay path.

Current workaround

Using profile="openclaw" (isolated browser) works.

Diagnostics

I have a local diagnostic bundle with exact logs/status snapshots and can paste full contents on request, including:

  • repeated tool error: Chrome extension relay is running, but no tab is connected
  • browser status snapshots showing relay endpoint reachable but no attached tab
  • gateway/browser service startup log excerpts and timestamps
elder flickerBOT
#

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

autumn gobletBOT
#

That error is thrown specifically when the extension relay is up but the relay has zero attached tabs. So the fastest way to debug is to verify whether the “attach” click is actually succeeding (from the gateway’s POV), and if not, why Chrome refused the debugger attach.

1) Verify attach from the gateway side (1 command)

Right after you click the toolbar icon on a normal tab, run:

openclaw browser --browser-profile chrome tabs
  • If it still says “no tab is connected” → the extension never successfully attached (even if Options says the relay is reachable).
  • If it lists a tab → tool calls should work, and we’d look at routing/sandboxing next.

2) What does the extension badge do?

Per the docs, the icon badge should show ON when attached (and …/! when it’s not)
Docs: https://docs.openclaw.ai/tools/chrome-extension

If you never see ON, the usual culprits are:

#
  • Chrome policy / enterprise restrictions blocking chrome.debugger (check chrome://policy)
  • Another debugger already attached to that tab (e.g. DevTools open can sometimes interfere)
  • You’re on a “restricted” page (Chrome internals / Web Store / etc.) — though example.com should be fine

If you do see ON but openclaw browser … tabs still claims none, then we need the relay/gateway logs from the moment you click attach.

3) Ensure you’re running the extension from the “OpenClaw-managed” install path

After upgrading OpenClaw, the most reliable refresh path is:

openclaw browser extension install
openclaw browser extension path

Then in chrome://extensions:

  • remove/disable any old duplicate unpacked loads
  • “Load unpacked” from the path printed above
#
  • hit “Reload” on the extension

(You said reinstall, but people often reinstall the Chrome side without re-installing the packaged extension files that ship with the specific OpenClaw version.)

4) If you paste diagnostics, these 3 snippets usually pinpoint it

Please paste (and redact tokens):

  1. openclaw browser status
  2. openclaw browser profiles
  3. A short log excerpt while doing: openclaw logs --follow → click extension attach → run openclaw browser --browser-profile chrome tabs

Troubleshooting page section that matches this exact signature:
https://docs.openclaw.ai/gateway/troubleshooting#browser-tool-fails

5) One more gotcha: sandboxed sessions

If the agent session you’re triggering the tool from is sandboxed, Chrome takeover needs host browser control enabled (otherwise you can end up driving the isolated browser fine while host takeover never “sticks”):