Summary

I updated three independent macOS OpenClaw installs to 2026.5.12-beta.4 and all three completed successfully, but each update emitted the same confusing restart-phase warning: the config had been written by 2026.5.12-beta.4 while the command was still running as the previous OpenClaw version. The gateway did end up healthy on 2026.5.12-beta.4, so this looks like an updater self-staleness/reporting bug rather than a failed update.

Environment

Sanitized across three hosts:

• OS: macOS 26.4.1 arm64
• Node: 25.9.0
• Install root: <global-openclaw> (Homebrew/global npm style)
• CLI shim: <user-bin>/openclaw
• Gateway: managed LaunchAgent, loopback bind, port 18789
• Channel: beta
• Target: 2026.5.12-beta.4 (d124625)

Starting versions:

• Host A: 2026.5.12-beta.3
• Host B: 2026.5.10-beta.3
• Host C: 2026.5.12-beta.2

Update command used on all three:

openclaw update --channel beta --tag 2026.5.12-beta.4 --yes --timeout 1800

Actual Result

All three package updates reported success:

Update Result: OK
Root: <global-openclaw>
After: 2026.5.12-beta.4

Then all three emitted this restart-phase warning, with <previous-version> matching each host's pre-update version:

Restarting service...
Your OpenClaw config was written by version 2026.5.12-beta.4, but this command is running <previous-version>.
Check: `openclaw --version`, `which openclaw`, and `openclaw gateway status --deep`.
If unexpected, update PATH so `openclaw` points to the version you want, or reinstall the Gateway service from that same OpenClaw install.
Gateway already reports the updated version after service refresh; skipped redundant restart.

Post-update verification was healthy on all three:

• openclaw --version: OpenClaw 2026.5.12-beta.4 (d124625)
• openclaw update status: up to date · npm beta 2026.5.12-beta.4
• openclaw gateway status --deep: LaunchAgent loaded/running, connectivity probe OK, CLI version and gateway version both 2026.5.12-beta.4
• openclaw plugins doctor: No plugin issues detected (with the deprecation note below)
• Direct non-delivered agent checks succeeded on all three through openai/gpt-5.5, agentHarnessId: codex, fallbackUsed: false

Expected Result

For package-manager updates, the post-install restart/verification phase should either:

1. re-exec through the updated entrypoint before running service restart logic, or
2. recognize and clearly label this as expected updater self-staleness, not as an operator PATH/config mismatch.

The current message looks like a real version-skew problem even though the update succeeded and the gateway is already on the target version.

Why This Matters

This warning appeared on three out of three updates from three different previous beta versions. It is easy for an operator to read it as a failed or risky update and start reinstalling service definitions unnecessarily. If an older updater process intentionally remains in charge after the package swap, it would help to make that state explicit and keep the scary config-version guard wording for true mismatches.

Related Audit Findings

These are secondary observations from the same update audit; happy to split into separate issues if preferred.

plugins doctor emits deprecated config API warning while reporting no plugin issues

All three hosts printed:

plugin runtime config.loadConfig() is deprecated (runtime-config-load-write); use config.current().
No plugin issues detected.

If this is actionable, it would help to attribute it to a plugin ID/path. If it is expected/internal noise, it may be better suppressed from a clean plugins doctor result.

External plugin beta fallback could be clearer in the final update summary

On one host, a configured external plugin had no beta npm release and fell back to latest:

Plugin "lossless-claw" has no beta npm release for @martian-engineering/lossless-claw@beta; using @martian-engineering/lossless-claw@latest instead. Core update can still complete.

That seems reasonable, but the final update summary still just reads OK. A compact summary line such as "plugin channel fallback: lossless-claw used @latest because @beta was unavailable" would make mixed-channel plugin state easier to audit.

Not Treated As Update Regressions

• One host had a pre-existing stalled agent run before the update; the update restart cleared gateway reachability.
• One host had a pre-existing gateway token-source conflict; it remained after update.
• Task audit warnings about lost/delivery-failed tasks predated the update.
• A direct agent check containing the words "smoke test" triggered a local smoke-test skill and tool calls before returning OK; that appears to be a skill-trigger/operator-footgun observation, not an update failure.

Likely Source Areas

From the current checkout, the relevant areas look like:

• src/cli/update-cli/update-command.ts
• src/cli/update-cli.test.ts
• future-config guard tests under src/cli/daemon-cli/
• src/plugins/runtime/runtime-config.ts
• src/plugins/update.ts
• src/plugins/plugin-peer-link.ts