Summary

In WSL2-to-Windows setups, when a CDP probe gets an empty reply through a netsh portproxy, OpenClaw's diagnostic asserted a single cause — a stale 127.0.0.1:9222 -> 127.0.0.1:9222 self-loop owned by svchost/iphlpsvc. As of Chrome 136+, a second cause produces the identical empty reply: Chrome ignores --remote-debugging-address and binds the CDP listener to [::1]:9222 (IPv6 loopback) only, so a v4tov4 portproxy forwarding to 127.0.0.1:9222 reaches nothing. Users following the old hint went looking for a self-loop that wasn't there, while the real fix is a v4tov6 portproxy.

This PR makes the empty-reply hint name both causes and tell the user to run netstat -ano | findstr :9222 to disambiguate, and documents the IPv6-binding case + v4tov6 remedy in the dedicated WSL2 remote-CDP troubleshooting guide.

Why guidance, not an auto-probe

Issue suggestion (2) proposed having OpenClaw probe both 127.0.0.1:9222 and [::1]:9222. In the reported topology the gateway runs in WSL2 and Chrome runs on Windows behind the portproxy, so [::1] from WSL2 is WSL2's own loopback, not Windows Chrome — OpenClaw cannot reach the Windows IPv6 listener to auto-detect this. The actionable improvement OpenClaw can make from the WSL2 side is to stop pointing users at the wrong cause and surface the correct remedy. Suggestion (1), the doc update, is implemented.

Changed surface

• extensions/browser/src/browser/chrome.diagnostics.ts — formatChromeCdpDiagnostic empty-reply hint now names both causes (self-loop and Chrome 136+ IPv6 binding) and the v4tov6 fix. Extracted to a commented WSL_EMPTY_REPLY_PORTPROXY_HINT constant.
• docs/tools/browser-wsl2-windows-remote-cdp-troubleshooting.md — new "Chrome 136+ binds CDP to IPv6 loopback" section under Layer 1 + a clue in "Common misleading errors".

This is additive diagnostic text + docs. The CDP connection path itself is unchanged.

Verification

Real environment tested: Linux/WSL2; reproduced the field report's IPv4-vs-IPv6 split and the empty-reply diagnostic with real loopback servers (no Windows Chrome required to drive the diagnostic path under test).

Reproduction of the field-report signature — a server bound to [::1] only (mirroring Chrome 136+) answers on IPv6 but not IPv4, exactly as reported (curl.exe http://[::1]:9222 200 vs 127.0.0.1:9222 empty/refused):

Chrome (IPv6-only) listening on [::1]:35865
[::1]: HTTP 200
127.0.0.1: FAIL ECONNREFUSED
portproxy empty-reply fetch error message: other side closed

Diagnostic behavior, before → after — a TCP server that accepts then closes the socket reproduces the portproxy empty-reply. diagnoseChromeCdp("http://127.0.0.1:<port>") returns http_unreachable ("other side closed"), and formatChromeCdpDiagnostic is asserted in a live end-to-end test:

• Before the fix (hint reverted), the real probe emits only the self-loop cause and the new assertions fail:

  AssertionError: expected 'CDP diagnostic: http_unreachable ... ' to contain 'v4tov6'
  Received: "... stale netsh portproxy self-loop where svchost/iphlpsvc owns the CDP port ... 127.0.0.1:9222 -> 127.0.0.1:9222 portproxy rule."
  

• After the fix, the hint names the IPv6 binding cause and v4tov6 remedy. Existing self-loop substrings preserved.

Exact commands run after this patch:

pnpm test extensions/browser/src/browser/chrome.test.ts   # 51 passed (incl. new live empty-reply test)
pnpm tsgo:extensions                                       # clean
npx oxfmt --check --threads=1 <changed .ts files>          # clean
node scripts/format-docs.mjs --check <changed doc>         # clean

What was not tested: I could not exercise the genuine Chrome 136+ Windows binding (no Windows host with Chrome 136+ in this environment); the IPv6-only listener is simulated with a real [::1]-bound server that produces the same observable IPv4/IPv6 split and empty-reply diagnostic. pnpm docs:check-links:anchors could not run locally (missing @mintlify/scraping transitive dep + network); the new same-page anchor #chrome-136-binds-cdp-to-ipv6-loopback was verified by hand against the heading slug.

AI-assisted; all proof above was produced by real local runs.

Closes #54669