configure gateway to use browser proxy on remote node

[vestal bramble]

Remote node is running and paired & connected to gateway. Browser control on the node is confirmed (e.g. openclaw browser --browser-profile openclaw open https://example.con). Now I'd like the gateway to be able to use the remote browser (without extension, just under the openclaw profile). What additional conf is needed on gateway and node to continue?

[radiant nexus]

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

[willow ice]

If the node host is already paired + connected, the “remote browser under the openclaw profile” is usually zero‑config: the node host advertises a browser proxy, and the Gateway auto-routes browser tool calls to it.

1) Node side (machine that has the GUI browser)

Make sure you did not disable the browser or the node browser proxy.

~/.openclaw/openclaw.json on the node:

{
  browser: {
    enabled: true,
    defaultProfile: "openclaw", // optional but nice
  },
  nodeHost: {
    browserProxy: {
      enabled: true, // default; only needed if you previously turned it off
    },

  },
}

(Per docs, the node host advertises the proxy as long as browser.enabled isn’t disabled.)

2) Gateway side (routing policy)

Ensure node browser routing isn’t disabled, and optionally pin the node.

~/.openclaw/openclaw.json on the gateway:

{
  gateway: {
    nodes: {
      browser: {

        mode: "auto",   // "auto" | "manual" | "off"
        // node: "My Mac Node", // optional pin if you have multiple browser-capable nodes
      },
    },
  },

  // Optional: make the agent default to the managed profile name
  browser: { defaultProfile: "openclaw" },
}

Mode meanings:

• "auto" = if exactly one browser-capable node is connected, use it automatically
• "manual" = require you to pass node=<id|name> in calls
• "off" = disables node browser proxy routing entirely

If you have multiple nodes connected, you’ll otherwise hit an error like:

“Multiple browser-capable nodes connected… Set gateway.nodes.browser.node or pass node=<id>.”

3) How to use it

Once the above is true, from the Gateway/agent you can either:

• rely on auto-routing (mode:"auto") and just use profile:"openclaw", or
• be explicit: target:"node" + node:"<id|name>" + profile:"openclaw".

Quick docs refs

• Browser tool + node proxy: https://docs.openclaw.ai/tools/browser
• Node host browser proxy note: https://docs.openclaw.ai/cli/node

If it still doesn’t route, paste:

• openclaw --version
• openclaw nodes status
• (and if possible) openclaw nodes describe --node <id>

[vestal bramble]

nodes status is now showing "browser" under caps. Q1) how do I get the windows node to persist it's connection? Currently I am manually calling node run --host etc from ps on it. Q2) how can I invoke the tool? give an example prompt

@willow ice u ded, homie?

[willow ice]

Q1) Make the Windows node persistent (no more manual node run)

Use the built-in service install:

# on the Windows machine (node)
openclaw node install --host <gateway-host> --port 18789 --display-name "Windows Browser Node" --force
openclaw node restart
openclaw node status

On Windows, openclaw node install installs a Task Scheduler task (name: OpenClaw Node). You can inspect/run it manually:

schtasks /Query /TN "OpenClaw Node" /V /FO LIST
schtasks /Run   /TN "OpenClaw Node"

Important for auth: the node host needs the gateway token at startup. For a service/task, the most reliable is setting a User env var on Windows:

[Environment]::SetEnvironmentVariable("OPENCLAW_GATEWAY_TOKEN", "<your-gateway-token>", "User")

Then restart the node task (openclaw node restart or schtasks /Run ...).
(Alternative: you can also put the token into the node’s ~/.openclaw/openclaw.json, but env var is usually cleaner on Windows.)

Also: if the Windows box sleeps/hibernates, the node will disconnect—so disable sleep or allow wake/network as needed.

---

Q2) How to invoke the browser tool (example prompts)

Once nodes status shows the node has caps: browser, the Gateway can auto-route browser calls to it.

Try prompts like these in chat:

1. Basic navigation + screenshot

“Open https://example.com in the node browser (profile openclaw) and take a screenshot.”

2. Do something + report back

“Using the node’s openclaw browser, go to https://news.ycombinator.com and tell me the top 5 story titles.”

3. Force the right node if you have multiple

“Use the browser on node Windows Browser Node (profile openclaw). Open https://example.com and take a snapshot of the page.”

If you ever have multiple browser-capable nodes connected, pin the one you want on the gateway:

{
  gateway: { nodes: { browser: { mode: "auto", node: "Windows Browser Node" } } }

}

Then you don’t have to fight routing—everything just goes to that node’s browser proxy.

[willow ice]

Not dead—just slow because I was pulling the exact docs + service behavior. You’re good now.

Quick recap:

• Persist node on Windows: openclaw node install … (creates Scheduled Task “OpenClaw Node”) + set OPENCLAW_GATEWAY_TOKEN as a User env var, then openclaw node restart.
• Use the remote browser: just ask in chat (“open URL and screenshot/snapshot”), and it’ll auto-route to the node since nodes status shows browser.

If you want, paste your openclaw node status output (on Windows) if the task still isn’t sticking.

[vestal bramble]

thx. I get now "Chrome extension init failed for profile "chrome"" on the node when the gateway attempts to use the browser tool. So it seems something is set to use extension (which I don't want to use). Where should I look ?

[willow ice]

That error means the Gateway is trying to use the chrome browser profile (the extension relay profile) on the node. By default, browser.defaultProfile is "chrome", so if the tool call/prompt doesn’t specify a profile, it’ll pick that and then fail because no extension is set up (and you said you don’t want it).

Where to look / what to change (Gateway-side)

On the gateway host, check what the default is:

openclaw config get browser.defaultProfile

Set it to openclaw:

openclaw config set browser.defaultProfile openclaw
openclaw gateway restart

(You can also confirm you’re not forcing a “chrome” profile anywhere else in your config.)

Optional (Node-side, nice-to-have)

If you also want the node itself to default to managed mode when it’s the one resolving defaults, set on the node too:

openclaw config set browser.defaultProfile openclaw

How to invoke (prompt examples)

After setting the default, prompts that don’t mention a profile should stop trying chrome. You can also be explicit:

• “Use the openclaw browser profile on my Windows node. Open https://example.com and take a screenshot.”
• “Using browser profile openclaw, go to https://news.ycombinator.com and list the top 5 titles.”

Docs reference (explains openclaw vs chrome): https://docs.openclaw.ai/tools/browser

If you paste the output of openclaw config get browser.defaultProfile (gateway) and openclaw nodes status, I can sanity-check that nothing else is pinning you to chrome.

[vestal bramble]

ok, that progressed us. Currently when prompting the browser on the node opens, however it does not navigate to the desired website. Currently two tabs are open on the openclaw brave profile window. The gateway reported back the following error:
Tool Output

{
"status": "error",
"tool": "browser",
"error": "Error: Error: listen EADDRINUSE: address already in use 127.0.0.1:18792"
}

[willow ice]

That EADDRINUSE 127.0.0.1:18792 is the giveaway: 18792 is the Chrome-extension relay port (the built-in chrome profile’s CDP URL defaults to http://127.0.0.1:18792). So something on the Windows node is still trying to start/use the extension relay, and it can’t bind because that port is already taken.

1) First make sure the node is not defaulting to chrome

On the Windows node, check:

openclaw config get browser.defaultProfile

If it’s chrome, set it:

openclaw config set browser.defaultProfile openclaw

(Do this on the node even if you already did it on the gateway—when the gateway proxies to the node, the node’s browser config can still matter.)

Also: in your prompt, be explicit once to confirm routing:

“Use browser profile openclaw (not chrome/extension). Open https://example.com”

2) Free the port (most common cause: two OpenClaw things running on the node)

On Windows, find what owns 18792:

netstat -ano | findstr :18792
# then:
tasklist /FI "PID eq <pid>"

If it’s an old OpenClaw node host / gateway / stray node.exe, kill it:

taskkill /PID <pid> /F

Very common scenario: you have both:

• a manual openclaw node run ... still running and
• the scheduled-task service from openclaw node install

If so, stop the service and restart cleanly:

openclaw node stop
openclaw node restart
openclaw node status

3) If you must avoid 18792 entirely

The clean fix is “don’t use the extension relay profile”, but if some other software permanently owns 18792, you can also “move the browser port family” by changing the node’s gateway.port (the browser control/relay ports are derived from it). That’s a bit hacky, so I’d only do it if you confirm something non-OpenClaw is occupying 18792.

---

If you paste these two outputs, I can tell you exactly which path you’re on:

• Windows node: openclaw config get browser.defaultProfile
• Windows node: netstat -ano | findstr :18792

[vestal bramble]

after restarting the node and gateway the node successfully opens the target web page. However, most attempts are now failing with the following error despite it working intermittently: {
"status": "error",
"tool": "browser",
"error": "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: No supported browser found (Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).)"
}

[willow ice]

That error is coming from the node (not the gateway): when the node host tries to (re)start/attach the openclaw-managed browser control service, its browser auto-detect sometimes can’t find a usable Chrome/Brave/Edge/Chromium executable, so the proxy call fails and the gateway reports “can’t reach browser control service”.

The fact it’s intermittent is almost always because the node host is sometimes running under a different Windows user/session (manual PowerShell vs Scheduled Task), with different env vars / install visibility.

Fix 1 (recommended): hard-pin the browser executable on the Windows node

On the Windows node, set an explicit path so auto-detect isn’t involved:

# Brave (common)
openclaw config set browser.executablePath "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe"

# OR Chrome (common)
# openclaw config set browser.executablePath "C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"

# OR Edge (common)
# openclaw config set browser.executablePath "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe"

openclaw node restart

(Adjust the path if yours differs; you can quick-check with Test-Path "<path>".)

Fix 2: ensure the Scheduled Task runs in the interactive user context

Open Task Scheduler → find task “OpenClaw Node” → verify it’s running as your user and is configured like:

• Run only when user is logged on (important for GUI browser launch)
• not running as SYSTEM / a different account

If it runs as a different account, it may not “see” Brave/Chrome installed for your user (or it may have a different HOME/config).

Quick sanity checks to paste back (from the Windows node)

1. What profile default is on the node: