openclaw - 💡(How to fix) Fix Control UI: ?token URL param sometimes fails to populate localStorage [1 comments, 2 participants]

Summary

In the Control UI SPA, opening a tokenized dashboard URL (http://127.0.0.1:18789/?token=<token>) is intended to write the token into localStorage["clawdbot.control.settings.v1"], after which the WebSocket connect frame includes auth.token. In my environment, the token in the URL is not landing in localStorage, so every WS connect attempt fails with close code 1008 reason "token_missing".

Environment

• clawdbot 2026.1.24-3 (885167d)
• Windows 11 (10.0.26200), Node 22.14.0
• Chrome (stable, installed at C:\Program Files\Google\Chrome)
• gateway.auth.mode: token, bind: loopback

Repro

1. clawdbot dashboard (or open the tokenized URL it prints).
2. Control UI loads, shell renders, then disconnects:

   unauthorized: gateway token missing (open a tokenized dashboard URL or paste token in Control UI settings)

3. Gateway log shows recurring unauthorized … reason=token_missing for client=clawdbot-control-ui webchat.

Hard refresh / Clear Site Data / re-opening the tokenized URL did not help.

Workaround

Writing the settings object directly works and persists:

localStorage.setItem('clawdbot.control.settings.v1', JSON.stringify({
  gatewayUrl: 'ws://127.0.0.1:18789',
  token: '<redacted>',
  sessionKey: 'main',
  lastActiveSessionKey: 'main',
  theme: 'system',
  chatFocusMode: false,
  chatShowThinking: true,
  splitRatio: 0.6,
  navCollapsed: false,
  navGroupsCollapsed: {},
}));
location.reload();

Code reference

The URL-token handler in the built bundle (dist/control-ui/assets/index-Cl-Y9zqE.js, function ad(e)) reads ?token / ?password / ?session / ?gatewayUrl from window.location.search and calls the settings setter (ke). In source this is likely the function that runs once per app boot. The handler looks correct on inspection, so the bug is probably one of:

• (a) ad(e) is invoked after the first WS connect attempt — the initial connect uses the still-empty settings.token, and reconnect logic does not retry once the token lands; or
• (b) ad(e) is invoked but ke() does not persist synchronously in some Chromium codepaths (storage backend not ready, throwing silently, etc.); or
• (c) An earlier throw during app init aborts ad(e) entirely (would be visible in DevTools console — I can capture if helpful).

Suggested fix

Ensure URL-param ingestion is applied to settings before the first WS connect attempt (e.g., synchronously during the initial settings load, not in a post-mount effect), and emit a one-shot console.warn if the URL carries a token that fails to persist.

Happy to grab a console/network dump if useful.