OpenClaw Browser Screenshot Can Time Out on WSL2 When Using Remote CDP (v2026.3.23)

A WSL2 setup that connects to Windows Chrome via remote CDP can hit a frustrating failure mode after upgrading to OpenClaw 2026.3.23:

Browser snapshot (accessibility-tree / text mode) works
CDP HTTP endpoints work (OpenClaw can list tabs)
But browser screenshot consistently times out

Source:

Issue report: openclaw/openclaw#54148

Who this affects

This is most likely to affect you if your setup looks like:

Chrome runs on Windows with --remote-debugging-port=9222
OpenClaw runs inside WSL2 (Ubuntu on Windows 11)
Your OpenClaw browser profile uses a remote endpoint, e.g.:

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

How to confirm you’re hitting this specific regression

From inside WSL2:

Confirm the CDP HTTP endpoint is reachable:

curl http://127.0.0.1:9222/json/version

If this returns JSON, CDP is reachable at the HTTP layer.

Confirm OpenClaw can use CDP for non-screenshot operations:

If browser snapshot works but browser screenshot times out, your CDP reachability is not the main problem.

(Optional) Prove that screenshots are possible over the CDP WebSocket outside OpenClaw

In the issue report, a direct CDP WebSocket call to Page.captureScreenshot succeeds and returns a valid PNG, which strongly suggests:

Chrome is capable of capturing screenshots in this environment
The OpenClaw screenshot path is where the timeout is happening

A common trap: the “existing-session” driver on WSL2

The issue reporter also tried an “existing-session” driver config and saw an error about DevToolsActivePort.

That’s expected if your Chrome runs on Windows:

DevToolsActivePort is a local file created by a locally-launched Chrome process
It won’t exist inside WSL2 when Chrome is launched on the Windows side

So for WSL2 → Windows Chrome, you typically want a remote CDP URL flow, not a local attach-by-file flow.

Practical workarounds (until a fix ships)

Workaround A) Use snapshot (text mode) where possible

If your automation or debugging does not strictly require PNG output, using browser snapshot can keep you moving.

Workaround B) Pin to a known-good OpenClaw version

If screenshots are business-critical, consider rolling back to the last version that worked for your environment.

In the issue report, the regression appears when upgrading from v2026.3.13 to v2026.3.23.

Workaround C) Capture screenshots outside OpenClaw (direct CDP)

If you can tolerate a temporary workaround, capture screenshots with a standalone CDP client (the issue report used a Python WebSocket client calling Page.captureScreenshot).

This is not ideal, but it isolates the screenshot step while you keep the rest of your OpenClaw flows intact.

What to include when reporting / escalating

If you want maintainers to reproduce faster, include:

OpenClaw version + commit hash
WSL2 distro + Windows version
Chrome version + the exact Chrome launch flags
Your browser profile config (cdpUrl, attachOnly, and driver if any)
Whether /json/version works
Whether snapshot works
Whether direct Page.captureScreenshot works via CDP WebSocket

Fast triage checklist for on-call teams

If screenshots suddenly start timing out after an upgrade, check these points in order before you rewrite your browser setup:

confirm /json/version still responds from inside WSL2
confirm browser snapshot still works against the same remote profile
compare the current OpenClaw version against the last version where screenshots worked
test one direct CDP Page.captureScreenshot call outside OpenClaw to separate Chrome capability from OpenClaw regression
record whether the timeout only affects screenshot or also affects snapshot and tab listing

This five-step split helps teams avoid mixing together network reachability, Chrome launch, and OpenClaw-specific screenshot regressions.

Source

openclaw/openclaw#54148