Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Once the Control UI has an authenticated session, any WebSocket drop (gateway restart, laptop sleep, SSH tunnel churn in remote mode, network blip) immediately unmounts the whole dashboard and replaces it with the login/connect gate showing a red "Could not connect" card — even though GatewayBrowserClient keeps auto-reconnecting with backoff in the background. The operator is visually "logged out" by a transient transport failure, loses all page context, and the gate flashes back to the dashboard whenever the retry succeeds.

The disconnect-resilient machinery already exists but is unreachable: chat-page.applyGatewaySnapshot (ui/src/pages/chat/chat-page.ts) handles disconnect/reconnect in place (marks queued sends "waiting for reconnect", re-syncs subscriptions and history on reconnect), and the sidebar has an offline status dot (sidebar-connection-status--offline). None of that is ever visible because OpenClawApp.render swaps the entire shell for <openclaw-login-gate> the moment connected flips false (ui/src/app/app-host.ts).

Steps to reproduce

1. Open the Control UI (browser or the macOS app dashboard) and connect with a valid token.
2. Restart the gateway (openclaw gateway restart), or kill the SSH control tunnel in remote mode, or sleep/wake the laptop.
3. Watch the dashboard get replaced by the connect form with the "Could not connect" error card while the client silently retries.

Expected behavior

An established session should degrade gracefully: keep the dashboard mounted, show a "connection lost — reconnecting" banner, pause actions, and recover in place when the auto-reconnect succeeds. The login gate should be reserved for states that actually need operator input: first connect, and credential rejections (bad token/password, revoked pairing).

Actual behavior

The full-screen login gate replaces the dashboard on every disconnect, including transient ones that auto-recover seconds later. In macOS-app remote mode this is effectively permanent: the WebView's injected gateway URL points at a dead forwarded tunnel port, so the retry loop can never succeed and the user is stuck on the gate (tracked separately, see linked macOS issues).

OpenClaw version

main @ 5fdaa04 (also 2026.6.11 stable)

Operating system

macOS 26.5 (any; behavior is in the web Control UI)

Install method

git checkout (dev), Homebrew (stable)

Model

n/a

Provider / routing chain

n/a

Additional provider/model setup details

n/a

Logs

Gateway close reasons observed in the client snapshot: disconnected (1006): no reason / gateway closed (1006) while GatewayBrowserClient.scheduleReconnect keeps retrying (800 ms → 1.7x → 15 s cap).

Screenshots, recordings, and evidence

• Render gate: ui/src/app/app-host.ts (if (!this.gatewayConnected) return login gate).
• Snapshot flip: ui/src/app/bootstrap.ts onClose sets connected: false with no memory of the established session.
• Client retry policy: ui/src/api/gateway.ts close handler (isNonRecoverableAuthError gates scheduleReconnect).
• Unreachable in-place reconnect handling: ui/src/pages/chat/chat-page.ts applyGatewaySnapshot.

Impact and severity

UX-facing: operators are booted from the dashboard on every transient network hiccup; on macOS-app remote mode the gate is a dead end until the window is reopened. Severity: medium (no data loss, but a routine occurrence that reads as "logged out / broken").

Additional information

Companion macOS issues: #100476 (stale tunnel port in open Dashboard window), #100477 (orphaned tunnel leak). Related but distinct: #99092 (static bundle fetch fails during gateway restart → "Control UI did not start" watchdog). This issue is about the post-load WebSocket lifecycle.