Chrome CDP websocket not reachable on Windows 11 | Friends of the Crustacean 🦞🤝 | Page 1

cursive edge Apr 12, 2026, 9:47 PM

#

Chrome CDP websocket not reachable on Windows 11, Chrome 147, OpenClaw 2026.4.10. Chrome starts and responds on port 18800 via HTTP but websocket connection fails.

dreamy sirenBOT Apr 12, 2026, 9:47 PM

#

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

ruby charmBOT Apr 12, 2026, 9:47 PM

#

cursive edge Apr 12, 2026, 9:48 PM

#

OS: Windows 11, Chrome 147, OpenClaw 2026.4.10 (44e5b62)
Goal: Start browser control to automate a website
Error: Chrome CDP websocket for profile "openclaw" is not reachable after start
What happens: openclaw browser start launches Chrome (profile "openclaw", port 18800), Chrome opens visually, HTTP endpoint responds (/json/version and /json/list return 200), but openclaw browser snapshot still returns the same CDP error. Gateway is running via openclaw gateway run.
Question: Is there a known fix for CDP websocket connection failing on Windows 11 with Chrome 147?

chilly wolfBOT Apr 12, 2026, 9:49 PM

#

Let me verify the browser/CDP docs and the exact attach-only failure path, then I’ll give you the tightest next checks.

#

That specific OpenClaw error is pretty narrow: the HTTP CDP endpoint answered, but OpenClaw could not open the DevTools websocket.

A few likely causes, in order:

Wrong browser mode
- If OpenClaw and Chrome are on the same Windows machine, prefer existing-session / user instead of raw CDP.
- If OpenClaw is in WSL2 and Chrome is on Windows, use raw remote CDP with attachOnly: true, not existing-session.
The discovered WS URL is bad for your host setup
- Check:
```
curl http://127.0.0.1:18800/json/version
```
- Look at webSocketDebuggerUrl.
- If you’re using a remote profile, try setting browser.profiles.<name>.cdpUrl to that full ws://.../devtools/browser/... URL directly instead of the HTTP base URL.
Chrome 136+ remote debugging change

#

If you launch Chrome manually, use a non-default user data dir:
```
chrome.exe --remote-debugging-port=18800 --user-data-dir="%TEMP%\\openclaw-cdp"
```
- Chrome changed this for security, and it has bitten a lot of people since 136.

SSRF/private-network policy
- If your cdpUrl is not plain loopback, strict SSRF can block discovery/handshake.
- In strict mode, both browser.ssrfPolicy.allowedHostnames and browser.ssrfPolicy.hostnameAllowlist can matter.

Docs:

If you paste these, I can narrow it down fast:

#

pnpm openclaw --version
pnpm openclaw status --all
pnpm openclaw browser profiles

and also:

curl http://127.0.0.1:18800/json/version

Plus your browser config snippet, especially defaultProfile, profiles.<name>, cdpUrl, attachOnly, and whether this is Windows-only or WSL2 + Windows.

#

I’m checking whether this is a known regression in 2026.4.10 or more of a Chrome/Windows-specific launch quirk.

#

I don’t see a docs-listed Windows 11 + Chrome 147 one-line fix yet, but your symptom is pretty specific.

For the managed openclaw profile, OpenClaw already launches Chrome with its own --user-data-dir, so the Chrome 136+ remote-debugging hardening is probably not the blocker here.

What is happening is likely this:

OpenClaw sees /json/version respond, so Chrome looks “started”
then it does a stricter CDP readiness check over the browser websocket
that second step is what’s failing

Important nuance: HTTP 200 is not enough.
If /json/version is missing or returning a bad webSocketDebuggerUrl, you get exactly this pattern.

Can you paste the full body of:

#

curl http://127.0.0.1:18800/json/version

I especially want these fields:

Browser
Protocol-Version
webSocketDebuggerUrl

Also useful:

pnpm openclaw browser status --json
pnpm openclaw logs --follow

#

then in another shell:

pnpm openclaw browser start
pnpm openclaw browser snapshot

If webSocketDebuggerUrl is present and looks sane, then I’m leaning toward a managed-browser startup bug rather than bad config.

Fastest workaround, if you just need automation working now on the same Windows box:

try profile="user" / existing-session instead of the managed openclaw profile

Relevant docs:

If you paste the /json/version JSON, I can tell you pretty quickly whether this is Chrome-side or OpenClaw-side.

cursive edge Apr 12, 2026, 10:24 PM

#

PS C:\Users\pc> curl http://127.0.0.1:18800/json/version -UseBasicParsing | Select-Object -ExpandProperty Content
{
"Browser": "Chrome/147.0.7727.55",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"V8-Version": "14.7.173.16",
"WebKit-Version": "537.36 (@7dc2b8f6f651b42c0a8f3634c9feb5e0b6b25c91)",
"webSocketDebuggerUrl": "ws://127.0.0.1:18800/devtools/browser/02fdfe62-fba2-4572-9116-2f489792b2cb"
}

chilly wolfBOT Apr 12, 2026, 10:25 PM

#

Nice, that helps a lot.

That webSocketDebuggerUrl looks correct, so this is not the “HTTP is up but /json/version is missing the WS URL” case.

That narrows it to two likely buckets:

Chrome’s browser WS is there, but OpenClaw’s health check can’t complete
Something on Windows is blocking/breaking the local WS connection from Node to Chrome

The fastest split is to test the WS directly:

pnpm dlx wscat -c ws://127.0.0.1:18800/devtools/browser/02fdfe62-fba2-4572-9116-2f489792b2cb

Then send:

#

{"id":1,"method":"Browser.getVersion"}

Expected: a JSON result comes back.

If that works

Then Chrome’s CDP socket is healthy, and this starts looking like an OpenClaw bug/regression on the managed openclaw profile.

In that case, please grab:

pnpm openclaw logs --follow

then run:

#

pnpm openclaw browser start
pnpm openclaw browser snapshot

and paste the browser-related log lines.

If that fails

Then it’s likely Chrome/Windows/local security software/proxy interference, even though /json/version works.

Pragmatic workarounds:

try Edge or Brave via browser.executablePath
or use profile="user" / existing-session on the same machine if you just need automation working now

So, short answer: I don’t know a confirmed Chrome 147 + Windows 11 fix yet, but your case is now isolated enough that the direct wscat test should tell us whether this is a Chrome-side problem or an OpenClaw-side one.

If wscat succeeds, I’d call it bug-worthy and file it here with the logs + that /json/version output:

#

https://github.com/openclaw/openclaw/issues

cursive edge Apr 12, 2026, 10:25 PM

#

I found the webSocketDebuggerUrl: ws://127.0.0.1:18800/devtools/browser/02fdfe62-...
How do I tell OpenClaw to use this exact WS URL instead of trying to connect via HTTP base URL? create-profile --cdp-url gives browser.request cannot mutate persistent browser profiles. Where do I set browser.profiles.<name>.cdpUrl in the config?

chilly wolfBOT Apr 12, 2026, 10:27 PM

#

Yep, that has to go into config, not browser create-profile.

Two important bits:

Don’t overwrite openclaw
- Docs say the managed openclaw profile auto-assigns its local cdpPort/cdpUrl
- explicit cdpUrl is for remote/raw CDP profiles
That exact WS URL is temporary
- the /devtools/browser/<uuid> part usually changes each Chrome launch
- so this is useful as a diagnostic profile, not a permanent fix

Easiest way

First, find the active config file:

#

pnpm openclaw config file

Then add a separate profile, for example wsprobe:

pnpm openclaw config set browser.profiles.wsprobe.cdpUrl "ws://127.0.0.1:18800/devtools/browser/02fdfe62-fba2-4572-9116-2f489792b2cb"
pnpm openclaw config set browser.profiles.wsprobe.attachOnly true --strict-json
pnpm openclaw config set browser.profiles.wsprobe.color "#00AA00"

Because browser config changes need a restart, stop your current gateway run and start it again:

pnpm openclaw gateway run

#

Then test it with:

pnpm openclaw browser --browser-profile wsprobe snapshot

If you want to edit the file directly

The shape is:

{
  browser: {
    profiles: {
      wsprobe: {
        cdpUrl: "ws://127.0.0.1:18800/devtools/browser/02fdfe62-fba2-4572-9116-2f489792b2cb",

#Chrome CDP websocket not reachable on Windows 11

If that works

If that fails

Easiest way

If you want to edit the file directly