control ui | Friends of the Crustacean 🦞🤝 | Page 1

pliant sparrow Mar 3, 2026, 6:24 AM

#

Can't access control ui it just keeps loading indefinitely

shrewd portalBOT Mar 3, 2026, 6:24 AM

#

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

pliant sparrow Mar 3, 2026, 6:25 AM

#

Openclaw running in wsl

tulip vaporBOT Mar 3, 2026, 6:25 AM

#

Control UI “loads forever” is usually: the page loads, but the WebSocket never successfully connects/auths (wrong URL/token, insecure HTTP/device auth, or pairing required).

Can you paste the output of these 3 commands (and also tell me the exact URL you’re opening in the browser)?

openclaw --version
openclaw gateway status
openclaw logs --follow

Meanwhile, the top common fixes:

If you’re opening it remotely over plain HTTP (e.g. http://<lan-ip>:18789 or http://<tailscale-ip>:18789): that’s a non-secure context and browsers can block the WebCrypto/device-identity flow → UI can spin forever.
Fix: open it locally (http://127.0.0.1:18789/) or use HTTPS (Tailscale Serve is the recommended path).
Docs: https://docs.openclaw.ai/web/control-ui#insecure-http
Token/password mismatch: open the UI’s settings panel and paste your Gateway token (or password) and connect again. (The onboarding wizard generates a token by default.)

#

Troubleshooting section: https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity

Pairing required (1008): if the UI shows “disconnected (1008): pairing required”, you need to approve the browser/device once:

openclaw devices list
openclaw devices approve <requestId>

If you paste the gateway status + the first error line you see in logs --follow, I can tell you which bucket you’re in (unauthorized loop vs device identity vs wrong URL/bind).

#

If you’re running the Gateway inside WSL, the Control UI should normally be reachable from Windows at:

http://127.0.0.1:18789/ (or http://localhost:18789/)

A couple quick WSL-specific gotchas that cause the “loads forever” symptom:

1) You’re opening the WSL IP (or LAN IP) over plain HTTP

If you open http://<wsl-ip>:18789/ (or any non-loopback HTTP URL), the Control UI can get stuck because the browser treats it as a non-secure context and device-identity crypto is blocked.
Fix: use localhost on the Windows machine, or use HTTPS (Tailscale Serve).
Docs: https://docs.openclaw.ai/web/control-ui#insecure-http

2) Gateway is up, but the WS auth/pairing is failing

Please paste these (from inside WSL):

openclaw --version

#

openclaw gateway status
openclaw logs --follow

Also: what exact URL are you opening (copy/paste it)?

With those, I can tell if it’s:

token/password mismatch (unauthorized reconnect loop)
device pairing required (1008)
wrong bind/URL target
or something crashing in the gateway logs during the WS handshake

(If you want a quick sanity check: try the URL printed by openclaw gateway status / openclaw dashboard, and try Chrome if you’re on a wedged Firefox.)

pliant sparrow Mar 3, 2026, 6:27 AM

#

f4cte@MSI-shems:~$ openclaw --version
2026.3.2

#

f4cte@MSI-shems:~$ openclaw gateway status

🦞 OpenClaw 2026.3.2 (85377a2) — I'm like tmux: confusing at first, then suddenly you can't live without me.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-03.log
Command: /usr/bin/node /home/f4cte/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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

Gateway: bind=auto (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/

Runtime: running (pid 14409, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
f4cte@MSI-shems:~$

tulip vaporBOT Mar 3, 2026, 6:28 AM

#

2026.3.2 is current enough — good.

Next 2 things I need to diagnose the “infinite loading”:

What exact URL are you opening in the browser? (http://localhost:18789/ vs http://<wsl-ip>:18789/ etc.)
Paste:

openclaw gateway status

WSL-specific gotcha (very common):

If you open the Control UI via WSL IP / LAN IP over plain HTTP, the UI page can load but the WS handshake/device identity can fail and it looks like “loading forever”.
Prefer opening from Windows as: http://localhost:18789/
Or use HTTPS (Tailscale Serve) if you need remote access. Docs: https://docs.openclaw.ai/web/control-ui#insecure-http

Quick “just give me the right link” path:

#

openclaw dashboard

Open the URL it prints (it often includes the token in the fragment).

If after doing that it still spins: run openclaw logs --follow, refresh the page once, then paste the first error you see (look for phrases like unauthorized, device identity required, or pairing required (1008)).

#

Gateway looks healthy (RPC probe: ok) and it’s only listening on 127.0.0.1 inside WSL:

Listening: 127.0.0.1:18789

So the Control UI will only work if you open it in a way that lands on localhost.

The 2 most common WSL causes of “loads forever”

You’re opening it via a WSL/LAN IP (e.g. http://172.x.x.x:18789/ or another machine on your network).
That’s not localhost, and the Control UI’s device-auth can get blocked (non-secure context / WS auth never completes), which looks like an infinite loader.
Fix: open from the same Windows machine as:

http://localhost:18789/ (or http://127.0.0.1:18789/)

Missing token in the UI (auth mismatch → reconnect loop).
Easiest fix: run this inside WSL and open the URL it prints (it usually includes #token=...):

openclaw dashboard

#

If it still spins

Run this in WSL, then refresh the page once and paste the first error lines:

openclaw logs --follow

Also tell me the exact URL you’re opening in the browser (copy/paste).

pliant sparrow Mar 3, 2026, 6:33 AM

#

logs:

https://pastebin.com/B9zpz4Kk

tulip vaporBOT Mar 3, 2026, 6:35 AM

#

Looked through the paste — it doesn’t show any Control UI / browser connection attempt at all (no unauthorized, no pairing required (1008), no device identity required, etc.). It’s mostly startup + an update + restarts.

Given your earlier openclaw gateway status, the important bit is:

Listening: 127.0.0.1:18789 (inside WSL)
WSL IP shown in logs: 172.25.184.156

In WSL setups, the “loads forever” symptom is very often because you opened the UI via the WSL IP (or LAN IP), e.g. http://172.25.184.156:18789/. That’s plain HTTP on a non-loopback host, so the browser runs it in a less-trusted context and the Control UI’s device-auth / WS handshake can fail and it looks like an infinite loader. The docs call this out under “Insecure HTTP”.
https://docs.openclaw.ai/web/control-ui#insecure-http

Do this

From Windows, open exactly:

http://localhost:18789/ (not the 172.* address)

Even better: in WSL run:

#

openclaw dashboard

…and open the URL it prints (it commonly includes #token=... so you don’t get stuck on auth).

If it still spins

Run this in WSL, then refresh the page once, and paste the new lines that appear:

openclaw logs --follow

Also tell me the exact URL you’re opening right now (copy/paste). That single detail usually makes this instantly obvious in WSL cases.

pliant sparrow Mar 3, 2026, 6:40 AM

#

still the same excpet it's not loading anymore , loking at the dev console i see no request at all

logs:
https://pastebin.com/uVEH3jcT

tulip vaporBOT Mar 3, 2026, 6:42 AM

#

Your new paste actually shows the Control UI did reach the gateway at least once:

webchat connected ... remote=127.0.0.1 client=openclaw-control-ui
and then sessions.list, device.pair.list, chat.history, …

So the gateway side is capable of serving/accepting the UI.

If your browser devtools shows “no requests at all”, that usually means one of these is happening:

A) You’re not actually on the gateway URL

Please copy/paste the exact URL in your address bar (including #token=... if present).

Fast path: run in WSL and open exactly what it prints:

openclaw dashboard

#

B) DevTools is hiding the only “request” (it’s a WebSocket)

In Chrome/Edge DevTools → Network → click the WS filter.
You should see a ws://localhost:18789 (or similar). If WS is empty, the page JS isn’t even connecting.

C) The page JS is crashing before it can connect (extensions/cached broken assets)

Do this reset:

Open the UI in Incognito (no extensions)
DevTools → Application → Clear site data for http://localhost:18789 / http://127.0.0.1:18789
Hard reload: Ctrl+Shift+R

Then try again and check if the gateway log prints another webchat connected line.

Quick sanity checks (copy/paste output)

From WSL:

curl -I http://127.0.0.1:18789/

#

From Windows (PowerShell):

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

Finally: can you paste a screenshot (or the text) of the Console errors (red lines) from the browser? That’s usually the smoking gun when Network looks empty.

pliant sparrow Mar 3, 2026, 6:46 AM

#

^Cf4cte@MSI-shems:~curl -I http://127.0.0.1:18789/
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
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: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' ws: wss:
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Date: Tue, 03 Mar 2026 06:45:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5

PS C:\Users\User> curl.exe -I http://localhost:18789/
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
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: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' ws: wss:
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Date: Tue, 03 Mar 2026 06:46:09 GMT
Connection: keep-alive
Keep-Alive: timeout=5

PS C:\Users\User>

tulip vaporBOT Mar 3, 2026, 6:47 AM

#

That’s a good sign: Windows can reach the gateway HTML on http://localhost:18789/ (HTTP 200). So WSL port forwarding + the gateway listener are fine.

If the browser now “doesn’t load” and DevTools shows “no requests”, that almost always means the JS bundle isn’t loading / is being blocked, so it never gets to the point where it opens the WebSocket.

1) In DevTools, make sure you’re looking at the right thing

In Network tab:

select All (not just Fetch/XHR)
then hard-reload (Ctrl+Shift+R)
You should at least see requests for /assets/*.js and /assets/*.css.

2) Check if the UI assets exist (this is the fastest test)

From PowerShell:

curl.exe http://localhost:18789/ | findstr /i assets

#

Copy/paste the /assets/...js URL it prints, then:

curl.exe -I http://localhost:18789/<PASTE-THE-ASSET-PATH-HERE>

If that asset is 404/blocked, the UI can’t boot → infinite loader / blank.
If it’s 200, then it’s a browser-side block/crash.

3) Clear local state + try without extensions

Open an Incognito/InPrivate window
Go to http://localhost:18789/
If it works there, an extension (adblock/privacy) is blocking scripts or websockets.
Also worth doing: DevTools → Application → Clear site data for http://localhost:18789.

4) Paste the browser Console errors (red lines)

That’s usually the smoking gun (common ones: “Failed to load module script”, “ERR_BLOCKED_BY_CLIENT”, CSP errors, etc.).

#control ui

1) You’re opening the WSL IP (or LAN IP) over plain HTTP

2) Gateway is up, but the WS auth/pairing is failing

The 2 most common WSL causes of “loads forever”

If it still spins

Do this

If it still spins

A) You’re not actually on the gateway URL

B) DevTools is hiding the only “request” (it’s a WebSocket)

C) The page JS is crashing before it can connect (extensions/cached broken assets)

Quick sanity checks (copy/paste output)

1) In DevTools, make sure you’re looking at the right thing

2) Check if the UI assets exist (this is the fastest test)

3) Clear local state + try without extensions

4) Paste the browser Console errors (red lines)