Browser Relay with Node not working | Friends of the Crustacean 🦞🤝 | Page 1

unkempt rampartBOT Mar 12, 2026, 5:02 PM

#

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

tribal mauve Mar 12, 2026, 5:02 PM

#

Right click solution message -> Apps -> ✅ Mark Solution

ripe sparrowBOT Mar 12, 2026, 5:12 PM

#

In a remote Gateway + Mac node setup, the relay at http://127.0.0.1:18792 is supposed to be served by the node host on the Mac (not the VPS). There isn’t a separate “relay-only” daemon/command — it’s created by the node’s browser control service when the node is browser-capable.

Why it often doesn’t come up in remote mode:

1) The Mac node doesn’t have a gateway token locally (most common)

The relay auth token is derived from OPENCLAW_GATEWAY_TOKEN / gateway.auth.token on the machine running the relay (your Mac). It does not automatically reuse gateway.remote.token.

So if your Mac node can connect to the VPS using gateway.remote.token, but doesn’t have OPENCLAW_GATEWAY_TOKEN / gateway.auth.token set locally, the node can still be “healthy for exec”… but the relay server fails to initialize, and you’ll see cdpHttp: false.

Fix (on the Mac):

Put the VPS token into the Mac’s env in a way the node host/service actually sees (macOS services don’t inherit your shell env):
- ~/.openclaw/.env:
```
OPENCLAW_GATEWAY_TOKEN=...same token as the VPS gateway.auth.token...
```
- or set it in the Mac’s ~/.openclaw/openclaw.json as gateway.auth.token.

#

Then restart the node host (macOS app / openclaw node restart if you’re using the headless node service).

2) The node isn’t advertising browser proxy capability

On the VPS, check whether your Mac node is browser-capable:

openclaw nodes status --connected

You want to see the Mac node advertising browser capability or the browser.proxy command. If it doesn’t, make sure on the Mac:

browser.enabled is not disabled
nodeHost.browserProxy.enabled is not disabled

(see docs: https://docs.openclaw.ai/cli/node and https://docs.openclaw.ai/tools/chrome-extension)

3) “Should it auto-start?”

Gateway on same machine as Chrome: yes, the gateway starts the relay server automatically.

#

Remote Gateway: the relay is started by the node host when browser control is initialized (often on first browser call). After fixing token/config, running:
```
openclaw browser status
```
is a good “kick” to force the browser proxy path and bring up the relay.

If you paste:

openclaw --version on VPS + Mac
openclaw nodes status --connected (from VPS)
I can tell you immediately which of the above you’re hitting.

#

Yep — once it’s actually working (extension Options can reach http://127.0.0.1:18792 and openclaw browser status shows cdpHttp: true), please right‑click the message that fixed it → Apps → ✅ Mark Solution so Answer Overflow indexes it.

If it’s still showing cdpHttp: false, paste:

openclaw nodes status --connected (from the VPS)
openclaw --version on VPS + Mac
and we’ll pinpoint whether it’s missing OPENCLAW_GATEWAY_TOKEN on the Mac vs the node not advertising browser.proxy.

ripe sparrowBOT Mar 12, 2026, 7:45 PM

#

A couple key clarifications (because the symptoms you posted are exactly what happens when the relay init fails on the node):

What “should” happen

In remote Gateway mode, the relay on the Mac (127.0.0.1:18792) is started by the node host on the Mac when the Gateway routes a browser.proxy call to it.
There is no separate “start relay” command. The relay is created as part of initializing the node’s browser control subsystem.

So if lsof -i :18792 is empty, it means: the Mac node host never successfully initialized the extension relay server.

The most likely cause in your case: the Mac node host still can’t resolve a gateway token

The extension relay server requires a local token source on the machine running the relay:

OPENCLAW_GATEWAY_TOKEN (env), or
gateway.auth.token (in that machine’s openclaw.json)

Important nuance: in remote setups you often only set gateway.remote.token. That is enough for the node to connect to the VPS, but the relay auth derivation does not use gateway.remote.token.

You added OPENCLAW_GATEWAY_TOKEN to ~/.openclaw/.env, but depending on which process is actually acting as the node host (macOS app node vs openclaw node service), that .env may not be getting loaded.

#

Fix I’d try first (most deterministic)

On the Mac, set the token directly in config (not just .env):

{
  gateway: {
    auth: {
      mode: "token",
      token: "PASTE_THE_SAME_TOKEN_YOU_PUT_IN_THE_EXTENSION",
    },
  },
}

Leave your existing gateway.mode="remote" + gateway.remote.* as-is.

Then restart the actual node host process that is connected.

#

How to force the Mac node to initialize the relay (and get a useful error if it can’t)

From the VPS, run an explicit node invoke so we know we’re hitting the Mac node:

Find the node id/name:

openclaw nodes list --connected

Invoke the browser proxy on that node:

openclaw nodes invoke --node "<mac-node>" --command browser.proxy --params '{"method":"GET","path":"/","profile":"chrome"}'

What we’re looking for:

If this returns an error like “extension relay requires gateway auth token …” → the Mac node host still isn’t seeing OPENCLAW_GATEWAY_TOKEN / gateway.auth.token.
If it returns enabled:true etc, then immediately re-check on the Mac:
- lsof -i :18792

#

and the extension Options page should flip to reachable.

Also check one easy “gotcha”

Make sure you did not set legacy browser.cdpUrl on the Mac to http://127.0.0.1:18792. That can prevent the built-in chrome extension profile from being created (port collision logic), which means no relay is started.

If you paste two outputs, we can finish this fast

VPS:

openclaw nodes invoke ... output (the command above)

Mac:

the exact openclaw browser status --json output (so we can see which profile it’s actually talking about)

Docs refs (for the behavior described above):

#Browser Relay with Node not working