OpenClaw has merged a major reliability fix for one of the riskiest everyday workflows: asking an agent to update itself from chat. PR #136588, merged on September 3, restores an owner-gated update.run path and makes chat-triggered updates end in a visible outcome instead of disappearing into a restart boundary.
The problem was not theoretical. The PR describes chat updates as a common way OpenClaw installs could die: the agent no longer had the right update operation, improvised through shell commands, hit the Gateway ancestry guard, and could end up killing the service that owned its own command. Even successful updates could finish invisibly if the restart sentinel woke the wrong route or collapsed into a heartbeat.
What Changed
The new path gives OpenClaw a real chat-owned update workflow again. Owner sessions can call update.run through the Gateway tool, and an owner-only /update command mirrors the existing restart gate. Both routes dispatch through the hosting Gateway with a 20-minute deadline and carry the originating session and delivery route.
The Gateway now sends a bounded durable acknowledgement before update work starts. That matters because the service may restart or drain while the update is in progress. The acknowledgement gives the user an explicit "updating" notice before the risky portion begins, and synchronous failures after that point send their own failure notice.
Restart outcomes are also routed back into a real conversation. Session-less sentinels now fall through to the operator main session or a recent eligible direct chat instead of relying on a model wake that might answer with silence. Control UI sessions get restart outcomes appended to the existing transcript rather than starting a second model turn.
Security Boundary
This is a security-boundary story as much as a convenience fix. The PR keeps update authority owner-gated and revalidates revocable external chat senders against current owner configuration. Non-owner sessions are told to hand off to the owner instead of receiving instructions for a capability they do not have.
The fix also avoids teaching agents to stop the Gateway that owns their shell. The prompt and tool guidance now explain the managed path and preserve manual instructions where an operator should run the update outside the owning service.
User Impact
For operators, the expected behavior is clearer:
- An owner can request an update from chat or Control UI
- OpenClaw sends a visible acknowledgement before restart-sensitive work
- Restart completion or failure is delivered back to the originating route when possible
- Health checks require sustained runtime health instead of accepting a single passing probe
- Failed package staging preserves and re-verifies the original package version
The result is not just that updates can run again. It is that users get a bounded, observable contract around a workflow that crosses package installation, service restart, session ownership, and external channel delivery.
Verification
The PR reports several focused proof points: 420 tests for the restored update path, 140 Gateway tests, 70 conformance and selector tests on the final rerun, 61 UI tests, and pnpm check:changed. It also documents one unchanged archive-publication timing failure in a broader sessions run, with the affected conformance file passing on rerun.
For anyone managing OpenClaw through Telegram, Discord, WhatsApp, Slack, or the Control UI, this is one of the most important reliability fixes in the September 3 morning window.
PR #136588 · merged September 3, 2026 · source: OpenClaw GitHub