Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Remote CDP profile stays running: false even though /json/list shows live page targets on WSL2 + Windows Edge [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#64900•Fetched 2026-04-12 13:26:20
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
wy-sgwy-sg
Participants
neo1027144-creatorneo1027144-creatorwy-sgwy-sg
Timeline (top)
labeled ×2referenced ×2commented ×1cross-referenced ×1

On WSL2, OpenClaw Gateway can reach the Windows Edge CDP endpoint successfully. Both /json/version and /json/list work, and /json/list shows a live type: "page" target with a normal HTTPS URL. However, OpenClaw still reports the remote attach-only profile as running: false, tabs returns No tabs, and snapshot fails with Browser attachOnly is enabled and profile "remote" is not running.

Error Message

If /json/list already exposes a live page target, the remote attach-only profile should become usable for tabs / snapshot, or at least fail with a more specific attach/WebSocket error.

Root Cause

On WSL2, OpenClaw Gateway can reach the Windows Edge CDP endpoint successfully. Both /json/version and /json/list work, and /json/list shows a live type: "page" target with a normal HTTPS URL. However, OpenClaw still reports the remote attach-only profile as running: false, tabs returns No tabs, and snapshot fails with Browser attachOnly is enabled and profile "remote" is not running.

Fix Action

Fixed

PR fix notes

PR #65001: fix(browser): use remote-class timeouts for attachOnly loopback profiles [AI-assisted]

Description (problem / solution / changelog)

Summary

Fixes #64900.

attachOnly profiles pointing at a loopback address (e.g. a WSL2 gateway connecting to a Windows-host browser via 127.0.0.1) may cross a virtual network boundary where loopback-class timeouts (200–300 ms) are too tight, causing OpenClaw to incorrectly report running: false.

Root Cause

Two timeout paths were affected:

  1. listProfiles() used a hardcoded 200 ms timeout when probing via isChromeReachable(). For WSL2 → Windows host connections through the NAT virtual network stack, the first TCP handshake can take 300–800 ms, causing the probe to time out.

  2. createProfileAvailability() resolved timeouts via resolveCdpReachabilityTimeouts() using profileIsLoopback: true (because 127.0.0.1 is a loopback address). This gave loopback-class timeouts (300 ms HTTP / 600 ms WS) to all availability probes (isHttpReachable, isReachable, ensureBrowserAvailable), which are also too tight for the WSL2 NAT boundary — causing the snapshot command to throw "Browser attachOnly is enabled and profile "remote" is not running".

Changes

  • server-context.ts: listProfiles() now uses remoteCdpTimeoutMs (default 1500 ms) instead of the hardcoded 200 ms when probing attachOnly profiles. Non-attachOnly profiles keep the existing 200 ms.

  • server-context.availability.ts: When a profile is both attachOnly and cdpIsLoopback, treat it as effectively non-loopback for timeout resolution. This single change cascades through all reachability probes.

  • New test file: server-context.list-profiles-attach-only.test.ts — 5 tests covering both listProfiles() and ensureBrowserAvailable() timeout paths for attachOnly loopback profiles.

Testing

  • Unit tests: 9/9 pass — 5 new tests verify that both listProfiles() and ensureBrowserAvailable() correctly propagate remoteCdpTimeoutMs for attachOnly loopback profiles; 4 existing ensureBrowserAvailable tests confirm zero regression.
  • E2E latency simulation: On WSL2 Ubuntu 24.04, a 300 ms delay proxy in front of the Windows Edge CDP endpoint (Edg/146.0.3856.109 on port 9333) confirms the timeout behavior:
    • timeout 0.2 (original 200 ms) → exit 124 (timeout → running: false)
    • timeout 1.5 (our 1500 ms fix) → exit 0 (success → running: true)
npx vitest run "server-context.list-profiles-attach-only" "server-context.ensure-browser-available"

Changed files

  • extensions/browser/src/browser/server-context.availability.ts (modified, +5/-1)
  • extensions/browser/src/browser/server-context.list-profiles-attach-only.test.ts (added, +125/-0)
  • extensions/browser/src/browser/server-context.ts (modified, +7/-1)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On WSL2, OpenClaw Gateway can reach the Windows Edge CDP endpoint successfully. Both /json/version and /json/list work, and /json/list shows a live type: "page" target with a normal HTTPS URL. However, OpenClaw still reports the remote attach-only profile as running: false, tabs returns No tabs, and snapshot fails with Browser attachOnly is enabled and profile "remote" is not running.

Steps to reproduce

Environment:

OpenClaw 2026.4.10 Gateway in WSL2 Microsoft Edge on Windows Remote CDP on port 9222

Config:

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

I also tested:

"cdpUrl": "ws://127.0.0.1:9222/devtools/browser/<browser-id>"

with the same result.

Expected behavior

If /json/list already exposes a live page target, the remote attach-only profile should become usable for tabs / snapshot, or at least fail with a more specific attach/WebSocket error.

Actual behavior

curl http://127.0.0.1:9222/json/version succeeds. curl http://127.0.0.1:9222/json/list succeeds. /json/list includes a real page target like https://www.naver.com/ with type: "page". openclaw browser --browser-profile remote status shows: running: false browser: unknown detectedBrowser: unknown openclaw browser --browser-profile remote tabs says: No tabs (browser closed or no targets). openclaw browser --browser-profile remote snapshot fails with: Browser attachOnly is enabled and profile "remote" is not running.

OpenClaw version

2026.4.10

Operating system

Windows 11

Install method

wsl2 npm global

Model

openai-codex/gpt-5.2

Provider / routing chain

WSL2 OpenClaw Gateway -> browser plugin (remote attachOnly profile) -> CDP endpoint at 127.0.0.1:9222 -> Microsoft Edge on Windows host

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue might be resolved by adjusting the cdpUrl configuration to correctly establish a WebSocket connection for the remote attach-only profile.

Guidance

  • Verify that the cdpUrl is correctly formatted for a WebSocket connection, which typically starts with ws:// instead of http://.
  • Check the Microsoft Edge documentation to ensure the correct WebSocket endpoint is being used, as it may differ from the standard http://127.0.0.1:9222 endpoint.
  • Test the connection using a tool like wscat to verify that a WebSocket connection can be established to the specified cdpUrl.
  • Review the OpenClaw Gateway documentation to ensure that the attachOnly profile is correctly configured for remote connections.

Example

No specific code example can be provided without more information on the OpenClaw Gateway API, but the cdpUrl configuration might need to be adjusted to something like:

"cdpUrl": "ws://127.0.0.1:9222/devtools/browser/<browser-id>"

Replace <browser-id> with the actual browser ID obtained from the /json/list endpoint.

Notes

The provided information does not include specific error logs or detailed debugging output, which might be necessary to pinpoint the exact cause of the issue.

Recommendation

Apply workaround: Adjust the cdpUrl configuration to use the correct WebSocket endpoint, as this is likely the cause of the remote attach-only profile not being recognized as running.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If /json/list already exposes a live page target, the remote attach-only profile should become usable for tabs / snapshot, or at least fail with a more specific attach/WebSocket error.

#inference speed#output truncation#response parsing#generation error#database connection

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING