Subject: Device Token Mismatch After Update v2026.2.9 → v2026.2.15
✅Solved
Hi everyone 
We're experiencing a persistent device_token_mismatch error after updating from v2026.2.9 to v2026.2.15. Looking for help from anyone who's hit this.
Setup:
• VPS (Ubuntu, systemd user service)
• Gateway mode: local loopback, token auth
• Channels: Telegram
• Agent: embedded (runs inside gateway process)
Problem:
After the update, all gateway-dependent tool calls (cron, sessions_list, subagents, etc.) fail with:
gateway closed (1008): unauthorized: device token mismatch (rotate/reissue device token)
The embedded agent connects to the gateway via internal WebSocket but gets rejected on device auth.
What we've tried (all failed):
1. Rotated gateway.auth.token in openclaw.json
2. Multiple gateway restarts (systemctl --user restart)
3. Full cold purge (kill all processes + fresh start)
4. Deleted ~/.openclaw/identity/device-auth.json
5. Cleared ~/.openclaw/devices/paired.json and pending.json
6. Combined wipe of device-auth + paired + pending + cold restart
Our theory:
The v2026.2.15 changelog mentions:
Security/Pairing: generate 256-bit base64url device and node pairing tokens and use byte-safe constant-time verification (#16535)
Our device identity was created under v2026.2.9 (old hex-format tokens). We believe the new verification logic in v2026.2.15 rejects the old-format tokens, but the gateway isn't auto-migrating them on restart.
Questions:
1. Is there an openclaw device reset or openclaw gateway repair command to force re-registration?
2. Should we delete the entire ~/.openclaw/identity/ directory (including device.json keypair) to force new-format generation?
3. Would updating to v2026.2.17 (latest) resolve this, or do we need to manually reset first?
4. Has anyone else hit this after upgrading from pre-2.15?
Version: v2026.2.15 | Latest available: v2026.2.17 | OS: Ubuntu, systemd
Thanks for any help!
We're experiencing a persistent device_token_mismatch error after updating from v2026.2.9 to v2026.2.15. Looking for help from anyone who's hit this.
Setup:
• VPS (Ubuntu, systemd user service)
• Gateway mode: local loopback, token auth
• Channels: Telegram
• Agent: embedded (runs inside gateway process)
Problem:
After the update, all gateway-dependent tool calls (cron, sessions_list, subagents, etc.) fail with:
gateway closed (1008): unauthorized: device token mismatch (rotate/reissue device token)
The embedded agent connects to the gateway via internal WebSocket but gets rejected on device auth.
What we've tried (all failed):
1. Rotated gateway.auth.token in openclaw.json
2. Multiple gateway restarts (systemctl --user restart)
3. Full cold purge (kill all processes + fresh start)
4. Deleted ~/.openclaw/identity/device-auth.json
5. Cleared ~/.openclaw/devices/paired.json and pending.json
6. Combined wipe of device-auth + paired + pending + cold restart
Our theory:
The v2026.2.15 changelog mentions:
Security/Pairing: generate 256-bit base64url device and node pairing tokens and use byte-safe constant-time verification (#16535)
Our device identity was created under v2026.2.9 (old hex-format tokens). We believe the new verification logic in v2026.2.15 rejects the old-format tokens, but the gateway isn't auto-migrating them on restart.
Questions:
1. Is there an openclaw device reset or openclaw gateway repair command to force re-registration?
2. Should we delete the entire ~/.openclaw/identity/ directory (including device.json keypair) to force new-format generation?
3. Would updating to v2026.2.17 (latest) resolve this, or do we need to manually reset first?
4. Has anyone else hit this after upgrading from pre-2.15?
Version: v2026.2.15 | Latest available: v2026.2.17 | OS: Ubuntu, systemd
Thanks for any help!
Solution
Awesome — and thanks for circling back with the root cause.
For anyone hitting this later, the working fix is:
- Check systemd drop-ins for a stale injected token:
-
- look in
- Remove/update stale
- Then reinstall/re-sync the service (
-
-
If you haven’t already, please mark the solution in the thread (right-click the solution message → Apps →
Mark Solution) so Answer Overflow indexes it.
For anyone hitting this later, the working fix is:
- Check systemd drop-ins for a stale injected token:
-
systemctl --user cat openclaw-gateway.service- look in
~/.config/systemd/user/openclaw-gateway.service.d/override.confDropInPaths- Remove/update stale
OPENCLAW_GATEWAY_TOKENOPENCLAW_STATE_DIR- Then reinstall/re-sync the service (
openclaw gateway install-
systemctl --user daemon-reload-
systemctl --user restart openclaw-gateway.serviceIf you haven’t already, please mark the solution in the thread (right-click the solution message → Apps →
Mark Solution) so Answer Overflow indexes it.
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
130,529Members
Resources
Was this page helpful?
