openclaw - 💡(How to fix) Fix Windows node-host browser path ignores explicit CDP profile and still forces DevToolsActivePort / Chrome MCP attach [1 participants]

Summary

When running OpenClaw with:

• Gateway on a VPS
• Windows machine connected via openclaw node
• Chrome on Windows launched with --remote-debugging-port=9222

The browser runtime still tries to attach via Chrome MCP / DevToolsActivePort instead of honoring an explicit cdpUrl profile routed through the node host.

This blocks using a VPS-hosted OpenClaw gateway to control an existing Windows browser session even after the Windows node host is correctly installed and connected.

Environment

Gateway host

• Linux VPS
• OpenClaw 2026.4.20

Windows host

• Windows desktop
• OpenClaw CLI 2026.4.21
• OpenClaw Tray installed
• dedicated node host also installed via openclaw node install

Goal

• control an existing Windows desktop browser session from a VPS-hosted OpenClaw gateway

Findings

1) Tray app alone is not enough

The Windows tray app connects as a node, but logs show it only registers:

• system
• canvas
• screen
• camera

It does not register browser capability.

2) Correct Windows-side component is the dedicated node host

Installing and starting:

openclaw node install
openclaw node run --host canycom.fromanclaw.com --port 443 --tls

created a pending pairing request, which was approved on the gateway. After approval, the node host stayed connected.

3) Chrome debug port is live

On Windows, Chrome was launched with:

& "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

Confirmed with:

netstat -ano | findstr 9222

Result:

TCP 127.0.0.1:9222 0.0.0.0:0 LISTENING <pid>

So Chrome CDP is available.

4) Existing-session path fails on DevToolsActivePort

Browser requests through the node host consistently fail with:

Could not connect to Chrome. Check if Chrome is running.
Cause: Could not find DevToolsActivePort for chrome at
C:\Users\Canycom Nick\AppData\Local\Google\Chrome\User Data\DevToolsActivePort

This happens even though Chrome is running and CDP port 9222 is listening.

5) Explicit CDP profile still does not get honored

On the gateway, the browser profile was changed from existing-session to explicit CDP:

"browser": {
  "profiles": {
    "user": {
      "cdpUrl": "http://127.0.0.1:9222",
      "attachOnly": true,
      "color": "#34A853"
    }
  }
}

Also verified in the distributed code that driver=existing-session cannot accept cdpUrl, so the profile was changed to pure CDP mode.

Despite that, browser requests routed to the Windows node still fail with the same DevToolsActivePort / Chrome MCP attach error, suggesting the runtime is still choosing the wrong attach mode.

Expected behavior

When a browser profile is configured with:

{
  "cdpUrl": "http://127.0.0.1:9222",
  "attachOnly": true
}

and used through a connected Windows node host, the browser runtime should:

• treat it as a raw CDP profile
• connect to the configured CDP endpoint
• not require Chrome MCP / DevToolsActivePort

Actual behavior

Even after switching the profile away from existing-session, the browser runtime still appears to:

• use Chrome MCP attach logic
• look for DevToolsActivePort
• fail before trying the explicit CDP endpoint

Why this matters

This blocks a very important topology:

• OpenClaw gateway on VPS
• user’s real browser on Windows desktop
• browser control routed through Windows node host

Right now, the architecture appears partly supported, but the browser runtime does not honor the intended attach mode correctly.

Strong suspicion

One of these is likely true:

1. Node-host browser proxy currently forces/assumes Chrome MCP for certain profiles
2. Profile resolution through node-host transport is ignoring the updated raw-CDP profile config
3. There is a regression/bug in browser profile capability resolution when routed through a remote node

Repro sketch

1. Run gateway on VPS
2. Install Windows tray app
3. Install Windows dedicated node host:

   openclaw node install
   openclaw node run --host canycom.fromanclaw.com --port 443 --tls

4. Approve pairing on gateway
5. Launch Chrome with:

   chrome.exe --remote-debugging-port=9222

6. Confirm:

   netstat -ano | findstr 9222

7. Configure gateway browser profile:

   "user": {
     "cdpUrl": "http://127.0.0.1:9222",
     "attachOnly": true
   }

8. Attempt browser status/action via node host
9. Observe runtime still failing on DevToolsActivePort