Fix Pairing Required Loop After npm Update
Known Open Issue — Workaround Required
This is tracked in openclaw/openclaw#21267. After running npm update or npm install -g openclaw@latest, the device approval works once but fails again on the next request — creating an infinite pairing loop.
The root cause is a version skew between the updated CLI and the still-running gateway process. The CLI generates a token with the new version's format, the gateway validates it with the old version's logic, and the mismatch causes a loop where openclaw devices approve succeeds but the next request fails with "pairing required" again.
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Jump to Section
What the Loop Looks Like
You'll see this pattern repeating in the gateway logs and/or your chat interface:
The key indicator is that approval succeeds but the device gets rejected again on the very next request. If approval itself fails, you have a different issue — see Pairing Required (1008).
Why This Happens
CLI and gateway version skew
When you run npm install -g openclaw@latest, the CLI binary is updated immediately. But the gateway is a separate long-running process — it keeps using the old version until restarted. The new CLI generates device tokens with a format the old gateway doesn't fully recognize, causing validation failures after the first successful handshake.
Token state file desynchronization
OpenClaw stores device approval state in two files: ~/.openclaw/devices/paired.json (approved devices) and ~/.openclaw/identity/device-auth.json (device identity). During an update, these files may reference different token versions or formats, causing cross-validation to fail.
Hot-reload token invalidation
If the gateway detects a version change and performs a hot-reload, it regenerates internal session tokens but doesn't invalidate the paired device list. The paired devices have tokens signed with the old key, which no longer matches the new internal state.
Fix: Full Resync (4 Steps)
This fix takes about 60 seconds
The key is to stop the gateway, clear stale token state, restart with the new version, and approve once cleanly.
openclaw gateway stop
# Backup (in case you need to rollback) cp ~/.openclaw/devices/paired.json ~/.openclaw/devices/paired.json.bak 2>/dev/null cp ~/.openclaw/identity/device-auth.json ~/.openclaw/identity/device-auth.json.bak 2>/dev/null # Clear stale token state rm -f ~/.openclaw/devices/paired.json rm -f ~/.openclaw/gateway/.lock
openclaw gateway start
openclaw devices list openclaw devices approve <request-id>
Why clear paired.json?
The old paired.json contains device tokens signed with the previous version's key. Deleting it forces a fresh pairing flow with the new version. Your device-auth.json (device identity) is preserved — only the approval state is reset.
Confirm It's This Issue
Before running the full resync, verify these three conditions:
Approval succeeds but pairing fails again within 1-2 requests
This is the hallmark of version skew. If approval itself fails, see Pairing Required (1008) instead.
Problem appeared immediately after npm update
Timing is the strongest signal. If pairing was already broken before the update, the cause is different.
Gateway and CLI show different versions
Run openclaw --version and check gateway logs for the startup version line. If they differ, version skew is confirmed.
# CLI version openclaw --version # Gateway version (in logs) openclaw logs --tail 50 | grep -i "version\|started\|boot"
Verify the Fix
# 1. Doctor should pass openclaw doctor # 2. Gateway should be healthy openclaw gateway status # 3. Send 3+ requests — no pairing errors openclaw logs --tail 100 | grep -Ei "pairing required|device token mismatch" # Expected: no output (empty = fixed)
The fix is confirmed when you can send 3+ consecutive requests without seeing "pairing required" in the logs. If the loop was going to recur, it would appear within the first 2 requests.
Prevent in Future Updates
Safe Update Checklist
Stop the gateway before updating
Run the update
Start the gateway (now running new version)
Verify health immediately
The critical step is stopping the gateway first. This ensures no version skew between the CLI and the running gateway process. If your setup uses systemd or LaunchAgent, stop the service before updating.
Still Looping?
If the loop persists after the full resync:
openclaw gateway stop # Remove ALL device state (will require re-pairing all devices) rm -rf ~/.openclaw/devices/ rm -rf ~/.openclaw/identity/ openclaw gateway start # Re-pair from scratch
Run the Doctor
Checks device pairing state, token file consistency, gateway version, and overall health.
Related Issues
Other pairing and token errors:
Fix It Faster With Our Tools
Config Wizard
Generate a production-ready clawhub.json in 30 seconds.
Local Doctor
Diagnose Node.js, permissions, and config issues instantly.
Cost Simulator
Calculate your agent burn rate before you get surprised.
Gateway Monitor
Detect token spikes and gateway incidents before users complain.
Skill Finder
Describe your use case and find the right Claude Code skill instantly.
Did this guide solve your problem?