openclaw - 💡(How to fix) Fix Control UI fails to reconnect after update/service repair due to stale or missing gateway auth token

Summary

After upgrading OpenClaw from 2026.5.18 to 2026.5.27, the local Control UI could open at http://127.0.0.1:18789/ but could not connect to the gateway. The gateway was healthy and listening, but the UI repeatedly failed WebSocket authentication.

The logs suggest an update/auth-state migration problem:

1. The gateway service definition was installed by 2026.5.18.
2. The CLI was upgraded to 2026.5.27.
3. OpenClaw repaired/reinstalled the LaunchAgent and restarted the gateway.
4. A previously loaded/stored Control UI state first tried to use a stale device token and failed with device_token_mismatch.
5. Subsequent opens of the bare dashboard URL failed with token_missing.
6. Opening the dashboard with a token fragment (#token=...) restored connectivity.

This is confusing because the dashboard page itself returns 200 OK, and openclaw gateway status reports the gateway as healthy/admin-capable. From the user's perspective the UI "does not connect" after the update.

Environment

• OpenClaw CLI/Gateway: 2026.5.27 (27ae826)
• Previous service version in logs: 2026.5.18
• OS: macOS 26.3 (25D125)
• Node: v25.9.0
• Gateway mode: local, loopback
• Gateway URL: http://127.0.0.1:18789/
• Auth mode: token
• Browser: Safari 26.3

Relevant Logs

Upgrade/service repair:

2026-05-30T12:31:29.871+03:00 info Gateway service definition needs repair:
2026-05-30T12:31:29.878+03:00 info - service was installed by OpenClaw 2026.5.18, current CLI is 2026.5.27
2026-05-30T12:31:31.389+03:00 info Gateway service definition repaired and started.

Gateway comes back healthy:

2026-05-30T12:31:34.552+03:00 info gateway {"subsystem":"gateway"} agent model: openai/gpt-5.5 (thinking=medium, fast=off)
2026-05-30T12:31:34.553+03:00 info gateway {"subsystem":"gateway"} http server listening (11 plugins: brave, browser, canvas, codex, device-pair, file-transfer, memory-core, phone-control, talk-voice, telegram, tts-local-cli; 2.4s)
2026-05-30T12:31:34.718+03:00 info gateway {"subsystem":"gateway"} gateway ready

First UI auth failure after the update still identifies as the older Control UI and sends a token, but the token is rejected as stale:

2026-05-30T12:29:20.326+03:00 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized ... client=openclaw-control-ui webchat v2026.5.18 ... auth=token ... reason=device_token_mismatch
2026-05-30T12:29:20.332+03:00 warn gateway/ws {"subsystem":"gateway/ws"} ... authMode="token" authProvided="token" authReason="device_token_mismatch" ... code=1008 reason=unauthorized: device token mismatch (rotate/reissue device token)

After the service repair/restart, the same local dashboard URL opens but connects without any auth token:

2026-05-30T12:33:19.475+03:00 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized ... client=openclaw-control-ui webchat v2026.5.18 ... auth=none ... reason=token_missing
2026-05-30T12:33:19.482+03:00 warn gateway/ws {"subsystem":"gateway/ws"} ... authMode="token" authProvided="none" authReason="token_missing" ... code=1008 reason=unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings)

The issue was reproducible with the current UI bundle as well:

2026-05-30T12:51:50.728+03:00 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized ... client=openclaw-control-ui webchat vcontrol-ui ... auth=none ... reason=token_missing
2026-05-30T12:57:40.969+03:00 warn gateway/ws {"subsystem":"gateway/ws"} unauthorized ... client=openclaw-control-ui webchat vcontrol-ui ... auth=none ... reason=token_missing

Connectivity was restored only after opening a token-authenticated URL:

2026-05-30T12:58:28.872+03:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=6dfbda73-7fc9-4200-aa18-7c733b485186 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.5.27

Expected Behavior

After an OpenClaw update and gateway service repair:

• The local Control UI should either reconnect automatically using the new valid auth state, or
• It should invalidate stale device auth state and clearly guide the user to a token-authenticated URL, or
• The CLI/dashboard launch flow should ensure the opened/copied local dashboard URL includes the token fragment when auth mode is token.

The user should not end up with a normal-looking 200 OK dashboard page that silently loops on token_missing.

Actual Behavior

• http://127.0.0.1:18789/ loads.
• Gateway health/status probes pass.
• Control UI WebSocket connection fails repeatedly.
• Logs show device_token_mismatch first, then token_missing.
• The visible symptom is "Control UI does not connect after update."

Why This Appears To Happen

The update repaired/reinstalled the gateway LaunchAgent because the service was still from 2026.5.18. That restart appears to invalidate or make incompatible the previously stored browser/device auth state.

The Control UI then has two bad states:

• stale device token present: gateway rejects it with device_token_mismatch
• no shared gateway token in Control UI settings/localStorage: gateway rejects with token_missing

Because the bare dashboard URL still serves the UI successfully, this looks like a connection bug rather than an auth-state migration problem.

Workaround

Open the dashboard with a URL fragment containing the gateway token:

http://127.0.0.1:18789/#token=<gateway-token>

Alternatively, clear the Control UI site data/localStorage and reopen via the token-authenticated dashboard URL.

Additional Related Symptom

During the same update window, embedded agent runs also failed with:

Error: Requested agent harness "codex" does not support openai/gpt-5.5 (provider is not one of: codex).

This may be separate from the Control UI auth failure, but it contributed to the perception that the update broke the local OpenClaw session. If this is expected after model/provider config changes, the migration/doctor flow should surface it more directly.