openclaw - 💡(How to fix) Fix v2026.5.12 agent-invoked self-update can leave macOS LaunchAgent unloaded or fail before package swap

Scope

Three macOS LaunchAgent-backed OpenClaw instances were asked to update themselves to v2026.5.12 from inside OpenClaw/agent conversations. This report is sanitized: hosts are referred to as Host A, Host B, and Host C, and no private addresses, tokens, local usernames, or machine names are included.

This appears related to the existing macOS LaunchAgent/update handoff class of issues, but the user-facing failure mode here is narrower: asking the running OpenClaw agent to update the OpenClaw process that is running it can leave the operator with either an upgraded-but-offline instance or a not-upgraded/offline instance.

Outcome

Evidence

Host A after the failed self-update:

OpenClaw 2026.5.12 (f066dd2)
Service: LaunchAgent (not loaded)
Connectivity probe: failed
LaunchAgent plist exists but launchd has no loaded job.

Host A repair:

Gateway LaunchAgent was installed but not loaded; re-bootstrapped launchd service.
CLI version: 2026.5.12
Gateway version: 2026.5.12
Runtime: running
Connectivity probe: ok

Host B before repair:

OpenClaw 2026.5.12-beta.8 (097daf9)
Update: available · pnpm · npm update 2026.5.12
Service: LaunchAgent (not loaded)
Connectivity probe: failed

Host B manual update:

Update Result: OK
Before: 2026.5.12-beta.8
After: 2026.5.12
Restarting service...
Gateway already reports the updated version after service refresh; skipped redundant restart.

All hosts final verification:

CLI version: 2026.5.12
Gateway version: 2026.5.12
Service: LaunchAgent (loaded)
Connectivity probe: ok
Capability: admin-capable

Diagnosis

The failure appears tied to running an update from inside the OpenClaw-managed agent/gateway path. The updater has to stop or refresh the same gateway that is supervising the user-visible agent conversation. In this run, that left one host with the package successfully upgraded but launchd no longer supervising the service, and a second host still on the prior beta with the service not loaded. Running the update from outside the gateway via SSH completed reliably.

For non-engineer operators, the most damaging part is the missing durable completion signal: the agent conversation can die or stop responding before it tells the user whether the package swap happened, whether launchd loaded the gateway, or which repair command to run.

Secondary observations

Host B still has stale lossless-claw plugin config entries. The stable gateway ignores them, but openclaw gateway status --deep repeats warnings:

plugins.entries.lossless-claw: plugin not found: lossless-claw
plugins.allow: plugin not found: lossless-claw

Host A had unrelated openai-codex OAuth refresh failures during earlier smoke testing. That explains some agent-run failures, but not the LaunchAgent unloaded state after the package update.

Suggested maintainer fixes

1. Detect when openclaw update is invoked from inside a managed gateway/agent session and either refuse with a clear handoff command or schedule the update into a detached supervisor process.
2. Make the final update health check fail if the package version changed but the LaunchAgent is installed and not loaded, and print or perform the same re-bootstrap path used by openclaw gateway restart.
3. Add an explicit "self-update completed, service loaded, gateway reachable" confirmation that can survive the gateway restart and be delivered back to the initiating channel.
4. Add a regression test or integration harness for macOS LaunchAgent self-update handoff: beta-to-stable update, service stop/restart, launchd load state, and gateway reachability.

Operator workaround

Until this is fixed, avoid asking an OpenClaw agent to update the OpenClaw process that is running it. Update from an outside shell/SSH session instead, then verify:

openclaw update --tag 2026.5.12 --yes --timeout 1800
openclaw gateway status --deep
openclaw channels status --deep

If the package version is current but the gateway is unreachable:

openclaw gateway restart
openclaw gateway status --deep