Summary
When the gateway restarts (e.g. during a self-update), the Control UI webchat's WebSocket connection drops. The reconnect logic retries automatically but does not include the auth token in the new handshake, causing repeated unauthorized failures that quickly trigger the rate limiter. Once rate-limited, even manually refreshing with the correct ?token= URL is rejected until the gateway is fully restarted again.
Steps to Reproduce
- Open the Control UI dashboard in a browser via
http://127.0.0.1:18789?token=<token>
- Authenticate successfully — the webchat connects
- Restart the gateway (e.g.
openclaw gateway restart or launchctl bootout + bootstrap)
- Observe the browser tab — the Control UI begins reconnecting automatically
Observed Behavior
- The reconnect attempts are sent with
authProvided: "none" (visible in gateway logs under gateway/ws)
- After several rapid failed attempts, the gateway rate-limits the IP:
reason=rate_limited
- Subsequent attempts — even with a valid token — are rejected with:
unauthorized: too many failed authentication attempts (retry later)
- The only recovery is a full gateway process restart to clear the in-memory rate-limit state
Expected Behavior
- The Control UI should persist the auth token (e.g. in
localStorage or from the original ?token= URL parameter) and include it in every WebSocket reconnect handshake
- Reconnect backoff should be exponential to avoid flooding the rate limiter even if auth does fail
Environment
- OpenClaw 2026.2.26 (bc50708)
- macOS, Edge 145 (also reproducible in any browser — this is client-side JS, not browser-specific)
- Gateway bound to loopback (
127.0.0.1:18789), auth mode: token
Relevant Log Snippet
unauthorized conn=... remote=127.0.0.1 client=openclaw-control-ui webchat vdev reason=token_missing
unauthorized conn=... remote=127.0.0.1 client=openclaw-control-ui webchat vdev reason=rate_limited
Note the alternation between authProvided: "none" and authProvided: "token" — the UI sometimes sends the token and sometimes doesn't, suggesting a race condition or inconsistent token retrieval on reconnect.
Summary
When the gateway restarts (e.g. during a self-update), the Control UI webchat's WebSocket connection drops. The reconnect logic retries automatically but does not include the auth token in the new handshake, causing repeated
unauthorizedfailures that quickly trigger the rate limiter. Once rate-limited, even manually refreshing with the correct?token=URL is rejected until the gateway is fully restarted again.Steps to Reproduce
http://127.0.0.1:18789?token=<token>openclaw gateway restartorlaunchctl bootout+bootstrap)Observed Behavior
authProvided: "none"(visible in gateway logs undergateway/ws)reason=rate_limitedunauthorized: too many failed authentication attempts (retry later)Expected Behavior
localStorageor from the original?token=URL parameter) and include it in every WebSocket reconnect handshakeEnvironment
127.0.0.1:18789), auth mode: tokenRelevant Log Snippet
Note the alternation between
authProvided: "none"andauthProvided: "token"— the UI sometimes sends the token and sometimes doesn't, suggesting a race condition or inconsistent token retrieval on reconnect.