Bug type

Docs mismatch / feature gap

Summary

When using a remote Gateway with a connected node host on the machine that runs Chrome, the browser tool can use the node's managed browser profile, but the built-in profile="user" (driver="existing-session", Chrome DevTools MCP) is hard-blocked for target="node" with:

profile="user" only supports the local host browser.

This appears inconsistent with the browser/node-host docs, which describe remote browser control via node host and note that the Gateway or node host can spawn npx chrome-devtools-mcp@latest --autoConnect.

Environment

• OpenClaw: 2026.3.13 (61d171a)
• Gateway host: headless Linux server over Tailscale Serve
• Node host: macOS laptop on same Tailscale tailnet
• Browser on node: Google Chrome 146.0.7680.80
• Node status: paired + connected, caps: [browser, system]

Steps to reproduce

1. Run OpenClaw Gateway on a remote Linux server.
2. Run openclaw node run --host <gateway> --port 443 --tls --display-name "sam macbook pro" on a macOS machine with Chrome installed.
3. Approve node pairing on the gateway.
4. Confirm node is connected and advertises browser capability.
5. From an agent/browser-tool context, inspect browser profiles on the node.
6. Attempt to use the built-in live Chrome session via:
   • browser(action: "status", target: "node", node: "sam macbook pro", profile: "user")

Expected behavior

If node-host browser proxy is the supported architecture for remote browser control, profile="user" / existing-session Chrome MCP should either:

• work through the node host, or
• be clearly documented as local-host-only.

Actual behavior

• Node host works.
• Managed browser on the node works.
• Browser profiles on the node show:
  • openclaw
  • user (driver: existing-session, transport: chrome-mcp, running: true, tabCount: 8)
  • chrome-relay
• But browser requests against profile="user" on the node fail immediately with:

profile="user" only supports the local host browser.

Evidence

Node host is connected and browser-capable

openclaw nodes status:

• node connected
• caps include browser

openclaw nodes describe --node "sam macbook pro":

• commands include browser.proxy

Browser profiles on the node show live Chrome session detected

browser(action: "profiles", target: "node", node: "sam macbook pro") returned a user profile with:

• driver: "existing-session"
• transport: "chrome-mcp"
• running: true
• tabCount: 8

Managed browser on the node works

The node-managed openclaw browser profile can launch and return a snapshot successfully (e.g. https://example.com → "Example Domain").

Current code hard-blocks user profile on node targets

In the installed build, the following guard exists:

• /usr/local/lib/node_modules/openclaw/dist/model-selection-CU2b7bN6.js
• /usr/local/lib/node_modules/openclaw/dist/reply-Bm8VrLQh.js

Observed logic:

if (requestedNode || target === "node") throw new Error(`profile="${profile}" only supports the local host browser.`);

There is also logic treating existing-session as:

mode: "local-existing-session"

which suggests the implementation is intentionally local-only right now.

Relevant docs

Browser docs:

• https://docs.openclaw.ai/tools/browser
• https://docs.openclaw.ai/tools/browser#chrome-existing-session-via-mcp

CLI browser docs (remote node-host proxy):

• https://docs.openclaw.ai/cli/browser#remote-browser-control-node-host-proxy

Chrome extension docs (remote gateway → use node host):

• https://docs.openclaw.ai/tools/chrome-extension#remote-gateway-use-a-node-host

The specific line that creates the expectation mismatch is in the browser docs:

"the Gateway or node host can spawn npx chrome-devtools-mcp@latest --autoConnect"

Impact

This makes the remote node-host browser story partially work:

• ✅ managed browser on node works
• ❌ built-in live Chrome session (profile="user") does not work remotely

So users who set up a remote gateway + local node host specifically to access their real signed-in Chrome session hit a hard stop.

Requested outcome

Please clarify which of these is intended:

1. profile="user" / existing-session Chrome MCP is supposed to work over node host, and the current hard block is a bug.
2. profile="user" is intentionally local-host-only, and the docs should be updated to say that explicitly.

If the latter is intended, a docs clarification would save a lot of confusion.