Bug type

Behavior bug (incorrect output/state without crash)

Summary

This scenario is working in practice (WSL2 gateway + Windows Chrome remote CDP), but diagnostics are currently misleading across layers. Multiple independent failures can produce overlapping symptoms, causing users to debug the wrong subsystem and spend hours before reaching a valid configuration.

Steps to reproduce

1. Run OpenClaw Gateway inside WSL2 with gateway.bind=lan.
2. Run Chrome on Windows with --remote-debugging-port=9222.
3. Expose CDP from Windows localhost to a reachable Windows LAN IP route (portproxy/firewall as needed).
4. In WSL2, test CDP reachability: curl http://WINDOWS_LAN_IP:9222/json/version.
5. Configure remote browser profile cdpUrl to that reachable endpoint.
6. Open Control UI from Windows localhost only: http://127.0.0.1:18789/openclaw/.
7. Try browser actions from CLI/UI.

Expected behavior

Control UI should authenticate cleanly on a secure origin, and remote browser actions should work once cdpUrl is reachable from WSL2. Errors should clearly identify which layer is failing.

Actual behavior

Observed overlapping errors during setup: gateway timeout after 1500ms, Remote CDP not reachable, token_missing, pairing required, control-ui-insecure-auth, and allowedOrigins/origin-related failures. Fixing one layer often still showed failures from another, causing misleading diagnosis.

OpenClaw version

2026.3.2

Operating system

Windows 10 22H2 (host) + WSL2

Install method

Gateway in WSL2 + Chrome on Windows remote CDP

Logs, screenshots, and evidence

Key evidence:

1. Control UI secure-context failure when opened via non-localhost origin:
- Repeated logs:
 control-ui-insecure-auth
 reason=control ui requires device identity (use HTTPS or localhost secure context)

2. Remote CDP unreachable before Windows routing/portproxy/firewall fix:
- Error:
 Remote CDP for profile "remote" is not reachable at http://WINDOWS_LAN_IP:9222

3. Proof that CDP became reachable from WSL2 after network fix:
- curl http://WINDOWS_LAN_IP:9222/json/version returned HTTP 200 with Chrome version and webSocketDebuggerUrl
- curl http://WINDOWS_LAN_IP:9222/json/list returned real page targets

4. Proof that browser control worked after correct config:
- openclaw browser open https://example.com --browser-profile remote
- openclaw browser tabs --browser-profile remote
- Real Chrome tabs appeared in Windows

5. Final working condition:
- Control UI opened from Windows via http://127.0.0.1:18789/openclaw/
- gateway.controlUi.allowedOrigins included http://127.0.0.1:18789
- remote browser profile pointed to reachable Windows CDP endpoint

Impact and severity

Affected: users running OpenClaw gateway in WSL2 with Chrome on Windows
Severity: Medium-High (setup appears broken for long periods)
Frequency: Reproducible during initial setup unless all routes/origins are exact
Consequence: Browser tool fails or appears inconsistent despite partial fixes

Additional information

This scenario is not fundamentally broken: it works once routing, origin, token, and browser profile are configured correctly.

The real problem is that multiple independent failures produce overlapping symptoms:

• Control UI secure-context/device-identity failures
• token/pairing failures
• remote CDP reachability failures
• browser profile mis-targeting

This makes users debug the wrong layer first and can make a working scenario appear completely broken for hours.

Suggested mitigation:

• add layered diagnostics
• detect WSL2 + Windows remote CDP setups more explicitly
• add an official WSL2 + Windows + Chrome remote CDP guide

Regression status unclear; main issue was misleading diagnostics during WSL2 + Windows + remote CDP setup.

The environment was ultimately functional. The main issue is not lack of capability, but that the current errors make different failure layers look the same, which significantly increases setup/debug time.