#has anyone gotten this Chrome CDP websocket fixed?

1 messages · Page 1 of 1 (latest)

rocky wing
#

Ever since the new update i cant get CDP to work. I do know others have had this issue. has anyone fixed it?

prisma jayBOT
#

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

pseudo orchidBOT
abstract gazelleBOT
#

Yeah, people have fixed it, but it’s been a few different bugs under the same “CDP is broken” symptom.

The common ones after recent updates are:

  1. plugins.allow is set and doesn’t include browser
  2. using user / existing-session across WSL2 ↔ Windows instead of raw remote CDP
  3. Linux snap Chromium, where the CDP websocket never comes up properly

Can you paste these first:

openclaw --version
openclaw status
openclaw browser status
openclaw gateway status
#

and the exact browser/CDP error line from openclaw logs --follow?

If your error is specifically CDP websocket ... not reachable, the fast check is:

# on the machine running Chrome
curl http://127.0.0.1:9222/json/version

# from the machine running OpenClaw/Gateway
curl http://<reachable-host>:9222/json/version

If that second one fails, OpenClaw won’t be able to attach either.

Docs:
https://docs.openclaw.ai/help/troubleshooting#browser-tool-fails
https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting

rocky wing
#

Here’s the current state.

openclaw --version

  • OpenClaw 2026.4.10 (44e5b62)

openclaw status

  • hangs from this shell

openclaw browser status

  • hangs from this shell

openclaw gateway status

  • service loaded
  • runtime running
  • RPC probe ok
  • loopback on 127.0.0.1:18789
#

Exact browser/CDP errors from .openclaw/logs/gateway.log:

  • 2026-04-11T01:44:26.444-04:00 ... Error: Failed to start Chrome CDP on port 18800 for profile "openclaw".
  • 2026-04-11T01:26:42.023-04:00 ... Error: Chrome CDP websocket for profile "openclaw" is not reachable after
    start.

Quick CDP checks:

What that means:

  • plugins.allow is not the problem
  • the gateway itself is up
  • the failing path is still the managed local openclaw browser profile
  • there is no stable raw CDP endpoint exposed on 9222
  • and when OpenClaw tries to launch its own managed CDP on 18800, it is not staying reachable
abstract gazelleBOT
#

That’s a really useful clue.

If openclaw gateway status says RPC probe ok, the gateway itself is up. The weirder part is openclaw browser status hanging, which usually means the browser layer is stuck trying to attach to a dead CDP target or a stale browser session is wedged.

I’d try this next:

openclaw health --verbose
openclaw doctor
openclaw logs --follow

Then in a second shell run:

openclaw browser status --json
#

and paste the first log/error line that appears.

Also, if you’re using a remote or attach-only profile, try:

openclaw browser stop --browser-profile <your-profile-name>

That does not kill the external browser, it just clears the active control/CDP session, and that has fixed stale websocket state for some people.

The other thing I need to know is which setup you’re on:

  • WSL2 gateway + Windows Chrome
  • Linux + Chromium/snap
  • local Chrome/Brave on the same machine as OpenClaw

Because the fix is different for each:

#

If you paste the logs --follow line plus which of those 3 setups you have, I can narrow it down pretty fast.

#

Yep, that narrows it down a lot.

This is not the remote CDP / websocket URL side anymore. The managed local openclaw browser process is failing before it ever binds port 18800. That’s why you get connection refused on 18800.

The two most common fixes for this exact symptom are:

  1. OpenClaw is trying to launch snap Chromium on Linux
  2. the browser needs noSandbox: true (common on VPS, containers, some Linux setups)

First check what binary it’s trying to use:

openclaw config get browser.executablePath
which google-chrome-stable google-chrome brave-browser chromium chromium-browser

If this is Ubuntu/Debian and it’s hitting chromium / chromium-browser

#

That’s very likely the snap wrapper. Recommended fix is to point OpenClaw at a real Chrome/Brave binary instead:

openclaw config set browser.executablePath "/usr/bin/google-chrome-stable"
openclaw config set browser.noSandbox true
# optional on headless boxes:
openclaw config set browser.headless true

openclaw gateway restart
openclaw browser start
curl http://127.0.0.1:18800/json/version

If Chrome isn’t installed, use Brave’s path instead if that’s what which returns.

If you must stay on snap Chromium

Use attach-only and launch Chromium manually instead: