openclaw - 💡(How to fix) Fix openclaw update can succeed while the running gateway stays on an older version, causing plugin/config version skew [1 comments, 2 participants]

Summary

openclaw update can succeed, but the running gateway/app service can still come back on an older runtime. In our case, the update path and the service path appeared to drift apart, which left the system in a broken mixed-version state.

What happened

• The machine successfully updated OpenClaw via CLI from 2026.4.21 to 2026.4.24, and later the installed packages were at 2026.4.26.
• However, the running gateway continued to identify itself as 2026.4.15.
• Because of that skew, plugins and config intended for newer versions were rejected by the older runtime.
• From the user side, this made the update look successful while the actual running system was still effectively old/broken.

Evidence

1) Successful CLI update

From /tmp/openclaw-update-2026.4.23-20260425-000842.log:

=== BEFORE VERSION ===
OpenClaw 2026.4.21 (efb7d42)
...
Update Result: OK
  Before: 2026.4.21
  After: 2026.4.24
...
Tip: Run `openclaw gateway restart` to apply updates to a running gateway.

2) Running gateway still thought it was 2026.4.15 afterward

From /Users/cawl/.openclaw/logs/gateway.log:

2026-04-28T09:26:47.288+07:00 [gateway] update available (latest): v2026.4.26 (current v2026.4.15). Run: openclaw update

Also from /tmp/openclaw/openclaw-2026-04-28.log:

update available (latest): v2026.4.26 (current v2026.4.15). Run: openclaw update

3) Newer plugins/config were rejected because the host was still seen as 2026.4.15

From /tmp/openclaw/openclaw-2026-04-28.log:

Invalid config at /Users/cawl/.openclaw/openclaw.json:
- plugins.entries.feishu: plugin feishu: plugin requires OpenClaw >=2026.4.25, but this host is 2026.4.15; skipping load
- plugins.entries.google-meet: plugin google-meet: plugin requires OpenClaw >=2026.4.20, but this host is 2026.4.15; skipping load
- plugins.entries.whatsapp: plugin whatsapp: plugin requires OpenClaw >=2026.4.25, but this host is 2026.4.15; skipping load

4) LaunchAgent metadata still advertised the old version

Sanitized output from ~/Library/LaunchAgents/ai.openclaw.gateway.plist:

{
  "Comment": "OpenClaw Gateway (v2026.4.15)",
  "ProgramArguments": [
    "/Users/cawl/.openclaw/tools/node-v22.22.0/bin/node",
    "/Users/cawl/.openclaw/lib/node_modules/openclaw/dist/index.js",
    "gateway",
    "--port",
    "18789"
  ],
  "OPENCLAW_SERVICE_VERSION": "2026.4.15"
}

5) Installed packages were newer than the service metadata

At the time of inspection:

/Users/cawl/openclaw/package.json -> 2026.4.26
/Users/cawl/.openclaw/lib/node_modules/openclaw/package.json -> 2026.4.26
openclaw --version -> 2026.4.26

Expected behavior

If openclaw update succeeds and the gateway is restarted, the running gateway/service should come back on the same updated version, or the update command should clearly fail with a remediation step if that cannot be guaranteed.

Actual behavior

The CLI/update path reported success, but the running gateway still identified as an older version (2026.4.15), causing plugin/config incompatibility and a broken mixed-version state.

Why this is confusing / severe

This is especially hard to diagnose because:

• openclaw update reports success
• installed package versions look correct
• but the running gateway still behaves like an old build
• plugin failures then look like config problems rather than update/service-path skew

Suspected root cause

Some combination of these:

1. The CLI update target and the launchd-managed gateway target are not guaranteed to be the same runtime.
2. Service metadata / launch agent state can remain pinned to an older version even after update.
3. Restarting the gateway is not enough if the service definition itself is stale or gets rewritten incorrectly.

Suggested fixes

• Make openclaw update verify the version of the running gateway after restart, not just the installed package.
• Detect and warn when the CLI install target and service runtime target differ.
• Treat version skew between installed CLI and running gateway as a first-class doctor/status error.
• Regenerate or validate service metadata (OPENCLAW_SERVICE_VERSION, launch agent comment/version stamp, runtime path) during update/restart.
• Consider an explicit openclaw doctor update-paths / openclaw status check that prints both:
  • installed CLI version
  • running gateway version
  • service-managed runtime path

Environment

• macOS (launchd-managed gateway)
• OpenClaw CLI eventually at 2026.4.26
• Gateway repeatedly reporting 2026.4.15

Repro sketch

I can’t guarantee these are minimal repro steps, but the observed path was roughly:

1. Have an older launchd-managed gateway install active.
2. Run openclaw update successfully.
3. Restart the gateway.
4. Observe that the CLI and package versions are updated, but the gateway still reports the older version.
5. Enable plugins/config requiring newer OpenClaw versions.
6. Observe plugin load failures because the running host still thinks it is the old version.