WSL2 + Windows + remote Chrome CDP troubleshooting

In the common split-host setup, OpenClaw Gateway runs inside WSL2, Chrome runs on Windows, and browser control must cross the WSL2 and Windows boundary. The layered failure pattern from issue #39369 means several independent problems can show up at once, which makes the wrong layer look broken first.

Choose the right browser mode first

You have two valid patterns:

Option 1: Raw remote CDP from WSL2 to Windows

Use a remote browser profile that points from WSL2 to a Windows Chrome CDP endpoint.

Choose this when:

the Gateway stays inside WSL2
Chrome runs on Windows
you need browser control to cross the WSL2/Windows boundary

Option 2: Host-local Chrome MCP

Use existing-session / user only when the Gateway itself runs on the same host as Chrome.

Choose this when:

OpenClaw and Chrome are on the same machine
you want the local signed-in browser state
you do not need cross-host browser transport
you do not need advanced managed/raw-CDP-only routes like responsebody, PDF export, download interception, or batch actions

For WSL2 Gateway + Windows Chrome, prefer raw remote CDP. Chrome MCP is host-local, not a WSL2-to-Windows bridge.

Working architecture

Reference shape:

WSL2 runs the Gateway on 127.0.0.1:18789
Windows opens the Control UI in a normal browser at http://127.0.0.1:18789/
Windows Chrome exposes a CDP endpoint on port 9222
WSL2 can reach that Windows CDP endpoint
OpenClaw points a browser profile at the address that is reachable from WSL2

Why this setup is confusing

Several failures can overlap:

WSL2 cannot reach the Windows CDP endpoint
the Control UI is opened from a non-secure origin
gateway.controlUi.allowedOrigins does not match the page origin
token or pairing is missing
the browser profile points at the wrong address

Because of that, fixing one layer can still leave a different error visible.

Critical rule for the Control UI

When the UI is opened from Windows, use Windows localhost unless you have a deliberate HTTPS setup.

Use:

http://127.0.0.1:18789/

Do not default to a LAN IP for the Control UI. Plain HTTP on a LAN or tailnet address can trigger insecure-origin/device-auth behavior that is unrelated to CDP itself. See Control UI.

Validate in layers

Work top to bottom. Do not skip ahead.

Layer 1: Verify Chrome is serving CDP on Windows

Start Chrome on Windows with remote debugging enabled:

powershell

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

From Windows, verify Chrome itself first:

powershell

curl http://127.0.0.1:9222/json/version
curl http://127.0.0.1:9222/json/list

If this fails on Windows, OpenClaw is not the problem yet.

Layer 2: Verify WSL2 can reach that Windows endpoint

From WSL2, test the exact address you plan to use in cdpUrl:

bash

curl http://WINDOWS_HOST_OR_IP:9222/json/version
curl http://WINDOWS_HOST_OR_IP:9222/json/list

Good result:

/json/version returns JSON with Browser / Protocol-Version metadata
/json/list returns JSON (empty array is fine if no pages are open)

If this fails:

Windows is not exposing the port to WSL2 yet
the address is wrong for the WSL2 side
firewall / port forwarding / local proxying is still missing

Fix that before touching OpenClaw config.

Layer 3: Configure the correct browser profile

For raw remote CDP, point OpenClaw at the address that is reachable from WSL2:

json5

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://WINDOWS_HOST_OR_IP:9222",
        attachOnly: true,
        color: "#00AA00",
      },
    },
  },
}

Notes:

use the WSL2-reachable address, not whatever only works on Windows
keep attachOnly: true for externally managed browsers
cdpUrl can be http://, https://, ws://, or wss://
use HTTP(S) when you want OpenClaw to discover /json/version
use WS(S) only when the browser provider gives you a direct DevTools socket URL
test the same URL with curl before expecting OpenClaw to succeed

Layer 4: Verify the Control UI layer separately

Open the UI from Windows:

http://127.0.0.1:18789/

Then verify:

the page origin matches what gateway.controlUi.allowedOrigins expects
token auth or pairing is configured correctly
you are not debugging a Control UI auth problem as if it were a browser problem

Helpful page:

Control UI

Layer 5: Verify end-to-end browser control

From WSL2: