Bug type

Behavior bug / Documentation gap

Summary

Chrome 147+ binds --remote-debugging-port to IPv6 [::1] only, not IPv4 127.0.0.1. The existing WSL2 troubleshooting docs recommend v4tov4 portproxy which forwards to IPv4 — this no longer works with Chrome 147.

Steps to reproduce

1. Run Chrome 147 on Windows with --remote-debugging-port=9222
2. Configure v4tov4 portproxy per docs: netsh interface portproxy add v4tov4 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=127.0.0.1
3. From WSL2: curl http://<windows-ip>:9222/json/version → Empty reply (exit code 52)
4. From Windows: curl http://127.0.0.1:9222/json/version → Empty reply
5. From Windows: curl http://[::1]:9222/json/version → 200 OK, returns JSON

Expected behavior

curl http://127.0.0.1:9222/json/version should return Chrome DevTools JSON, as it did in Chrome 146 and earlier.

Actual behavior

Chrome 147 only responds on [::1]:9222 (IPv6 loopback). IPv4 connections are accepted (TCP handshake completes) but Chrome returns empty responses.

Fix

Use v4tov6 portproxy instead of v4tov4:

netsh interface portproxy delete v4tov4 listenport=9222 listenaddress=0.0.0.0
netsh interface portproxy add v4tov6 listenport=9222 listenaddress=0.0.0.0 connectport=9222 connectaddress=::1

Additionally, Chrome 147 requires --user-data-dir to be a non-default directory for CDP HTTP endpoints to respond:

chrome.exe --remote-debugging-port=9222 --remote-debugging-address=0.0.0.0 --user-data-dir="C:\ChromeDebug" --no-first-run --remote-allow-origins="*"

Without --user-data-dir, Chrome shows LISTENING on port 9222 but returns empty replies to all HTTP requests.

Diagnosis tips

1. If netstat shows LISTENING on 9222 but curl http://127.0.0.1:9222/json/version returns empty → test IPv6: curl http://[::1]:9222/json/version
2. If IPv6 works but IPv4 doesn't → Chrome 147 IPv6-only binding, use v4tov6 portproxy
3. If neither works → Chrome needs --user-data-dir pointing to a non-default directory

Suggested doc update

The WSL2 troubleshooting page (https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting) should be updated to:

1. Note Chrome 147+ IPv6-only CDP binding
2. Recommend v4tov6 portproxy instead of v4tov4
3. Note the --user-data-dir requirement for CDP to respond

OpenClaw version

2026.4.15

Operating system

Windows 11 + WSL2 (Ubuntu)

Install method

Gateway in WSL2 + Chrome 147 on Windows via remote CDP