Browser CDP issue on Windows — OpenClaw 2026.4.11

[lime sigil]

Symptom: browser tool always fails with "Chrome CDP websocket for profile "openclaw" is not reachable after start" — even when Playwright Chromium is already running and listening on port 18800.

Confirmed working: Playwright + Chromium installed in openclaw's node_modules. Gateway log shows Chrome launches with a pid. Manually launching the same binary works fine and CDP responds at /json/version immediately.

Problem: The spawned process exits within ~8 seconds. Even with a Chromium already on port 18800, the browser tool spawns a new one instead of attaching, which then also fails.

Tried: noSandbox: true, remoteCdpHandshakeTimeoutMs: 15000, profiles.openclaw.attachOnly: true + cdpPort: 18800, killed all Chrome processes first. Nothing works.

Also: cron tool and openclaw browser CLI get pairing required (scope-upgrade: operator.read → operator.admin) from within agent sessions — is that expected?

[deft heron]

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

[stark lichen]

A couple things jump out.

1. The ~8 second exit is probably OpenClaw killing the spawned browser after CDP websocket readiness fails.
   /json/version being up is not enough, the DevTools websocket also has to attach cleanly.

2. If this is an externally managed browser, I would not overload the managed openclaw profile.
   Create a separate remote profile with an explicit cdpUrl and attachOnly: true, then target that profile:

{
  browser: {
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://<address reachable from the gateway host>:18800",
        attachOnly: true

      }
    }
  }
}

If the Gateway is in WSL2, 127.0.0.1 is wrong here, use the Windows host IP that WSL2 can reach.

3. If OpenClaw is still spawning a new browser, then attachOnly is probably not in the effective config. Please paste:

openclaw --version
openclaw config get browser
openclaw gateway status

4. If you enabled strict browser SSRF, CDP discovery can get blocked. For localhost targets, I’ve seen people need both:

browser: {
  ssrfPolicy: {
    allowedHostnames: ["localhost", "127.0.0.1"],
    hostnameAllowlist: ["localhost", "127.0.0.1"]
  }
}

5. On the pairing question, yes, mostly expected:

• cron list/status/runs are read-scoped
• cron add/update/remove/run are admin-scoped, so the scope-upgrade is expected there
• browser.request itself is write-scoped, but if you run openclaw browser ... inside an agent via CLI/exec, that path usually goes through system-run/exec and can require operator.admin

Docs: