You run npm install -g openclaw@latest. The CLI confirms the new version. You check the running service — it’s still on the old one.
The binary upgraded. The daemon didn’t notice.
The Problem
After upgrading OpenClaw via npm:
npm install -g openclaw@latest
openclaw --version
# ✅ 2026.3.1
openclaw health
# ❌ gateway version: 2026.2.15
The running service is still on the previous version. systemctl --user restart openclaw-gateway doesn’t help — it restarts the same stale service definition.
Why This Happens
npm install -g updates the binary, but the systemd service file — written to ~/.config/systemd/user/openclaw-gateway.service — was generated at first install and never touched again. It points to the node binary and script path from the original install. On restart, systemd uses that old definition, which loads the old version.
The service file and the installed binary are two separate things. npm only updates one of them.
The Fix
Regenerate the service file with the --force flag, then restart:
# 1. Reinstall the service definition
openclaw daemon install --force
# 2. Reload systemd and restart
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway
# 3. Confirm the right version is running
openclaw health
Expected output from openclaw health:
gateway version: 2026.3.1
status: running
The --force flag overwrites the existing service file without prompting. Your config (openclaw.json) and all workspace files are untouched — only the service definition changes.
Key Takeaway
OpenClaw upgrades are a two-step operation: update the binary with npm, then update the daemon with openclaw daemon install --force. If you only do the first step, the service keeps running the old version silently. Add both steps to your upgrade runbook so you don’t spend four minutes wondering why the version number looks right everywhere except where it matters.