OpenClaw merged PR #125027, a P2 Control UI fix for stale-page recovery when the Gateway updates or restarts.
The bug lived in a small but visible moment: a protocol-mismatch page offered a Refresh page action, but clicking it while the Gateway was restarting could navigate into an error page. That is exactly when users need the recovery path to be calm and predictable.
What Changed
The repaired refresh action now waits for the served Gateway to answer before navigating. While it waits, the UI shows a refreshing state. If the bounded wait fails, the user gets a retry path instead of being pushed into a broken page.
The PR also keeps cancellation tied to the active failure state. Connecting, changing the target or credential, dismissing the failure, or replacing the login gate cancels the old attempt. Unsaved-input guards remain binding.
The result is a more disciplined recovery flow:
- A failed HEAD probe during shutdown does not trigger navigation.
- Credential edits cancel recovery and preserve typed input.
- A later retry performs one cache-busting navigation.
- Service-worker recovery moves from the old build to the new build.
- Existing privacy and authentication boundaries are preserved.
The PR explicitly notes that already-open pre-fix JavaScript cannot gain this behavior retroactively. Users need a build that includes the fix.
Why It Matters
Control UI recovery is one of those paths users notice only when something has already gone sideways. A Gateway restart, protocol mismatch, or app update should not make the interface feel like it is arguing with itself.
Waiting for the Gateway before navigation is a better mental model. The page says it is recovering, checks whether the served Gateway is actually ready, and either moves forward once or leaves the user in a bounded retry state.
That is especially important for OpenClaw installations where the Control UI is the user's main window into local agents, credentials, sessions, and Gateway status. Recovery pages need to protect state, not create a second failure.
The Proof
The PR says the new handoff regression fails on unchanged current main and passes with the repaired candidate. It also reports 92 focused and sibling tests, required changed-source checks, formatting, dependency and source guards, export scans, lint, and UI style checks.
The behavior proof used real Chromium, production bundles, an isolated real Gateway, the same loopback origin, and a production service worker. The fixture injected only the old client protocol range into the initial connect request, while Gateway rejection, HTTP probes, service-worker handling, Gateway stop and start, rendered interaction, and navigation were real.
Hosted UI validation also passed across all three UI test shards and all 13 hosted UI end-to-end shards on the reported head before the final native merge verification.
What To Watch
PR #125027 does not add a new recovery service or dependency. It tightens the manual refresh path around the active failure and the currently served Gateway.
For users, the visible effect should be simple: when the Control UI gets stale during a Gateway update, refresh recovery should stay on the recovery page until it has a real destination.