openclaw - 💡(How to fix) Fix Browser start reports CDP unreachable even while managed Chromium is live and /json/version responds [1 participants]

Summary

On this OpenClaw 2026.4.2 Linux host, the official managed browser lane for profile openclaw is degraded even though Chromium/CDP itself is healthy.

Environment

• OpenClaw: 2026.4.2
• Host: Linux VPS
• Browser config (effective baseline during investigation):
  • browser.enabled=true
  • browser.defaultProfile=openclaw
  • browser.executablePath=/home/openclaw/.cache/ms-playwright/chromium-1208/chrome-linux64/chrome
  • browser.headless=true
  • browser.noSandbox=true
  • browser.profiles.openclaw.cdpPort=18800
• Browser plugin enabled

What happens

openclaw browser start reports a browser start for profile openclaw, but the CLI then fails with:

• Chrome CDP websocket for profile "openclaw" is not reachable after start

Related observed states across attempts:

• openclaw browser status => running: false, browser: unknown, detectedBrowser: custom (or unknown when testing auto-detect), cdpPort: 18800
• openclaw browser tabs => either websocket-unreachable or No tabs (browser closed or no targets)
• openclaw browser open / snapshot can fail with PortInUseError: Port 18800 is already in use

Critical evidence

The important part is that Chromium/CDP is actually healthy during the failing window:

• OpenClaw logs lines like openclaw browser started (custom) profile "openclaw" on 127.0.0.1:18800 (pid ...)
• Parallel inspection during a failing openclaw browser start showed:
  • a live Chromium process tree still running after the failure window
  • a real listener on 127.0.0.1:18800
  • http://127.0.0.1:18800/json/version returns successfully
  • a valid webSocketDebuggerUrl is present

So the failure is not simply “browser did not launch” or “CDP is absent”. It looks more like OpenClaw’s managed-profile attach/validation/state logic falsely concludes the profile is unreachable.

Additional narrowing already done

The following were tested and did not resolve it:

• resetting/clearing the managed openclaw profile user-data (kept reversible backup)
• removing and re-adding browser.executablePath
• forcing explicit custom executable path again
• testing with a secondary openclaw-recovery profile aimed at the live CDP endpoint
• setting attachOnly: true on the managed profile

Manual launch with the same Chromium binary and the same official profile directory works, including live /json/version response. That points away from Chromium itself and toward OpenClaw’s own browser ownership/attach/probe path.

Impact

• Official browser lane unusable for SPA/client-rendered research and browser automation
• Degrades official-first research/navigation capability on this instance
• Forces reliance on weaker fallbacks (web_fetch, bundle inspection, etc.) for JS-heavy pages

Question

Could you clarify whether the managed openclaw profile is expected to support attach-only/live-CDP attach semantics, and whether there is a known regression in the CDP reachability/validation path on 2026.4.2 where the browser is actually up but OpenClaw still marks it unreachable?