DASHBOARD NOT OPENING | Friends of the Crustacean 🦞🤝 | Page 1

carmine meadow Apr 29, 2026, 1:28 PM

#

when i run gateway it runs perfectly in WSL2 but when i do "openclaw dashboard" it generates a link with auth token but when i paste it in any browser it dont get open , why????

earnest swallowBOT Apr 29, 2026, 1:28 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

silent craterBOT Apr 29, 2026, 1:30 PM

#

Likely WSL2 networking, not the token.

First: what version?

openclaw --version

Then in WSL run:

openclaw gateway status
openclaw status
curl -I http://127.0.0.1:18789/

If that curl works, try this in Windows PowerShell:

#

curl.exe -I http://127.0.0.1:18789/

How to read it:

WSL curl fails → gateway isn’t actually reachable; run openclaw logs --follow / openclaw doctor.
WSL curl works, PowerShell/browser fails → Windows ↔ WSL localhost forwarding/firewall issue.
PowerShell works but browser doesn’t → browser/cache/extension/proxy issue; try http://127.0.0.1:18789/ manually, then paste the token in the Control UI auth field if prompted.

Also: the dashboard URL is meant for the same machine. If you’re opening it from another PC/phone, 127.0.0.1 points to that other device, not your WSL gateway. Use Tailscale or an SSH tunnel instead.

Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/platforms/windows

carmine meadow Apr 29, 2026, 1:32 PM

#

ayu@MSI:/mnt/c/Users/theay$ openclaw --version
OpenClaw 2026.4.26 (be8c246)
ayu@MSI:/mnt/c/Users/theay$ openclaw gateway status

🦞 OpenClaw 2026.4.26 (be8c246) — You had me at 'openclaw gateway start.'

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /home/ayu/.nvm/versions/node/v22.22.2/bin/node /home/ayu/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/ayu/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/ayu/.nvm/versions/node/v22.22.2/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.4:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

silent craterBOT Apr 29, 2026, 1:32 PM

#

Yep — your output shows the clue:

Dashboard: http://192.168.1.4:18789/

Because you’re running inside WSL2, that 192.168.1.4 is likely the WSL/Linux-side address. Your Windows browser may not be able to open that directly.

Try this from the Windows browser instead:

http://127.0.0.1:18789/

If your openclaw dashboard URL has #token=..., keep the token part, just replace the host:

http://127.0.0.1:18789/#token=YOUR_TOKEN

#

Don’t paste the token here.

To verify from Windows PowerShell:

curl.exe -I http://127.0.0.1:18789/

If that fails too, restart WSL networking:

wsl --shutdown

Then reopen WSL and start/check the gateway again.

Also: Runtime: stopped means your systemd service is not running, but Connectivity probe: ok + Listening: *:18789 means something is currently listening, probably a manually-started gateway. We can clean that up later with openclaw doctor, but first try the localhost dashboard URL.

#

Docs: https://docs.openclaw.ai/web/dashboard and https://docs.openclaw.ai/platforms/windows

carmine meadow Apr 29, 2026, 1:35 PM

#

PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21064 ms: Could not connect to server
PS C:\Users\theay>

silent craterBOT Apr 29, 2026, 1:36 PM

#

That confirms it: Windows cannot reach the Gateway port inside WSL. So this is networking/WSL forwarding, not an auth-token problem.

Try this in WSL:

curl -I http://127.0.0.1:18789/
hostname -I

If the WSL curl works, then in PowerShell try the WSL IP directly:

$ip = (wsl hostname -I).Trim().Split()[0]
curl.exe -I "http://$ip:18789/"

If that works, open this in your Windows browser:

#

http://<WSL_IP>:18789/#token=YOUR_TOKEN

If it still fails, reset WSL networking:

wsl --shutdown

Then reopen WSL, start/check OpenClaw again:

openclaw gateway status
openclaw dashboard

#

Also, your status showed gateway.bind=lan. For WSL, I’d switch back to loopback after this:

openclaw config set gateway.bind loopback
openclaw gateway restart

Docs: https://docs.openclaw.ai/web/dashboard https://docs.openclaw.ai/platforms/windows

carmine meadow Apr 29, 2026, 1:37 PM

#

ayu@MSI:/mnt/c/Users/theay$ curl -I http://127.0.0.1:18789/
hostname -I
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; base-uri 'none'; object-src 'none'; frame-ancestors 'none'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: blob:; font-src 'self' https://fonts.gstatic.com; worker-src 'self'; connect-src 'self' ws: wss:
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Date: Wed, 29 Apr 2026 13:37:19 GMT
Connection: keep-alive
Keep-Alive: timeout=5

