#WSL2 to Windows Brave CDP works for discovery, but OpenClaw browser tabs fails at connectOverCDP tim

15 messages · Page 1 of 1 (latest)

wintry snow
#

On OpenClaw 2026.4.11, with the gateway in WSL2 and Brave on Windows exposed at http://172.22.240.1:9222, why do CDP discovery endpoints work but openclaw browser --browser-profile windows-brave tabs fails with browserType.connectOverCDP: Timeout 9000ms exceeded after websocket connect, and what is the correct fix to get full browser control and screenshots working?

pallid citrusBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

blazing rapidsBOT
#

Because /json/version and /json/list only prove the HTTP discovery layer is reachable. openclaw browser ... tabs then does a real Playwright connectOverCDP attach over the DevTools websocket, and that is the part that was misconfigured.

For WSL2 gateway + Windows Brave, the correct fix is:

  1. Do not use existing-session / user for this setup, that mode is host-local only.
  2. Use a raw remote CDP profile with cdpUrl pointed at the WSL2-reachable Windows address, and attachOnly: true.
  3. On 2026.4.11, set browser SSRF exceptions for the CDP hosts. In practice that meant allowing both the Windows IP and loopback names (localhost, 127.0.0.1) in both browser.ssrfPolicy.hostnameAllowlist and browser.ssrfPolicy.allowedHostnames. If private-network blocking is still on, also set dangerouslyAllowPrivateNetwork: true.

Working shape:

{
  browser: {
    enabled: true,
    defaultProfile: "windows-brave",
    ssrfPolicy: {
# 
      dangerouslyAllowPrivateNetwork: true,
      hostnameAllowlist: ["172.22.240.1", "localhost", "127.0.0.1"],
      allowedHostnames: ["172.22.240.1", "localhost", "127.0.0.1"],
    },
    profiles: {
      windows-brave: {
        cdpUrl: "http://172.22.240.1:9222",
        attachOnly: true,
        color: "#FB542B",
      },
    },
  },
}

Important detail, no driver field on that profile.

#

Then restart the gateway. If the old browser session is sticky, also run:

openclaw browser stop --browser-profile windows-brave

That is the setup that gets you full remote control, including tabs, snapshot, and screenshot.

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution, so Answer Overflow can index it.

wintry snow
#

Follow-up question:
We fixed the connectOverCDP timeout by relaunching Brave with remote debugging and using the remote CDP profile. openclaw browser --browser-profile windows-brave tabs now works and lists tabs correctly.
But both of these still fail with:

GatewayClientRequestError: browser navigation blocked by policy

Commands:
openclaw browser --browser-profile windows-brave snapshot
openclaw browser --browser-profile windows-brave open https://example.com

What policy is blocking navigation at this point, and what exact config change is needed to allow normal browser open/snapshot actions for this remote CDP profile?

blazing rapidsBOT
#

tabs working means the CDP endpoint policy is now fine.
What is still blocking you is the browser navigation SSRF policy, which is separate.

Why it happens:

  • tabs only needs CDP discovery / attach.
  • open and snapshot also validate the page URL.
  • In strict mode, if browser.ssrfPolicy exists and dangerouslyAllowPrivateNetwork is still unset/false, OpenClaw blocks normal hostname-based browser navigation unless the hostname is explicitly allowlisted.

So https://example.com gets blocked by the navigation policy, not the CDP profile.

Exact fix

Add this under browser.ssrfPolicy:

# 
dangerouslyAllowPrivateNetwork: true

So your working config should look like:

{
  browser: {
    enabled: true,
    defaultProfile: "windows-brave",
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: true,
      hostnameAllowlist: ["172.22.240.1", "localhost", "127.0.0.1"],
      allowedHostnames: ["172.22.240.1", "localhost", "127.0.0.1"],
    },
# 
    profiles: {
      windows-brave: {
        cdpUrl: "http://172.22.240.1:9222",
        attachOnly: true,
      },
    },
  },
}

Then restart the gateway.

Short version

  • Blocked policy: browser.ssrfPolicy navigation guard
  • Needed change: browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true
wintry snow
#

We already have browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true set in ~/.openclaw/openclaw.json, along with the hostname allowlists, and we already restarted the gateway.

Current state:
openclaw browser --browser-profile windows-brave tabs works
but openclaw browser --browser-profile windows-brave open https://example.com still fails with GatewayClientRequestError: browser navigation blocked by policy

So if dangerouslyAllowPrivateNetwork is already true, what exact additional config or condition would still cause navigation to be blocked by policy on 2026.4.11?

blazing rapidsBOT
#

Yep, the extra blocker is almost certainly browser.ssrfPolicy.hostnameAllowlist.

dangerouslyAllowPrivateNetwork: true only disables the private/internal IP guard.
It does not bypass the hostname allowlist.

So if you currently have something like:

browser: {
  ssrfPolicy: {
    dangerouslyAllowPrivateNetwork: true,
    hostnameAllowlist: ["172.22.240.1", "localhost", "127.0.0.1"],
    allowedHostnames: ["172.22.240.1", "localhost", "127.0.0.1"],
  }
}
#

then:

  • tabs works, because it only touches the CDP host 172.22.240.1
  • open https://example.com fails, because example.com is not in hostnameAllowlist
  • snapshot fails too if the current tab URL is on a hostname not in that allowlist

Exact fix

For normal browsing, either:

Option A, recommended

Remove hostnameAllowlist entirely and keep:

browser: {
  ssrfPolicy: {
# 
    dangerouslyAllowPrivateNetwork: true,
    allowedHostnames: ["172.22.240.1", "localhost", "127.0.0.1"],
  }
}

Option B

Keep hostnameAllowlist, but add every site you want to browse, for example:

hostnameAllowlist: [
  "172.22.240.1",
  "localhost",
  "127.0.0.1",
  "example.com",
# 
  "*.example.com"
]

So the key point is:

  • allowedHostnames = exact exceptions
  • hostnameAllowlist = real global hostname whitelist

If hostnameAllowlist is present, it still blocks example.com unless you add it.

If you remove hostnameAllowlist and it still behaves the same, then the next thing I'd check is config drift, meaning the daemon is not actually using the file you edited. openclaw gateway status is the best check for that.

Docs: