OpenClaw Main Restores Dashboard Setup and Device-Auth Recovery
Merged Control UI fixes recover interrupted onboarding, repair post-upgrade pairing and enforce origin checks for Tailscale-authenticated avatar reads.
OpenClaw has merged a second recovery wave for Control UI access. It targets two operational traps: dashboard assets or setup state that never recover after interrupted onboarding, and a browser that cannot regain pairing after a device-auth upgrade.
A companion security fix permits Tailscale-identity-authenticated avatar reads while enforcing request origins and rejecting wildcard ambient origins.
The changes are on main. No supplied source record identifies a packaged release containing them.
Interrupted setup must be resumable
PR #118388 repairs dashboards that fail to load and first-time setup that remains stuck after interruption. The upstream record also calls out the managed-proxy bypass boundary, so recovery should not be implemented by broadly weakening authentication.
PR #118038 separately builds dashboard assets before onboarding needs them. A successful daemon start is not a sufficient readiness signal if the first browser request reaches assets that were never prepared.
Operator impact: onboarding needs an idempotent resume path. Killing setup between credential creation, Gateway startup and dashboard load should not leave an installation that appears live but cannot present its recovery interface.
Post-upgrade pairing can recover from the dashboard
PR #118231 restores Control UI access after device-auth upgrades. This follows an earlier migration fix for installations moving away from retired device-auth bypass behaviour; the new work covers recovery from the dashboard and preserves a headless path.
The security contract matters as much as availability. Recovery should restore the current operator’s ability to pair—it should not recreate a permanent bypass or expose other pending pairing requests.
Keep shell or console access available during the first upgrade test. If the browser loses access, recovery should use the supported pairing flow rather than deleting device state or disabling authentication.
Tailscale avatar reads retain an origin boundary
PR #118353 fixes Control UI avatars under Tailscale identity authentication while enforcing avatar request origins and rejecting wildcard ambient origins.
An image endpoint can still carry authenticated user data and ambient browser credentials. Making avatars load through Tailscale identity does not justify accepting requests from any web origin.
Operators using Serve or another tailnet-only route should test the exact dashboard origin. Do not replace a rejected origin with * merely to remove a broken image icon.
Recovery matrix
Run this on a disposable installation or protected staging copy:
| Boundary | Test | Required result |
|---|---|---|
| Asset readiness | Start onboarding from a clean checkout/package | Dashboard assets exist before the browser is opened |
| Interrupted setup | Stop setup at several non-destructive phases, then resume | One canonical configuration survives and the dashboard becomes available |
| Device-auth upgrade | Upgrade a browser from the affected legacy state | Supported recovery pairing succeeds without a permanent bypass |
| Headless recovery | Repeat without automatic browser launch | Operator receives a usable supported recovery path through the intended channel |
| Competing browser | Attempt recovery from another browser | It cannot inherit the first browser’s authority or see unrelated pairing state |
| Tailscale identity | Load the dashboard and avatars from the intended tailnet origin | Avatar succeeds only for the permitted origin and authenticated identity |
| Hostile origin | Request the avatar from an unrelated origin | Request is rejected; no permissive wildcard is required |
Back up configuration and device-auth state before the test. Do not paste recovery URLs, pairing codes or bearer material into tickets or chat logs.
Incident response
If a production dashboard is blank after upgrade:
- preserve logs, configuration and device state before rerunning setup;
- distinguish missing assets from failed authentication and failed Gateway startup;
- check whether the browser is being offered a supported pairing recovery;
- keep the Gateway on its intended loopback, tailnet or proxy boundary; and
- avoid emergency wildcard origins or disabled device auth.
A blank dashboard is an availability symptom, not evidence that the underlying Gateway is idle. Check active agents and scheduled work before restarting or replaying commands.
Evidence and limits
The official merged PR, commit and documentation records supplied by the repository collector establish the reported recovery and origin fixes. Direct GitHub page extraction returned HTTP 403 and the configured search backend was unavailable. OpenClaw Academy did not interrupt a real onboarding flow or perform a device-auth migration behind Tailscale.
Relevant collector IDs are 34918/34808/34873, 34592/34485/34547, 34912/34802/34872 and 34599/34492.
Bottom line
The safe fix for a broken dashboard is resumable setup and narrowly scoped pairing—not an authentication bypass. Stage interruption, upgrade and Tailscale-origin tests together before relying on the Control UI as the recovery surface for a live Gateway.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF