OpenClaw merged a high-priority update safety fix Tuesday morning in PR #160663, titled fix: protect live Gateways sharing an update installation.
The change targets a sharp operator edge case: package and source updates could replace a shared installation while another managed Gateway was still serving from that same physical root. The new behavior refuses publication when OpenClaw can positively observe a live sibling Gateway using the shared install.
The Problem
OpenClaw's updater already protected build output writes, but package publication changes more than dist. It can replace dependencies and installation files that another Gateway process may still be using.
That is risky in multi-profile or managed-service setups where two Gateways point at the same package root. If one updater replaces files underneath a sibling Gateway, the sibling may keep serving with a half-old, half-new runtime until it restarts or fails.
The PR frames this as a controlled stop-first workflow. The selected updater should not silently take control of unrelated sibling services. Instead, if a live shared consumer is observed, publication is blocked before the selected Gateway is stopped.
New Update Behavior
The merged fix adds a common publication boundary that checks for live consumers of the installation's physical roots. It also keeps a second check at artifact publication time, which protects against a race where the environment changes after initial preparation.
The operator-facing result is straightforward:
- A live sibling using the same installation blocks publication.
- Operators stop sibling Gateways through their own service managers or exact startup entries.
- The updater does not claim authority over services it did not select.
--no-restartstill permits publication while the selected service runs, relying on the installation-change watcher where appropriate.- Unknown identity, uncertain cleanup, or lost authority keeps recovery conservative.
On macOS, the implementation reads the loaded service definition in the right GUI or System domain so it can still see a running job when its loaded plist differs from the discovered file. That distinction matters because a service can be live even when file paths or definitions have moved.
Recovery Improvements
The PR also repairs several related lifecycle issues uncovered during native proof.
Staged settlement no longer replays an already-delivered refusal. Untouched activation journals no longer block later updates. Runtime retention excludes private activation-control state instead of hardlinking it into retained runtime dependencies.
Another important fix is delegated Doctor stop adoption. An earlier run could publish successfully but leave the selected Gateway stopped because Doctor had recorded a stop receipt that only migrated finalization consumed. Ordinary and migrated finalization now share the adoption path, verify service identity, and preserve partial-stop failures.
Why Operators Should Care
This is not a shiny feature, but it is exactly the sort of guardrail that makes OpenClaw safer to run as real infrastructure.
Shared installations are common in managed hosts, test fleets, and advanced desktop setups. The worst version of this failure is subtle: one Gateway appears healthy while its files have been replaced out from under it. Blocking publication in the observed-live-sibling case turns that into an explicit operator decision.
The PR reports extensive Linux and macOS proof, including live shared-sibling refusal, stopped-sibling success, disjoint-install success, update recovery tests, and service identity checks. The remaining caveats are also recorded directly in the PR, including unclaimed automatic Windows completion and positive-live macOS System-domain proof.
For OpenClaw maintainers and self-hosters, the main takeaway is simple: update publication is now more conservative when installations are shared, and that is the right bias for availability.