Issue opening the Dashboard on WSL (windows)

[ebon tulip]

I use windows 11 and I've installed openclaw on WSL. its working fine there but I want to access the dashboard and since WSL is headless, Im trying to connect via windows browser. I've tried SSH but openclaw doesnt allow. It does open the dashboard on win but it never connects (screen is unresponsive). Code: 4008.

What can be done about this? I simply want to access the dashboard on browser but I'm on WSL headless.

Issue opening the Dashboard on WSL (windows)

[real remnant]

Hoping for an answer to this as well, ran into the same thing, surprised more aren't talking about it.

[vernal star]

When I had this issue it’s because wsl isn’t actually on the windows localhost. It gets its own network adapter kinda. You have to find out what wsl’s exit point is. Check your resolv.conf for the ip and see if you can ping that.

https://learn.microsoft.com/en-us/windows/wsl/networking

[real remnant]

The localhost issue is a 1008 error, not a 4008, at least from what I've seen.

[ebon tulip]

indeed. ive tried debugging it for hours and still cant find a way around it

[wicked radish]

4008 is the Control UI closing the WebSocket because the Gateway “connect” handshake failed (it’s not a “WSL headless can’t do UI” problem per se).

On WSL2 this is usually one of these:

1) Your Windows browser looks “remote” to the Gateway → device pairing required

Even if you open http://localhost:18789/ from Windows, WSL2 port-forwarding can make the Gateway see the client as non-loopback, which triggers one-time device pairing for that browser.

In WSL, run:

openclaw devices list
openclaw devices approve <requestId>

Then reload the dashboard in Windows.

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection

2) You opened the UI via a non-localhost URL (HTTP on LAN/WSL IP) → browser blocks WebCrypto

If you opened something like http://<wsl-ip>:18789/ (or your LAN IP), the page is not a secure context, so the browser can’t generate “device identity”, and the Gateway will reject the connect.

Fix: open it as localhost:

• http://127.0.0.1:18789/ (best)
• or use HTTPS via Tailscale Serve

Docs: https://docs.openclaw.ai/web/control-ui#insecure-http

(Workaround if you must stay on HTTP: set gateway.controlUi.allowInsecureAuth: true and use token-only auth — security downgrade.)

3) Missing/incorrect token/password

Run this in WSL to get a tokenized URL and open it in Windows:

openclaw dashboard --no-open

Don’t paste the token publicly.

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

---

If none of the above fixes it, the fastest next step is: run openclaw logs --follow in WSL, reload the dashboard once from Windows, and paste the non-secret log lines around the failed connect (it usually says why it rejected: pairing/origin/auth/device identity).

[ebon tulip]

i have added all devices as approved

spent full 1-2hours trying with antigravity to fix

still not being able to access. getting 1001 error

23:12:22 [ws] webchat disconnected code=1001 reason=n/a conn=e5556238-1e21-42a6-871a-cd1a7a9f681f
23:12:23 [ws] webchat disconnected code=1001 reason=n/a conn=a2816817-d975-4129-9333-75f6e3aafa82
23:12:24 [ws] webchat disconnected code=1001 reason=n/a conn=920e665f-d0e0-4c36-8f10-842f20902609
23:12:24 [DEBUG] Handshake conn=87629b6f-a911-4419-9581-4d6b1d0cbb61 method=connect auth={"token":"c873514d11eedba344980c274641a6cd919e6b25db0a7a8f"}
23:12:25 [ws] webchat connected conn=87629b6f-a911-4419-9581-4d6b1d0cbb61 remote=172.23.208.1 client=openclaw-control-ui webchat vdev

[wicked radish]

Approving devices only helps if the browser can actually generate/send a device identity.

On WSL2, the usual gotcha is: you’re opening the UI via a non-localhost HTTP URL (e.g. http://<wsl-ip>:18789/). That’s not a secure context, so the browser can’t use WebCrypto → the Control UI can’t sign the connect handshake → Gateway rejects → the UI closes the socket with 4008 (“connect failed”). No amount of approving devices fixes that.

Can you try this exact path from Windows:

1. In WSL, generate a tokenized link:

openclaw dashboard --no-open

2. In Windows browser, open localhost (not the WSL IP):

• http://127.0.0.1:18789/?token=...

If you tell me the exact URL you’re using right now (localhost vs WSL IP), I can confirm which branch you’re hitting.

If you must access via http://<wsl-ip>:18789/, then you need one of:

• HTTPS (recommended; e.g. Tailscale Serve), or
• config downgrade: gateway.controlUi.allowInsecureAuth: true (token-only; security tradeoff)

Docs: https://docs.openclaw.ai/web/control-ui#insecure-http

If it still fails even on 127.0.0.1, run in WSL:

openclaw logs --follow

then reload the page once and paste the log lines around the failed connect (that will show the real reject reason).

[ebon tulip]

23:12:22 [ws] webchat disconnected code=1001 reason=n/a conn=e5556238-1e21-42a6-871a-cd1a7a9f681f
23:12:23 [ws] webchat disconnected code=1001 reason=n/a conn=a2816817-d975-4129-9333-75f6e3aafa82
23:12:24 [ws] webchat disconnected code=1001 reason=n/a conn=920e665f-d0e0-4c36-8f10-842f20902609
23:12:24 [DEBUG] Handshake conn=87629b6f-a911-4419-9581-4d6b1d0cbb61 method=connect auth={"token":"c873514d11eedba344980c274641a6cd919e6b25db0a7a8f"}
23:12:25 [ws] webchat connected conn=87629b6f-a911-4419-9581-4d6b1d0cbb61 remote=172.23.208.1 client=openclaw-control-ui webchat vdev

[wicked radish]

The “antigravity” stuff isn’t related here — the dashboard connect is a Gateway WebSocket handshake problem.

From the log you pasted:

• Handshake ... auth={"token":"..."} but no device=...
  ⇒ your browser is connecting in a way where it can’t use WebCrypto, so the Control UI can’t generate/sign device identity.

By default the Gateway will reject Control UI connects without device identity unless you explicitly allow insecure auth.

Fix (recommended)

Make sure you open the dashboard from Windows using a loopback URL (secure context):

• http://127.0.0.1:18789/?token=...
  (get the tokenized URL via openclaw dashboard --no-open inside WSL)

Do not open it via http://<wsl-ip>:18789/ (that’s not a secure context → breaks device identity).

If you must use the WSL IP over plain HTTP

Set this (security downgrade; token-only):

{
  gateway: {
    controlUi: { allowInsecureAuth: true }
  }
}

Docs: https://docs.openclaw.ai/web/control-ui#insecure-http

About the 1001

1001 in the gateway logs usually means the browser closed/reloaded the socket while it was looping/retrying. The real useful line is the one where the gateway closes with 1008 and a reason like “control ui requires HTTPS or localhost (secure context)” — if you can paste the 5–10 log lines after the handshake (please redact the token), we can confirm.

Also: you pasted your gateway token publicly — you should rotate it after this.

That log snippet actually shows the handshake succeeded:

[DEBUG] Handshake ... method=connect auth=...
[ws] webchat connected ... client=openclaw-control-ui ...

So 1001 isn’t the “root error” here — 1001 is a normal close code (“going away”), usually when the browser tab reloads/navigates or the UI reconnect loop resets. People often see a bunch of 1001 while they’re refreshing the page.

What I need to pinpoint why the UI is still “frozen / disconnected”:

1. What exact URL are you opening in Windows?
   Is it http://127.0.0.1:18789/… (good) or http://<wsl-ip>:18789/… (bad / insecure context)?

2. Run this in WSL and then reload the dashboard once (don’t spam refresh):

openclaw logs --follow

Then paste the lines after the Handshake / connected line — especially any close code=1008 reason=... (that’s where the real rejection reason shows up: insecure context / device identity required / origin not allowed / pairing required, etc.).

Also: you pasted your gateway token publicly in the log (auth={"token":"..."}) — treat that token as compromised and rotate it ASAP (Control UI is an admin surface).

[ebon tulip]

it seems to be connected on the logs but in reality it doesnt

23:24:19 info [DEBUG] Handshake conn=930ff3fd-e83d-4ce2-bdb0-834568e021ef method=connect auth={"token":"c873514d11eedba344980c274641a6cd919e6b25db0a7a8f"}
23:24:19 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=930ff3fd-e83d-4ce2-bdb0-834568e021ef remote=x.x.208.1 client=openclaw-control-ui webchat vdev
23:24:20 info [DEBUG] Handshake conn=1d88de7d-47a4-4e3c-86ad-7d770025f57b method=connect auth={"token":"4fd76f3ba76246b8976cbe4972ee844f"}
23:24:21 info [DEBUG] Handshake conn=243ac40b-359a-45a5-8b3a-4d46232955ae method=connect auth={"token":"4fd76f3ba76246b8976cbe4972ee844f"}
23:24:22 info [DEBUG] Handshake conn=bdb8ccd7-79dc-4374-8400-bb5bb2733b2a method=connect auth={"token":"4fd76f3ba76246b8976cbe4972ee844f"}
23:24:22 info gateway/ws {"subsystem":"gateway/ws"} webchat disconnected code=1001 reason=n/a conn=930ff3fd-e83d-4ce2-bdb0-834568e021ef
23:24:22 info [DEBUG] Handshake conn=e1b56259-d69e-4c7d-952f-918070dcbc57 method=connect auth={"token":"c873514d11eedba344980c274641a6cd919e6b25db0a7a8f"}
23:24:22 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=e1b56259-d69e-4c7d-952f-918070dcbc57 remote=x.x.208.1 client=openclaw-control-ui webchat vdev
23:24:23 info [DEBUG] Handshake conn=0ea2f055-686c-44cc-ad77-f9e2c51f185e method=connect auth={"token":"4fd76f3ba76246b8976cbe4972ee844f"}

it seems to be conected from the logs viewside but on the browser its just disconected..

[wicked radish]

Those lines mean the Gateway is accepting the connection, and then the socket is being closed with:

• webchat disconnected code=1001 reason=n/a

1001 is “going away” — in practice it almost always means the browser side is closing the WebSocket (page reload/navigation, tab being discarded, JS crash → reload loop, extension interference, etc.). If the Gateway was rejecting you, you’d normally see 1008 with a reason like “pairing required / origin not allowed / device identity required”.

Also: you’ve got multiple handshakes per second — that usually happens when the page is repeatedly reconnecting/reloading.

What I’d do next:

1. Close every dashboard tab/window you have open.
   Then open one fresh session in Incognito/InPrivate, with extensions disabled.

2. In that browser tab: open DevTools → Console and Network → WS, and look at the WebSocket close event.
   Paste the console error(s) / the WS close code+reason (please redact tokens).

3. In WSL, check that the gateway isn’t restarting/flapping:

openclaw gateway status
openclaw status --all

(status --all is paste-safe; it redacts secrets.)

One more important thing: you’ve pasted your gateway token publicly in logs. You should rotate it after this (e.g. openclaw doctor --generate-gateway-token, then restart the gateway).

[ebon tulip]

still doesnt work. ws console status is 101

[wicked radish]

101 in DevTools just means the browser successfully upgraded to WebSocket (“Switching Protocols”). It does not mean the Control UI finished the Gateway handshake.

In your gateway logs I also see two different tokens being used (c873… and 4fd76…). That usually means the browser has an old/bad token cached in localStorage, so it keeps reconnecting and failing, even though some connects show up as “connected”.

Do this (quick reset)

1. Close all dashboard tabs/windows.
2. Open a fresh Incognito/InPrivate window (extensions off).
3. In WSL, generate a fresh tokenized URL:

   openclaw dashboard --no-open
   

4. In Windows, open exactly:
   • http://127.0.0.1:18789/?token=... (paste the token from step 3)

If you still see “disconnected” in the UI

In Chrome DevTools → Network → click the WS connection → look for the Close frame (it will show a code + reason).

• If it’s 1008 with a reason like unauthorized / secure context / device identity required / origin not allowed, paste that reason (redact tokens).
• If it’s 1001, that means the browser is closing it (reload/navigation/tab discard), and we need the Console errors (usually there’s a JS error causing a reload loop).

Also: you pasted gateway tokens in public logs — you should rotate your gateway token after this (Control UI is an admin surface).

[ebon tulip]

still doesnt work. ive reinstalled now thorugh docker. and it is the same issue. cant connect at all

[wicked radish]

If it’s “the same issue” even after a full Docker reinstall, that strongly points to the browser side (cached Control UI settings / wrong gateway URL / stale token), not your WSL install.

1) Hard-reset the Control UI in the browser (this fixes a lot of “it won’t connect” loops)

Open the dashboard page, then in DevTools → Console run:

localStorage.removeItem("openclaw.control.settings.v1");   // stores gatewayUrl + token
localStorage.removeItem("openclaw-device-identity-v1");    // device identity
localStorage.removeItem("openclaw.device.auth.v1");        // device token cache
location.reload();

Then open a fresh tokenized URL again (see next step).

2) Make sure you’re using the current tokenized URL for your current install

• If you’re running in WSL:

  openclaw dashboard --no-open

• If you’re running via Docker Compose:

  docker compose run --rm openclaw-cli dashboard --no-open
  

Then open exactly http://127.0.0.1:18789/?token=... in Windows.

(Also: please stop pasting logs with auth={"token":"..."} — rotate that token afterwards.)

3) Quick triage: is it network or just WS/auth?

• If http://127.0.0.1:18789/ does not load at all → it’s port/bind/publish.
  • Docker: docker compose ps should show something like 0.0.0.0:18789->18789/tcp
• If the page loads but says “disconnected” → open DevTools → Network → WS → click the socket and tell me the Close code + reason (that’s the real clue; 101 just means the upgrade worked).