OpenClaw has landed a Control UI recovery fix for a common browser edge case: an already-open tab can miss a Gateway update while the browser is suspended. PR #140484, "fix(ui): recover tabs after missed Gateway update notifications," merged on September 6, 2026 at 22:56 UTC.
The problem was not that the update failed. It was that a tab could remain on an old build after the update had already completed. When the user returned, the document might have missed both the service-worker activation announcement and the finished replacement.
The result was awkward: opening a new tab could be the practical way to get back onto the current build.
What Changed
The Control UI page now reconciles the active worker's embedded build identity even when no new update is discovered. That reconciliation runs through startup, controller changes, and existing foreground, online, and history recovery paths.
The implementation waits for an installing replacement first, so a newer document is not reloaded by an older active worker. It also rechecks ownership across asynchronous queries and avoids treating the worker registration URL as the current build identity.
The PR replaces several older patterns, including timed document probes, forced worker navigation, and per-client reload-marker caching. The existing reload scheduler remains responsible for reachability, unsaved-work protection, loop prevention, and Gateway target precedence.
Drafts Stay Protected
The most important user-facing detail is that recovery is not allowed to trample unsaved work.
Existing tabs can recover without opening a new tab, and the current route plus stored draft survive recovery. Newer settings drafts block automatic recovery until they are saved or explicitly discarded. Older settings tabs do not receive broadened forced-reload announcements.
That distinction matters because update recovery is only useful if it does not cost users their local edits.
Why It Matters
OpenClaw operators often leave Control UI tabs open across long-running tasks, Gateway updates, suspended laptops, mobile browser pauses, and network changes. Service-worker update paths have to handle the boring but real cases where the tab was asleep at exactly the wrong time.
This PR makes the tab inspect the active build state when it resumes, rather than depending solely on having heard the original update event.
For people running OpenClaw as an always-on control surface, that is a quality-of-life improvement. The current page can catch up to the Gateway instead of silently sitting on stale code.
Validation
The PR includes a regression for the missed-activation path that failed before the fix. It also reports 180 focused worker, cache, reload, config draft, and capability tests.
Production-bundle Chromium E2E coverage passed for four scenarios: deep-link boot, missed activation preserving a chat draft, raw config staying intact until explicit discard and recovery, and same-version update with owned terminal recovery.
The maintainers also ran an isolated native WebKit owner-boundary proof with the real service worker and compiled page recovery owners. That proof preserved the draft and deep-link query and fragment while moving from the old build to the new one.
For users, the visible outcome is calmer update handling: suspended Control UI tabs can recover after missed Gateway update notifications without losing the route or draft that made the tab worth preserving.