Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from 2026.4.10 to 2026.4.12, the managed browser profile (openclaw) no longer starts correctly in a Docker/Linux deployment.

The failure looks like an OpenClaw browser-management regression rather than a Chromium/runtime problem, because Chromium itself can start and expose CDP normally when launched manually inside the container.

Environment

• OpenClaw: 2026.4.12
• Previous known-good version: 2026.4.10
• Deployment: Docker on Linux
• Browser executable:
  • /home/node/.openclaw/browser-cache/chromium-current

Relevant config

"browser": {
  "enabled": true,
  "defaultProfile": "openclaw",
  "executablePath": "/home/node/.openclaw/browser-cache/chromium-current",
  "headless": true,
  "noSandbox": true,
  "profiles": {
    "openclaw": {
      "cdpPort": 18800,
      "color": "#FF4500"
    }
  }
}

Steps to reproduce

What was ruled out
Not a bad browser path
Not a broken symlink
Not unresolved shared library dependencies
Not stale Chromium lock files
Not old profile contamination
I tested:

removing SingletonCookie, SingletonLock, SingletonSocket, Default/LOCK
recreating /home/node/.openclaw/browser/openclaw/user-data
reinstalling browser dependencies and Chromium
None of those fixed the managed browser startup.

Strong signal that Chromium itself is fine
Launching Chromium manually inside the container works:

nohup /home/node/.openclaw/browser-cache/chromium-current
--headless
--no-sandbox
--disable-gpu
--disable-dev-shm-usage
--remote-debugging-port=18800
--remote-debugging-address=127.0.0.1
--user-data-dir=/home/node/.openclaw/browser/openclaw/user-data
--no-first-run
--no-default-browser-check
about:blank >/tmp/openclaw-browser.out 2>/tmp/openclaw-browser.err &
Then:

curl http://127.0.0.1:18800/json/version
returns valid JSON including Browser, Protocol-Version, and webSocketDebuggerUrl.

Chromium stderr also shows:

DevTools listening on ws://127.0.0.1:18800/...
Additional suspicious signal
CLI also returned:

GatewayClientRequestError: browser.request cannot mutate persistent browser profiles
That seems relevant because openclaw is a persistent OpenClaw-managed profile.

Attach-only test
I also tried browser.attachOnly: true.

Manual Chromium + CDP still worked, and OpenClaw could sometimes partially see it, but running-state recognition was unstable and later reported:

Browser attachOnly is enabled and profile "openclaw" is not running.
So attach-only is not a reliable workaround here.

Expected behavior

This command should start the managed browser profile successfully:

docker compose run --rm openclaw-cli browser --browser-profile openclaw start

Actual behavior

It fails with:

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

And browser status shows:

profile: openclaw
enabled: true
running: false
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: custom
detectedPath: ~/.openclaw/browser-cache/chromium-current

OpenClaw version

2026.04.12

Operating system

Debian GNU/Linux 11 x86_64

Install method

docker

Model

gpt-5.4

Provider / routing chain

openclaw→newapi→codex

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Current judgment
This looks most consistent with a regression in 2026.4.12 around one or more of:

managed browser launch
persistent profile handling
CDP readiness detection
attach-only running-state recognition
Request
Could you check whether 2026.4.12 introduced a regression in managed persistent browser profiles on Docker/Linux?

I can provide full logs and more details if helpful.