192.168.1.4 2401:4900:8f61:66e9:1630:d7b6:ccaf:3d5c 2401:4900:8f61:66e9:502d:d7cf:1058:ebcb
ayu@MSI:/mnt/c/Users/theay$

silent craterBOT Apr 29, 2026, 1:37 PM

#

Perfect — Gateway is healthy inside WSL. Windows just isn’t forwarding 127.0.0.1:18789 into WSL.

Now try this in PowerShell:

curl.exe -I http://192.168.1.4:18789/

If that returns HTTP/1.1 200 OK, open your dashboard in the Windows browser as:

http://192.168.1.4:18789/#token=YOUR_TOKEN

If PowerShell still can’t connect, do this quick reset:

#

wsl --shutdown

Then reopen WSL and run:

openclaw gateway restart
openclaw gateway status

One note: your config is gateway.bind=lan, which is why OpenClaw prints the 192.168.1.4 URL. For normal WSL-on-same-PC use, loopback is usually simpler:

openclaw config set gateway.bind loopback
openclaw gateway restart

#

Then try http://127.0.0.1:18789/ again from Windows.

carmine meadow Apr 29, 2026, 1:39 PM

#

PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21064 ms: Could not connect to server
PS C:\Users\theay> $ip = (wsl hostname -I).Trim().Split()[0]
PS C:\Users\theay> curl.exe -I "http://:18789$ip/"
curl: (3) URL rejected: No host part in the URL
PS C:\Users\theay> curl.exe -I http://192.168.1.4:18789/
curl: (28) Failed to connect to 192.168.1.4 port 18789 after 21034 ms: Could not connect to server
PS C:\Users\theay>

silent craterBOT Apr 29, 2026, 1:39 PM

#

Got it. Now we know:

✅ OpenClaw works inside WSL
❌ Windows cannot reach WSL on 127.0.0.1 or 192.168.1.4
Your $ip variable was empty, so that PowerShell command didn’t grab the WSL IP correctly

First do the simple reset from PowerShell:

wsl --shutdown

Then reopen WSL and run:

openclaw gateway restart

#

openclaw gateway status

Then test again from PowerShell:

curl.exe -I http://127.0.0.1:18789/

If it still fails, paste this PowerShell output:

wsl --list --verbose
wsl.exe --exec sh -lc "hostname -I"
netsh interface portproxy show all

#

Also, I’d change OpenClaw back to loopback inside WSL:

openclaw config set gateway.bind loopback
openclaw gateway restart

Then openclaw dashboard should ideally give/use 127.0.0.1 instead of the LAN IP.

carmine meadow Apr 29, 2026, 1:43 PM

#

ayu@MSI:/mnt/c/Users/theay$ openclaw gateway status

🦞 OpenClaw 2026.4.26 (be8c246) — Your terminal just grew claws—type something and let the bot pinch the busywork.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /home/ayu/.nvm/versions/node/v22.22.2/bin/node /home/ayu/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/ayu/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/ayu/.nvm/versions/node/v22.22.2/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.4:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21040 ms: Could not connect to server
PS C:\Users\theay>

silent craterBOT Apr 29, 2026, 1:44 PM

#

Your status still says:

Gateway: bind=lan (0.0.0.0)
Dashboard: http://192.168.1.4:18789/
Runtime: stopped
Listening: *:18789

So there’s a manual gateway process listening, but the managed service is stopped, and Windows can’t reach that WSL listener.

Do this exact cleanup:

In WSL:

#

openclaw config set gateway.bind loopback

Then stop the currently-running gateway — if it’s open in another WSL terminal, press Ctrl+C there.

If you can’t find it, run this in WSL:

openclaw gateway --force --port 18789

Leave that running, then in PowerShell test:

curl.exe -I http://127.0.0.1:18789/

#

If that returns HTTP/1.1 200 OK, open:

http://127.0.0.1:18789/

Then paste the token only into the dashboard auth field if it asks.

carmine meadow Apr 29, 2026, 1:49 PM

#

Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /home/ayu/.nvm/versions/node/v22.22.2/bin/node /home/ayu/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/ayu/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/ayu/.nvm/versions/node/v22.22.2/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21056 ms: Could not connect to server
PS C:\Users\theay>

it is set to loopback

silent craterBOT Apr 29, 2026, 1:49 PM

#

