WSL2: Control Windows Browsers
Crossing the Bridge
Running OpenClaw in WSL2 while using your Windows-native Chrome/Edge/Brave is the most efficient setup. However, it requires bypassing the default localhost isolation.
To enable browser control in WSL2, you have two primary options: using the Extension Relay (easiest) or direct CDP mapping.
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Option 1: Extension Relay (Recommended)
The Extension Relay is the most stable way to bridge WSL2 and Windows. It works by having the OpenClaw Gateway in WSL2 talk to the browser via a WebSocket.
- 1.Install the OpenClaw Extension in your Windows browser.
- 2.In WSL2, run
openclaw gateway start. - 3.By default, WSL2 sees the Windows host as
localhostfor certain ports, but if it fails, use the WSL Bridge IP.
Option 2: Direct Executable Path
If you want OpenClaw to launch a fresh browser instance, you must point it to the .exe file on the Windows partition using the /mnt/c/ path.
Update openclaw.json
"browser": {
"config": {
"executablePath": "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
}
}Networking (The common "Timeout" fix)
If the browser extension shows "Disconnected", WSL2 might be unable to reach the gateway port on Windows. Ensure your firewall allows port 18789.
New-NetFirewallRule -DisplayName 'OpenClaw Gateway' -Direction Inbound -LocalPort 18789 -Protocol TCP -Action Allow
Check Connection
Run this inside WSL2 to verify you can see the Windows-side browser relay:
curl http://$(hostname).local:18789/health
Did this guide solve your problem?