Summary

Improve layer-specific diagnostics for Control UI origin/auth state versus remote Chrome CDP reachability in WSL2 + Windows setups, so users can identify the failing layer faster and avoid misdirected troubleshooting.

Problem to solve

In WSL2 + Windows + remote Chrome CDP setups, multiple independent failures can present with very similar user-visible symptoms. This makes users debug the wrong layer and spend unnecessary time on unrelated issues.

This is not a request for a new browser capability. The setup can work correctly; the problem is diagnosability and UX clarity.

Real-world scenario:

• OpenClaw Gateway running inside WSL2
• Chrome running on Windows with remote debugging enabled
• Windows exposing a CDP endpoint that is reachable from WSL2
• Control UI opened from Windows localhost
• A remote browser profile targeting that reachable endpoint

Current behavior:

• Control UI secure-context / origin issues
• token / auth / pairing issues
• allowedOrigins misconfiguration
• remote CDP HTTP reachability failures
• browser profile pointing to the wrong cdpUrl
• stale Windows LAN IP after a network change, leaving the profile pointed at an old IP

A user can fix one layer and still keep seeing visible failures from another layer, which makes the system appear inconsistent or still broken.

Proposed solution

Surface diagnostics by layer in CLI and/or Control UI so users can immediately see whether failures are caused by:

• Control UI origin / secure-context state
• token / auth / pairing state
• allowedOrigins mismatch
• remote CDP reachability
• /json/version availability
• selected browser profile / target endpoint
• browser attach state / visible tabs / browser health

Possible improvements:

• Layered health panel in the Control UI
• Clearer, actionable error messages
• Explicit stale-IP detection for remote cdpUrl
• A troubleshooting command such as openclaw browser doctor

Example diagnostics:

• “Control UI is opened from a non-secure origin. Use localhost.”
• “Remote CDP endpoint is unreachable from WSL2.”
• “Remote browser profile points to an old host IP; check whether the Windows LAN IP changed.”
• “Token/auth is configured, but browser connection still fails because remote CDP is unreachable.”

Alternatives considered

Continue with generic cross-layer error signals and rely on manual, trial-and-error troubleshooting across UI origin, auth, and CDP connectivity. This is weaker because it prolongs debugging loops and obscures the actual failing layer.

Impact

Affected users/systems/channels:

• Users running OpenClaw Gateway in WSL2 with Chrome on Windows via remote CDP

Severity:

• Medium (capability can work, but troubleshooting is unnecessarily difficult and time-consuming)

Frequency:

• Intermittent, especially when network conditions or host IP/routing details change

Consequence:

• Repeated support/debugging loops
• Extra manual verification across unrelated layers
• Delayed resolution because users fix the wrong problem first

Evidence/examples

This request comes from real troubleshooting of a working WSL2 + Windows + remote Chrome CDP setup, where different failures produced overlapping symptoms and made the failing layer hard to identify.

Observed troubleshooting classes included:

• Control UI origin / secure-context issues
• token / auth / pairing issues
• allowedOrigins mismatch
• remote CDP endpoint not reachable from WSL2
• browser profile targeting the wrong or stale cdpUrl

Example diagnostics that would have reduced debugging time:

• “Control UI is opened from a non-secure origin. Use localhost.”
• “Remote CDP endpoint is unreachable from WSL2.”
• “Remote browser profile points to an old host IP; check whether the Windows LAN IP changed.”
• “Token/auth is configured, but browser connection still fails because remote CDP is unreachable.”

Additional information

Not reported as a regression.
Not requesting a brand-new browser capability.
Request scope: clearer, layer-specific diagnostics to distinguish UI/auth/origin issues from remote CDP reachability and profile-targeting issues.

This would complement existing troubleshooting documentation by making the failing layer more explicit in the product itself.