Summary

When using the node browser proxy to access a Chrome MCP existing-session (user profile) on a remote node, the connection fails with McpError: MCP error -32000: Connection closed. Chrome never shows the consent dialog that would authorize the connection.

The same user profile works perfectly when accessed via the local gateway on the same machine.

Environment

• Gateway: OpenClaw 2026.3.24 on Ubuntu (AWS Lightsail VPS), bind=tailnet
• Node: OpenClaw 2026.3.24 on Ubuntu Desktop (marks-IT13), connected via Tailscale
• Chrome: 146.0.7680.164 (stable, not snap)
• Chrome remote debugging: Enabled via chrome://inspect/#remote-debugging
• Display: Wayland (Ubuntu desktop)

Steps to reproduce

1. Configure gateway with gateway.bind=tailnet
2. Connect a Linux desktop as a node host: openclaw node run --host <gateway-tailscale-ip> --port 18789
3. Node connects successfully, shows browser capability, browser.proxy command available
4. From gateway, invoke: openclaw nodes invoke --node <name> --command browser.proxy --params '{"path":"/tabs","query":{"profile":"user"},"method":"GET"}'

Expected

• The node host's browser service spawns chrome-devtools-mcp --autoConnect
• Chrome shows the consent/approval dialog on the desktop
• User accepts, connection established
• Gateway receives tab list via node proxy

Actual

• Node browser proxy attempts Chrome MCP existing-session attach
• Fails immediately with: BrowserProfileUnavailableError: Chrome MCP existing-session attach failed for profile "user". Details: McpError: MCP error -32000: Connection closed
• Chrome never shows the consent dialog
• The managed openclaw profile works fine through the same node proxy

Key observations

1. Local gateway on the same machine works: openclaw browser --browser-profile user tabs returns tabs correctly after consent is accepted
2. Manual MCP trigger works: Piping a JSON-RPC command directly into npx chrome-devtools-mcp@latest --autoConnect triggers the consent dialog and Chrome connects
3. Node proxy does not trigger consent: The node host's browser service spawns its own MCP server instance, but Chrome rejects the connection before showing consent — likely a timeout issue where the proxy gives up before Chrome can render the dialog
4. Chrome IS listening: ss -tlnp | grep 9222 confirms Chrome listening on 127.0.0.1:9222
5. Not a DISPLAY issue: Tested with explicit DISPLAY=:0 on the node host — same result
6. Not a Chrome version issue: Chrome 146 (well above 144 requirement)

Probable cause

The node browser proxy has a short timeout for the Chrome MCP handshake. The --autoConnect flow requires:

1. MCP server connects to Chrome's debug endpoint
2. Chrome shows consent dialog to user
3. User clicks Allow
4. MCP server completes handshake

The proxy appears to fail at step 1-2, timing out before Chrome can present the consent UI. The local gateway may have a longer timeout or different initialization path that allows the consent flow to complete.

Suggested fix

• Increase the timeout for Chrome MCP existing-session attach in the node browser proxy
• Or: allow the node browser proxy to reuse the local gateway's established MCP connection instead of spawning a new one
• Or: provide a way to pre-authorize the Chrome MCP connection so the consent dialog is not required on every new MCP server process

Related issues (chrome-devtools-mcp)

• Feature request: Allow persisting remote debugging permission approval ChromeDevTools/chrome-devtools-mcp#825 — Feature request for persisting remote debugging approval
• Long-running MCP sessions lose Chrome connection and trigger repeated approval prompts with --autoConnect ChromeDevTools/chrome-devtools-mcp#1094 — Long-running sessions trigger repeated approval prompts
• list_pages/new_page time out with ProtocolError: Network.enable timed out when using --autoConnect (Chrome 144, OpenCode) ChromeDevTools/chrome-devtools-mcp#870 — Timeouts with --autoConnect on Chrome 144