Summary

The browser relay binds exclusively to 127.0.0.1 inside WSL2. Since Windows accesses WSL2 services via the VM's LAN IP (e.g. 172.17.x.x), the Chrome extension on Windows cannot connect to the relay, even when a netsh portproxy rule forwards 127.0.0.1:<port> on Windows to WSL2's LAN IP.

This is the same root cause as #27924 (Docker), but manifests differently in WSL2 environments.

Steps to reproduce

1. Install OpenClaw in WSL2 (Ubuntu)
2. Gateway starts, relay listens on 127.0.0.1:18792
3. Configure Windows netsh interface portproxy to forward 127.0.0.1:18792 → <WSL2 LAN IP>:18792
4. Install Chrome extension on Windows, set port to 18792 with correct gateway token
5. Extension reports: Relay not reachable/authenticated at http://127.0.0.1:18792/

Root cause

The relay binds to 127.0.0.1 (loopback) with no configuration option to change the bind address. The Windows portproxy connects to WSL2's LAN IP, but the relay is not listening on that interface.

Workaround

Use socat inside WSL2 to forward the LAN IP to loopback:

socat TCP-LISTEN:18792,bind=<WSL2_LAN_IP>,fork,reuseaddr TCP:127.0.0.1:18792

This makes the relay reachable on the LAN interface. Not ideal as a permanent solution (requires a persistent socat process).

Expected behavior

Either:

• A config option like browser.relay.host to set the bind address (e.g. 0.0.0.0)
• Or the relay should bind to 0.0.0.0 by default since it already requires token authentication for access control

Environment

• OS: Ubuntu 24.04 on WSL2 (Windows 11)
• OpenClaw version: 2026.3.2
• Chrome extension: Latest from Chrome Web Store
• Gateway port: 18789, Relay port: 18792

Related

• [Bug]: Chrome extension cannot connect to OpenClaw relay running in Docker (port 18792) #27924 — Same root cause in Docker environments