Troubleshoot OpenClaw WSL2 and Windows Chrome Connections

Ever spent hours trying to get your WSL2 environment to talk to a browser running on your Windows host? It is one of those setups that feels like it should just work, but then you hit a wall of connection errors and timeout messages. It is frustrating when you are just trying to automate some browser tasks and the networking gets in the way.

This guide covers the common split-host setup where OpenClaw Gateway runs inside WSL2 while Chrome runs on Windows. In this scenario, browser control must cross the WSL2/Windows boundary. We will also look at the layered failure pattern from issue #39369, where several independent problems can show up at once, making the wrong layer look broken first.

Choose the right browser mode first

You have two valid patterns to choose from:

Option 1: Raw remote CDP

Use a remote browser profile that points from WSL2 to a Windows Chrome CDP endpoint. Choose this when:

• you only need browser control and are comfortable exposing Chrome remote debugging to WSL2
• you do not need the Chrome extension relay

Option 2: Chrome extension relay

Use the built-in chrome profile plus the OpenClaw Chrome extension. Choose this when:

• you want to attach to an existing Windows Chrome tab with the toolbar button or want extension-based control
• the relay itself must be reachable across the WSL2/Windows boundary

If you use the extension relay across namespaces, browser.relayBindHost is the important setting introduced in Browser and Chrome extension.

Working architecture

Here is the reference shape for a successful setup:

• 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 and OpenClaw points a browser profile at it

Why this setup is confusing

Several failures can overlap, which is why it gets tricky:

• 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
• the extension relay is still loopback-only when you actually need cross-namespace access

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

Critical rule for the Control UI

When you open the UI 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

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

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

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

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

{
  browser: {
    enabled: true,
    defaultProfile: "chrome",
    relayBindHost: "0.0.0.0",
  },
}

openclaw browser open https://example.com --browser-profile remote
openclaw browser tabs --browser-profile remote

openclaw browser tabs --browser-profile chrome