OpenClaw Main Repairs Live Update, Plugin Rollback and First-UI Availability

OpenClaw has merged a coordinated set of Gateway maintenance and cold-path fixes. The live updater now puts wall deadlines around commands that could leave the service fenced or stopped forever; failed plugin/config operations restore only the index revision they own; completed state migrations can be skipped safely by later short-lived processes; and agents.list no longer performs synchronous provider discovery during the first Control UI connection.

These changes are on main. No supplied release establishes package inclusion. Operators should not run a source updater merely to obtain the updater fix: stage a known containing artifact with rollback and out-of-band access.

The live updater could wait forever after stopping service

PR #119116 reports that maintenance-owned dependency installation, builds, service actions and probes lacked wall deadlines. A child process could remain alive without useful progress while the Gateway stayed fenced or stopped, preventing rollback, lock release and terminal JSON output.

The repair gives external phases explicit budgets and manages Unix child process groups. Output does not reset the deadline. At timeout, cleanup is bounded; if the updater cannot prove the stopped-state command tree is gone, recovery fails closed and retains the maintenance lock rather than restarting the previous service beside an uncontrolled updater process.

That choice can still leave the Gateway offline, but it converts an unbounded and potentially concurrent mutation into a bounded, diagnosable state. A later heartbeat may reclaim the lock after the exact process group is gone.

The merged Windows behavior is deliberately conservative: strict descendant verification is not available through the current owner, so the updater refuses before the pre-stop fetch and leaves the Gateway untouched. Do not bypass that guard with an ad-hoc process launcher.

PR #119096 adds bounded structured diagnostics that separate primary, proof, cleanup and rollback failures without copying command lines, environment, paths, PIDs, stdout or stderr into the receipt.

Plugin rollback now proves revision ownership

PR #119228 fixes several ways a failed plugin, channel, setup or post-core update could leave the installed-plugin index inconsistent with effective configuration—or restore a stale snapshot over a newer concurrent mutation.

The persisted-index owner now issues monotonic write revisions, holds one lifecycle lease across the tentative index write and paired config commit, and restores only while that exact tentative revision remains current. A successor write wins.

Interpretation: rollback is itself a mutation. It must prove ownership just as rigorously as the write it is undoing, otherwise error recovery can destroy newer valid state.

This change reports no config or SQLite schema migration, but operators still need a consistent backup. “No schema change” does not make concurrent rollback safe on an older binary.

Completed migrations no longer run in every CLI process

PR #119051 adds a durable state-completion checkpoint bound to immutable build provenance plus effective configuration and plugin migration identities. After one clean automatic pass, later short-lived local agent and state-owning CLI processes can skip broad migration discovery.

The checkpoint is intentionally narrower than Gateway readiness. Explicit Doctor repair bypasses it, changed config/plugin migration inputs invalidate it, and the Gateway still owns plugin convergence before declaring readiness.

This also persists a legacy derived plugin index instead of rediscovering it in every new process.

First Control UI load stops blocking the event loop

PR #119208 moves agents.list onto the model catalog already published by Gateway startup. Previously, the read-only RPC could begin synchronous provider discovery on the request path, preventing its intended timeout and delaying unrelated RPCs and liveness timers.

Upstream’s exact-environment reproduction measured agents.list at 43.4 seconds before the change and 227 ms after it, with all observed candidate bootstrap RPCs at or below 913 ms. Those are upstream observations, not portable performance promises.

The architectural point is stronger than the benchmark: startup owns model-catalog publication; roster reads should consume that fact rather than rediscover providers.

Safe rollout

1. Record the exact current revision, service manager and updater ownership mode.
2. Take a consistent backup of Gateway state, plugin index/config and relevant sidecars.
3. Verify an out-of-band path can restore the previous service without the live updater.
4. In staging, stall a harmless pre-stop phase and require timeout with the service unchanged.
5. Stall a harmless post-stop child and require bounded cleanup or explicit retained-lock failure.
6. Race a failed tentative plugin write with a newer successful write; prove rollback cannot overwrite the successor.
7. Run one migration pass, then several short-lived CLI processes; prove the checkpoint skips only when identities match.
8. Open the Control UI against a production-sized provider roster and monitor RPC latency, liveness and memory.

Never test process-tree cleanup by killing a production updater or deleting its lock manually. Preserve the receipt and prove whether the owned child group still exists first.

Evidence and limits

Official merged PR and commit records establish the updater, plugin-index, migration and roster faults. Upstream provides focused process, SQLite, browser and RPC evidence. OpenClaw Academy did not stop a live Gateway, induce a plugin commit race or reproduce the cited timing and memory observations.

Key collector IDs are 37711/37664, 37625/37582, 38090/38027, 37944/37919 and 37945/37920.

Bottom line

Maintenance code is part of the availability boundary. Adopt a containing build through an external rollback plan, then prove updater timeouts release or retain ownership correctly, failed plugin writes cannot erase successors, migration checkpoints do not overclaim readiness, and first-UI reads consume startup facts instead of rebuilding them.