Skip to content

[Field Report] Chrome 136+ binds CDP to [::1] (IPv6) on Windows — portproxy v4tov4 breaks silently #54669

@Owlock

Description

@Owlock

OpenClaw version: 2026.3.13 (61d171a) → updated recently to latest
OS: Windows 10 x64 + WSL2
Chrome version: 146.0.7680.154
Reported by: @Owlock (contributor, PR #39407 merged)


Summary

After a PC reboot, openclaw browser tabs --browser-profile remote returned no tabs.
Root cause: Chrome 136+ on Windows ignores --remote-debugging-address=127.0.0.1 and binds CDP to [::1]:9222 (IPv6 loopback) instead of 127.0.0.1:9222 (IPv4). The existing portproxy v4tov4 → 127.0.0.1:9222 fails silently because Chrome no longer listens on that IPv4 address. No error is surfaced by OpenClaw diagnostics.


Diagnosis steps

curl.exe http://[::1]:9222/json/version # → 200 OK ✅
curl.exe http://127.0.0.1:9222/json/version # → curl: (52) Empty reply ❌

netstat -ano | findstr :9222
# TCP [::1]:9222 LISTENING <chrome_pid> ← IPv6 only

Fix

Replace v4tov4 portproxy rules with v4tov6 pointing to ::1. PowerShell Admin (one by one):

netsh interface portproxy reset
netsh interface portproxy add v4tov6 listenaddress=127.0.0.1 listenport=9222 connectaddress=::1 connectport=9222
netsh interface portproxy add v4tov6 listenaddress=172.30.144.1 listenport=9222 connectaddress=::1 connectport=9222

After this, both curl.exe http://127.0.0.1:9222/json/version and curl.exe http://172.30.144.1:9222/json/version return Chrome JSON correctly.


Why this happens

Chrome has been hardening remote debugging security since v136. The --remote-debugging-address flag is now ignored internally. On Windows, Chrome resolves localhost as IPv6-first (::1), so the CDP listener ends up on [::1] rather than 127.0.0.1.

Reference: https://developer.chrome.com/blog/remote-debugging-port


Suggested improvements to OpenClaw

  1. Doc update: The WSL2 + Windows CDP guide (PR docs: add WSL2 + Windows remote Chrome CDP troubleshooting guide #39407) should note that on Chrome 136+, netstat -ano | findstr :9222 should be run to detect IPv4 vs IPv6 binding, and portproxy should use v4tov6 accordingly.

  2. openclaw doctor enhancement: Add a check that tests both 127.0.0.1:9222 AND [::1]:9222 — the current silent failure gives no hint that Chrome changed its binding address.

Note: Windows Test Mode (TESTSIGNING ON) was confirmed to have no effect on this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions