chrome Browser stopped working

[lost tulip]

Browser attach seems broken on OpenClaw 2026.4.11 on Linux.

Setup:

• browser plugin enabled
• browser.defaultProfile = "user"
• user.cdpUrl = "http://127.0.0.1:9223"
• openclaw profile also present

What happens:

• openclaw browser profiles shows openclaw and user
• openclaw browser --browser-profile user start
returns:
Chrome CDP websocket for profile "user" is not reachable after start
• if Chrome is manually launched with remote debugging, a blank window appears briefly, but:
openclaw browser --browser-profile user tabs
returns:
No tabs (browser closed or no targets)

Tried:

• port 9222, then moved to 9223
• restarted gateway after config change
• manually launched Chrome with remote debugging and fresh user-data-dir
•
retried browser start/tabs

Observed:

• config reload works
• OpenClaw sees 9223
• CDP websocket never becomes reachable
• browser may open briefly, then drops / shows no targets

Question:

• is this a known regression in 2026.4.11 for user browser attach on Linux?
• is there a required extra Chrome flag or different profile mode now?

[leaden sundial]

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

[slow gull]

I’m checking the current browser docs/source, because this smells more like attach mode changed than Chrome itself breaking.

Found the key distinction: OpenClaw now has two different “user browser” modes, and your config looks like it’s mixing them. Let me grab the exact Chrome MCP requirements too.

I don’t think this is a Linux-specific 2026.4.11 regression.

What it looks like is a mixed config.

user is now the built-in existing-session / Chrome MCP profile, not a raw CDP profile. So there are 2 different modes:

• user / driver: "existing-session"

  • do not set cdpUrl
  • do not use --remote-debugging-port
  • Chrome must be 144+
  • enable remote debugging in chrome://inspect/#remote-debugging
  • keep Chrome running with at least one tab open
  • accept the attach prompt

• raw CDP profile

  • use a separate profile like remote
  • set cdpUrl

• usually set attachOnly: true

So if you configured user.cdpUrl, that is probably the problem.

That also matches your symptoms:

• Chrome CDP websocket ... not reachable after start means OpenClaw is treating it like CDP/manage mode
• blank window flash
• then No tabs

Try one of these, not both:

browser: {
  defaultProfile: "user",
  profiles: {
    user: { driver: "existing-session", attachOnly: true }

  }
}

or:

browser: {
  defaultProfile: "remote",
  profiles: {
    remote: { cdpUrl: "http://127.0.0.1:9223", attachOnly: true }
  }
}

One more gotcha on 2026.4.11: if strict browser SSRF is enabled, loopback CDP attach may need both 127.0.0.1 and localhost in both: