#Chrome extension

1 messages · Page 1 of 1 (latest)

oblique templeBOT Feb 21, 2026, 4:37 AM

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

wheat nicheBOT Feb 21, 2026, 4:40 AM

“Relay disconnected” with the Chrome extension is usually one of these:

No tab is attached yet (most common)

Open the tab you want to control → click the OpenClaw extension icon
The badge should show ON (it does not auto-attach)

The local relay server isn’t reachable

Extension badge meanings:
ON = attached, should work
! = relay not reachable (server/port issue)
… = trying to connect

Your Gateway is remote, but you didn’t start a node host on the Chrome machine

If the Gateway is running on a different machine than Chrome, you typically need a node host on the machine with Chrome so the Gateway can proxy browser control.

To diagnose fast, can you paste:

openclaw --version
openclaw status --all (it redacts tokens)
And tell me:
Is the Gateway on the same machine as Chrome, or remote?
What badge do you see on the extension (ON / ! / …)?

Also try (on the machine you expect to have the relay running):

openclaw browser --browser-profile chrome status
openclaw browser --browser-profile chrome tabs

Docs (with the badge/error meanings + remote gateway notes): https://docs.openclaw.ai/tools/chrome-extension

That output is the key: your chrome browser profile is configured, but the relay isn’t running.

cdpUrl: http://127.0.0.1:18792 + running: false means nothing is listening on 127.0.0.1:18792, so the extension will show disconnected (! / relay unreachable).

Try this checklist on the same Mac that’s running Chrome:

Confirm the Gateway is actually running

openclaw gateway status
openclaw status

Restart the Gateway (most common fix)

openclaw gateway restart

Re-check the relay status

openclaw browser --browser-profile chrome status

If it still says running: false, check if the port is blocked/taken:

lsof -nP -iTCP:18792 -sTCP:LISTEN

Also: is your Gateway on this same Mac, or is it running remote (VPS/etc)?
If it’s remote, you generally need a node host on the Mac with Chrome for the relay/takeover to work.

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

potent glacier Feb 21, 2026, 6:47 AM

gate way is running on mac

wheat nicheBOT Feb 21, 2026, 6:48 AM

Cool — if the Gateway is on the same Mac, then that running: false basically means nothing is listening on 127.0.0.1:18792, so the extension has nothing to talk to.

Let’s narrow it down to the 2 usual causes: port conflict or Gateway/CLI config mismatch.

1) Start the relay explicitly (quick win)

Run:

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

2) Check if something else is already using 18792

lsof -nP -iTCP:18792 -sTCP:LISTEN

If you see another process listening, OpenClaw can’t bind that port (and the relay won’t come up).

3) Check for “CLI vs service” mismatch (very common on macOS)

Paste the output of:

openclaw gateway status

In particular, it will show whether Config (cli) and Config (service) differ, and whether the RPC probe is ok.

If you want, also paste:

openclaw status --all

(it redacts secrets)

Once I see those outputs I can tell you exactly which branch you’re in.

Nice — that means something is listening on 127.0.0.1:18792 already.

Now we need to confirm two things:

Is that listener actually the OpenClaw relay server?
Is the Chrome extension connected to it? (separate from “attached to a tab”)

A) Verify it’s the OpenClaw relay + whether the extension is connected

Run these on the Mac:

curl -I http://127.0.0.1:18792/
curl http://127.0.0.1:18792/extension/status

Expected:

first one: HTTP/1.1 200 OK

second one: {"connected": true} when the extension has an active connection to the relay

If connected is false, the relay server is up but the extension isn’t actually talking to it yet (Chrome-side issue: extension not loaded/reloaded, permissions, etc.).

B) If it’s not OpenClaw, identify that `node` process

ps -p 12055 -o command=

Paste that line — it’ll tell us if this is OpenClaw, or some other Node thing squatting on the port.

C) Also paste this (checks CLI vs service mismatch)

openclaw gateway status

(There’s a very common macOS case where the Gateway service is running with a different config/install than the openclaw CLI, and then browser/relay status gets weird.)

Docs for the relay/extension behavior: https://docs.openclaw.ai/tools/chrome-extension

That’s actually good news: the relay server is up (HTTP/1.1 200 OK), but the Chrome extension is not connected to it yet:

/extension/status → {"connected": false}

So the problem is on the Chrome side (extension not loaded/enabled in the profile you’re using, needs reload, or its Options point at the wrong relay URL).

Fix checklist (in Chrome)

Go to chrome://extensions

Find OpenClaw Browser Relay (or similar)
Make sure it’s Enabled
Click Reload
(Optional but useful) click the extension’s “service worker” link — it should open DevTools (meaning it’s alive)

Open the extension Options

Ensure the relay URL/port is http://127.0.0.1:18792
- If you changed your gateway port at any point, the relay port may have shifted; but your openclaw browser ... status says 18792, so set it to that.

Now open the tab you want controlled and click the extension toolbar icon

Badge should go … briefly then ON

Verify it worked

Run again:

curl http://127.0.0.1:18792/extension/status

You want: {"connected":true}

If it still stays false, tell me:

are you using multiple Chrome profiles? (extension might be installed in a different profile)
and paste:

  openclaw browser extension path
  openclaw browser --browser-profile chrome tabs

Ok, so the relay itself is alive now:

curl -I http://127.0.0.1:18792/ → 200 OK ✅
curl http://127.0.0.1:18792/extension/status → connected:false ❌
openclaw browser … tabs → No tabs (because no extension-attached targets yet)

That means: OpenClaw’s relay server is running, but the Chrome extension service worker is not connected to it (so it can’t report/forward any attached tabs).

The 3 things that usually cause `connected:false`

1) Extension is loaded in a different Chrome profile than the window you’re testing

In the exact Chrome window you’re using, open:

chrome://extensions

Make sure you actually see the OpenClaw extension there (enabled).

2) The unpacked extension path is wrong (loaded the wrong folder)

Your path is:
~/.openclaw/browser/chrome-extension

In chrome://extensions:

enable Developer mode
Remove the existing OpenClaw extension completely
Load unpacked → select that exact folder (~/.openclaw/browser/chrome-extension)
then click Reload on the extension once

(If you selected the parent folder or some copied folder, MV3 can “look installed” but never boot correctly.)

3) The extension is erroring and never starts its service worker

In chrome://extensions → click Details on the OpenClaw extension:

check Errors (if there’s an “Errors” button)
click service worker (Inspect views) and look at the Console

If you paste the first error line you see there, we can usually pinpoint it immediately.

Quick verification loop

After reinstall/reload, run again:

curl http://127.0.0.1:18792/extension/status

You want {"connected":true}.

Once it’s true, then clicking the extension icon on a tab should make openclaw browser --browser-profile chrome tabs show targets.

If you can, paste:

the error from the extension service worker console (or “no errors”), and
openclaw gateway status (to rule out CLI/service mismatch).

weak zinc Feb 21, 2026, 1:25 PM

Please please anyone can help with this issue, driving me insane. Relay reachable and authenticated at http:// 127.0.0.1:18789/ this is all set up the tunnel etc all good but when I press ON, it shows the bar for a few sections then goes off and cant be reached by bot? The extension shows orange with ...

I removed the other ones, sorry didnt think would get response quick so was trying on a few

wheat nicheBOT Feb 21, 2026, 1:27 PM

This symptom (“badge goes orange ... for a few seconds, then turns off / bot can’t see the tab”) almost always means the extension can’t keep a WebSocket connection to the relay.

Big gotcha: 127.0.0.1:18789 is the Gateway/UI port, not the relay.
For the Chrome extension takeover, the relay is typically:

Relay (extension connects here): http://127.0.0.1:18792
(Related) Browser control service: http://127.0.0.1:18791

1) Check what the extension is pointed at

In the extension Options, make sure the relay URL is exactly:

http://127.0.0.1:18792

If you pointed it at 18789, it’ll “kind of try” and then fail.

2) If your Gateway is remote and you’re using an SSH tunnel

You need to tunnel the relay port too, not just the Gateway port. Example:

ssh -N \
-L 18789:127.0.0.1:18789 \
-L 18792:127.0.0.1:18792 \
user@<gateway-host>

Important: the relay server rejects non-loopback connections, so the extension must reach it via 127.0.0.1 (tunnel is perfect for that).

3) Verify from your local machine (where Chrome runs)

Run:

curl -I http://127.0.0.1:18792/
curl http://127.0.0.1:18792/extension/status

Expected:

first: HTTP/1.1 200 OK
second: {"connected":true} (once the extension is actually connected)

If it stays false, Chrome never connected to the relay (extension not loaded in that Chrome profile, wrong URL, or the tunnel/relay isn’t up).

4) Make sure you’re attaching on a normal webpage

The extension can’t attach to chrome://… pages / Chrome Web Store pages. Try on https://example.com and click ON there.

If you paste:

your extension Options relay URL (just host/port, no secrets)
the two curl outputs above
and whether your Gateway is local vs SSH-tunneled remote
…I can tell you exactly which branch you’re in.

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

weak zinc Feb 21, 2026, 1:28 PM

Thanks very much for the info, will give above a go

wheat nicheBOT Feb 21, 2026, 1:28 PM

Yep, multiple installs can definitely make it look “haunted” — good call removing them.

If the badge goes ... (orange) then turns off, that’s almost always: the extension can’t keep a connection to the relay (not the dashboard).

A couple clarifications + the shortest path to isolate it:

1) Make sure the extension is pointing at the relay port (not 18789)

18789 = Gateway / dashboard
18792 = Chrome extension relay (what the badge connects to)

In the extension Options, the URL should be:

http://127.0.0.1:18792

2) If your Gateway is remote via SSH tunnel: tunnel the relay port too

A lot of folks tunnel only 18789 and then the extension can’t reach the relay.

Example:

ssh -N \
-L 18789:127.0.0.1:18789 \
-L 18792:127.0.0.1:18792 \
user@<gateway-host>

(Keep that SSH session running.)

3) Verify from the Chrome machine

Run locally (same machine Chrome is on):

curl -I http://127.0.0.1:18792/

curl http://127.0.0.1:18792/extension/status

first should be HTTP/1.1 200 OK
second should become {"connected":true} once the extension is actually connected

If it stays connected:false, Chrome isn’t connecting to the relay at all → check the extension service worker console:

chrome://extensions → Details → “service worker” (Inspect) and paste the first error line.

4) Attach on a normal webpage

It won’t attach on chrome://… pages (extensions/settings/etc). Try https://example.com, then click ON.

If you paste your two curl outputs + whether you’re tunneling or fully local, I can tell you exactly which branch you’re hitting.