Yep, and that explains it: loopback is only working inside WSL, but Windows’ automatic localhost forwarding is broken on your machine.

Use the deterministic workaround: Windows portproxy.

1) In WSL, expose Gateway on WSL network:

openclaw config set gateway.bind lan
openclaw gateway restart

2) In PowerShell as Administrator:

$WslIp = ((wsl.exe --exec sh -lc "hostname -I") -split '\s+')[0]
Write-Host "WSL IP = $WslIp"

#


netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=$WslIp connectport=18789

3) Test in PowerShell:

curl.exe -I http://127.0.0.1:18789/

If it says HTTP/1.1 200 OK, open:

http://127.0.0.1:18789/

#

If $WslIp prints blank, run:

wsl --list --verbose

and we’ll target the exact distro with wsl -d <name> ....

Docs: https://docs.openclaw.ai/platforms/windows

carmine meadow Apr 29, 2026, 1:54 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /home/ayu/.nvm/versions/node/v22.22.2/bin/node /home/ayu/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/ayu/.nvm/versions/node/v22.22.2/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/ayu/.nvm/versions/node/v22.22.2/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://192.168.1.4:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: stopped (state inactive, sub dead, last exit 0, reason 1)
Connectivity probe: ok
Capability: admin-capable

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Restart attempts: /home/ayu/.openclaw/logs/gateway-restart.log

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
ayu@MSI:/mnt/c/Users/theay$

#

PS C:\Users\theay> $WslIp = ((wsl.exe --exec sh -lc "hostname -I") -split '\s+')[0]
PS C:\Users\theay> Write-Host "WSL IP = $WslIp"
WSL IP = 192.168.1.4
PS C:\Users\theay>

#

PS C:\Users\theay> netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=$WslIp connectport=18789

PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21031 ms: Could not connect to server
PS C:\Users\theay>

silent craterBOT Apr 29, 2026, 1:55 PM

#

You’re very close. This output means two separate things:

Gateway is reachable inside WSL (Connectivity probe: ok, Listening: *:18789)
The systemd service is failing because something else is already listening on port 18789 (Runtime: stopped ... reason 1)

So first clean up the duplicate/manual gateway process.

In WSL:

ss -ltnp 'sport = :18789'

If it shows an openclaw/node process, stop the terminal where it’s running, or reclaim the port:

#

openclaw gateway --force --port 18789

That starts it in the foreground. If you want the service instead, press Ctrl+C, then:

openclaw gateway restart
openclaw gateway status

After that, for the Windows browser issue, run the PowerShell Admin portproxy step from my previous message, then test:

curl.exe -I http://127.0.0.1:18789/

#

Right now don’t worry about the token — Windows simply can’t reach WSL yet. Docs: https://docs.openclaw.ai/platforms/windows

#

Nice, IP lookup works. Now finish the portproxy in PowerShell as Administrator:

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=192.168.1.4 connectport=18789

Then test:

netsh interface portproxy show all
curl.exe -I http://127.0.0.1:18789/

If curl returns HTTP/1.1 200 OK, open:

#

http://127.0.0.1:18789/

If the dashboard asks for auth, paste the token from openclaw dashboard into the auth field.

#

That means the proxy rule didn’t actually create a working listener (or Windows still can’t reach that WSL IP).

Please run these in PowerShell and paste the output:

netsh interface portproxy show all
netstat -ano | findstr :18789
Get-Service iphlpsvc

Also make sure that PowerShell was Run as Administrator when adding the portproxy. If not, reopen PowerShell as Admin and run:

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=192.168.1.4 connectport=18789

#

One more important check: in WSL, Gateway must be bind=lan, not loopback, for portproxy to reach it:

openclaw config set gateway.bind lan
openclaw gateway restart
curl -I http://127.0.0.1:18789/

If that WSL curl still returns 200 OK, then the remaining issue is definitely Windows portproxy/firewall.

carmine meadow Apr 29, 2026, 1:56 PM

#

ayu@MSI:/mnt/c/Users/theay$ ss -ltnp 'sport = :18789'
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=1820,fd=34))

silent craterBOT Apr 29, 2026, 1:56 PM

#

Great — WSL side is correct now: Gateway is listening on 0.0.0.0:18789, so portproxy should be able to forward to it.

Now the blocker is on Windows. In PowerShell as Administrator, run:

netsh interface portproxy show all
netstat -ano | findstr :18789
Get-Service iphlpsvc

If iphlpsvc is not running, start it:

Start-Service iphlpsvc

Then recreate the proxy explicitly:

#

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=192.168.1.4 connectport=18789
netsh interface portproxy show all

Then test:

curl.exe -I http://127.0.0.1:18789/

If that still times out, Windows Firewall/VPN/security software is probably blocking the WSL vEthernet path.

carmine meadow Apr 29, 2026, 1:57 PM

#

PS C:\Users\theay> netsh interface portproxy show all

Listen on ipv4: Connect to ipv4:

Address Port Address Port

127.0.0.1 18789 192.168.1.4 18789

PS C:\Users\theay> netstat -ano | findstr :18789
TCP 127.0.0.1:48716 127.0.0.1:18789 SYN_SENT 7612
PS C:\Users\theay> Get-Service iphlpsvc

silent craterBOT Apr 29, 2026, 1:59 PM

#

Your proxy rule exists, but this line is the problem:

127.0.0.1:48716 -> 127.0.0.1:18789 SYN_SENT

There should also be a LISTENING entry for 127.0.0.1:18789. Since there isn’t, Windows portproxy isn’t actually listening.

Run this in PowerShell as Administrator:

Get-Service iphlpsvc | Select Name,Status,StartType
Set-Service iphlpsvc -StartupType Automatic
Start-Service iphlpsvc
Restart-Service iphlpsvc

#

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=192.168.1.4 connectport=18789

netstat -ano | findstr LISTENING | findstr :18789
curl.exe -I http://127.0.0.1:18789/

If there’s still no LISTENING, run:

wsl --status

Your WSL showing 192.168.1.4 looks like mirrored networking, and Microsoft notes WSL mirrored/Hyper-V firewall can require explicit inbound firewall rules. (learn.microsoft.com)

If needed, try this Admin PowerShell rule:

#

New-NetFirewallHyperVRule -Name "OpenClawDashboard18789" -DisplayName "OpenClaw Dashboard 18789" -Direction Inbound -VMCreatorId "{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}" -Protocol TCP -LocalPorts 18789

Docs: https://docs.openclaw.ai/platforms/windows

carmine meadow Apr 29, 2026, 2:02 PM

#

PS C:\Users\theay> Get-Service iphlpsvc | Select Name,Status,StartType

Name Status StartType

iphlpsvc Running Automatic

PS C:\Users\theay> Set-Service iphlpsvc -StartupType Automatic
PS C:\Users\theay> Start-Service iphlpsvc
PS C:\Users\theay> Get-Service iphlpsvc | Select Name,Status,StartType

Name Status StartType

iphlpsvc Running Automatic

PS C:\Users\theay> Restart-Service iphlpsvc
PS C:\Users\theay> netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789

PS C:\Users\theay> netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=18789 connectaddress=192.168.1.4 connectport=18789

PS C:\Users\theay>
PS C:\Users\theay> netstat -ano | findstr LISTENING | findstr :18789
PS C:\Users\theay> curl.exe -I http://127.0.0.1:18789/
curl: (28) Failed to connect to 127.0.0.1 port 18789 after 21044 ms: Could not connect to server
PS C:\Users\theay>

silent craterBOT Apr 29, 2026, 2:02 PM

#

Okay — portproxy is failing at the Windows layer. The rule exists, but Windows never creates a LISTENING socket, so OpenClaw isn’t the blocker anymore.

Your WSL IP being 192.168.1.4 strongly suggests WSL mirrored networking / Hyper-V firewall.

Try this in PowerShell as Administrator:

New-NetFirewallHyperVRule -Name "OpenClawDashboard18789" -DisplayName "OpenClaw Dashboard 18789" -Direction Inbound -VMCreatorId "{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}" -Protocol TCP -LocalPorts 18789

Then test direct WSL access:

curl.exe -I http://192.168.1.4:18789/

If that works, open:

#

http://192.168.1.4:18789/

If New-NetFirewallHyperVRule is not recognized, paste:

wsl --status
type $env:USERPROFILE\.wslconfig

At this point the diagnosis is: Gateway is running fine in WSL, but Windows networking/firewall is blocking access from the Windows browser.

carmine meadow Apr 29, 2026, 2:03 PM

#

[wsl2]
[experimental]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

i use this in .wslconfig is this the error?

silent craterBOT Apr 29, 2026, 2:04 PM

#

Yes — that’s very likely the cause.

With networkingMode=mirrored + firewall=true, Windows uses the Hyper-V firewall for WSL. Your OpenClaw gateway is fine, but Windows is blocking access to port 18789.

Two fixes:

Option A — allow just OpenClaw port, recommended. Run PowerShell as Administrator:

New-NetFirewallHyperVRule -Name "OpenClawDashboard18789" -DisplayName "OpenClaw Dashboard 18789" -Direction Inbound -VMCreatorId "{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}" -Protocol TCP -LocalPorts 18789

Then:

curl.exe -I http://127.0.0.1:18789/

#

Option B — simpler test: temporarily change:

firewall=false

Then run:

wsl --shutdown

Reopen WSL, restart gateway, test dashboard again.

Microsoft’s WSL docs also call out Hyper-V firewall rules for mirrored networking. (learn.microsoft.com)

Accessing network applications with WSL

Learn about the considerations for accessing network applications when using Windows Subsystem for Linux (WSL).

carmine meadow Apr 29, 2026, 2:06 PM

#

Name : OpenClawDashboard18789
DisplayName : OpenClaw Dashboard 18789
RulePriority : 0
Direction : Inbound
VMCreatorId : {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
Protocol : TCP
LocalAddresses : Any
LocalPorts : 18789
RemoteAddresses : Any
RemotePorts : Any
Action : Allow
Enabled : True
EnforcementStatus : OK
PolicyStoreSourceType : Local
Profiles : Any
PortStatuses : {
SwitchName: 30BE601B-A2AB-4EDC-9AD5-9D2600CF7CF0
PortName: A34A60F2-70B3-4A3F-AFC9-FCAF9818AE1D
Profile: Public
NetworkType: FSE
InterfaceGuid: {C4929EF9-0649-11EE-9F4B-806E6F6E6963}
PartitionGuid: {25AE1D11-CC4B-40E5-BEFF-2A6AF8D545E0}
VMCreatorId: {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
EnforcementStatus: OK
}
{
SwitchName: 30BE601B-A2AB-4EDC-9AD5-9D2600CF7CF0
PortName: 36F402F9-4BDF-48FE-B931-992AB803E4FA
Profile: Public
NetworkType: FSE
InterfaceGuid: {D6C6180E-F0BF-49D8-B008-09C6D1CB3623}
PartitionGuid: {25AE1D11-CC4B-40E5-BEFF-2A6AF8D545E0}
VMCreatorId: {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
EnforcementStatus: OK
}
{
SwitchName: 30BE601B-A2AB-4EDC-9AD5-9D2600CF7CF0
PortName: 41CE5031-2D37-4113-8DB3-9196C5169B4F
Profile: Public
NetworkType: FSE
InterfaceGuid: {4F3F7C0B-F818-48F5-9938-A55E3E45BC85}
PartitionGuid: {25AE1D11-CC4B-40E5-BEFF-2A6AF8D545E0}
VMCreatorId: {40E0AC32-46A5-438A-A0B2-2B479E8F2E90}
EnforcementStatus: OK
}

silent craterBOT Apr 29, 2026, 2:07 PM

#

Good — the Hyper-V firewall rule is installed correctly.

Now test access again from PowerShell:

curl.exe -I http://192.168.1.4:18789/
curl.exe -I http://127.0.0.1:18789/

If 192.168.1.4 works, open:

http://192.168.1.4:18789/

If neither works, restart WSL so the networking/firewall state reloads:

#

wsl --shutdown

Then reopen WSL and run:

openclaw gateway restart
openclaw gateway status

Then retest from PowerShell.

Also, since you’re using mirrored networking, you can remove the broken portproxy rule to avoid confusion:

#

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789

If it still fails after wsl --shutdown, temporarily set this in .wslconfig:

firewall=false

Then wsl --shutdown again. If that fixes it, we know 100% it’s Hyper-V firewall behavior, not OpenClaw.

carmine meadow Apr 29, 2026, 2:15 PM

#

PS C:\Users\theay> curl.exe -I http://192.168.1.4:18789/
curl: (28) Failed to connect to 192.168.1.4 port 18789 after 21050 ms: Could not connect to server
PS C:\Users\theay>

not working even after setting firewall false in .wslconfig

silent craterBOT Apr 29, 2026, 2:16 PM

#

Yep — at this point I’d stop fighting mirrored networking and switch WSL back to normal NAT mode. Microsoft says Windows apps should be able to access WSL apps via localhost in default NAT mode, while mirrored mode needs extra Hyper-V firewall handling. (learn.microsoft.com)

Edit C:\Users\theay\.wslconfig to this:

[wsl2]
networkingMode=nat
localhostForwarding=true

Remove the [experimental] block for now.

Then in PowerShell:

wsl --shutdown

#

Reopen WSL, then:

openclaw config set gateway.bind loopback
openclaw gateway restart
curl -I http://127.0.0.1:18789/

Then from PowerShell:

curl.exe -I http://127.0.0.1:18789/

If that returns 200 OK, your browser should open:

#

http://127.0.0.1:18789/

Small note: if you do use mirrored mode later, put networkingMode=mirrored under [wsl2], not [experimental].

carmine meadow Apr 29, 2026, 2:18 PM

#

if i switch to nat mode then i will be unable to use openclaw app

silent craterBOT Apr 29, 2026, 2:19 PM

#

Ah, fair — if by “OpenClaw app” you mean another device/app needs to reach the gateway over LAN, plain NAT + loopback may break that.

So don’t switch permanently yet. Try fixing the mirrored config layout first. Your current file puts networking settings under [experimental], but Microsoft documents networkingMode, firewall, dnsTunneling, and autoProxy under [wsl2]; [experimental] is for things like hostAddressLoopback. (learn.microsoft.com)

Use:

[wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=false
autoProxy=true

[experimental]
hostAddressLoopback=true

#

Then:

wsl --shutdown

Reopen WSL:

openclaw config set gateway.bind lan
openclaw gateway restart

Then test from PowerShell:

#

curl.exe -I http://127.0.0.1:18789/
curl.exe -I http://192.168.1.4:18789/

Mirrored mode is specifically meant to allow LAN access to WSL, but Hyper-V firewall/config can get in the way. (learn.microsoft.com)

carmine meadow Apr 29, 2026, 2:26 PM

#

still not working , lets switch to nat mode

silent craterBOT Apr 29, 2026, 2:27 PM

#

Yep, let’s go NAT and get the dashboard working first.

1) Edit C:\Users\theay\.wslconfig to:

[wsl2]
networkingMode=nat
localhostForwarding=true
dnsTunneling=true
autoProxy=true

Remove the mirrored/firewall/experimental bits for now.

2) PowerShell:

#

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=18789
wsl --shutdown

3) Reopen WSL:

openclaw config set gateway.bind loopback
openclaw gateway restart
curl -I http://127.0.0.1:18789/
openclaw dashboard

4) Test from PowerShell:

#

curl.exe -I http://127.0.0.1:18789/

If that returns HTTP/1.1 200 OK, open:

http://127.0.0.1:18789/

If the OpenClaw app needs LAN/mobile access later, use Tailscale or a clean NAT port-forward after the dashboard is confirmed working.

carmine meadow Apr 29, 2026, 2:31 PM

#

PS C:\Users\theay> openclaw gateway status

🦞 OpenClaw 2026.4.26 (be8c246) — I'm the reason your shell history looks like a hacker-movie montage.

│
◇
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\theay\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://172.19.32.1:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 31460, Startup-folder login item installed; listener detected on port 18789.)
Connectivity probe: ok
Capability: read-only

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
PS C:\Users\theay>

working now but i dont think i can pair my app now with this

silent craterBOT Apr 29, 2026, 2:32 PM

#

Yeah, your instinct is right: dashboard working on Windows localhost doesn’t automatically mean the mobile app can pair.

Also: this status is now native Windows OpenClaw, not WSL:

Service: Scheduled Task
Command: C:\Program Files\nodejs\node.exe ...
Listening: 127.0.0.1:18789

For phone/app pairing, the app needs a URL reachable from the phone:

Best option: Tailscale / secure remote URL

Use Tailscale Serve if you want reliable app pairing without LAN/firewall pain.

Docs: https://docs.openclaw.ai/gateway/remote

#

Same-LAN option

Find your Windows LAN IP:

ipconfig

Look for your Wi‑Fi/Ethernet IPv4, usually like 192.168.x.x, not 172.19.32.1.

Then allow firewall:

New-NetFirewallRule -DisplayName "OpenClaw Gateway 18789" -Direction Inbound -Protocol TCP -LocalPort 18789 -Action Allow

In the app, use manual gateway:

#

ws://YOUR_WINDOWS_LAN_IP:18789

Then approve pairing:

openclaw devices list
openclaw devices approve <requestId>

If the app still can’t connect, the issue is that Windows OpenClaw is only listening on 127.0.0.1; then Tailscale Serve is the cleaner route.

#DASHBOARD NOT OPENING

Best option: Tailscale / secure remote URL

Same-LAN option