Multi-device Max subscription: refresh token invalidated hours after another device logs in (cross-device logout ping-pong, 2.1.217)

Environment

• Claude Code 2.1.217 (npm install, single install verified), Windows 11
• One Max subscription used on 3 machines (2 desktops + 1 laptop), standard /login on each — no CLAUDE_CODE_OAUTH_TOKEN env var, no custom scripts touching credentials (a read-only monitor samples ~/.claude/.credentials.json mtime/hash every 30 min, plus per-device heartbeats to correlate machines)

Summary

Recurring forced re-logins across devices for ~a month. The evidence points to server-side refresh-token invalidation with a delayed symptom: a /login (or refresh) on device A appears to invalidate device B's stored refresh token; B only notices hours later, when its access token expires and the refresh fails — the CLI then demands /login even though the refresh token is still physically present on disk.

Signature from 2026-07-22 (local times, desktop = device with monitoring)

• 06:18 — desktop access token expired while idle (~8 idle claude.exe). 06:59 — CLI auto-refreshed successfully on its own (new refresh token, +8h). Normal, healthy.
• 09:12 — laptop woke after 4 days off: credentials already invalid → forced /login. (While it slept, the desktop rotated its own chain many times.)
• 14:59 — desktop token expired idle again. 15:30 snapshot: refresh token still intact on disk (file untouched since 06:59). ~15:40 — CLI demanded /login: the refresh either failed server-side or was never attempted. 15:52 — manual /login.
• The credential file's mtime was frozen from 06:59 to 15:52 → this is not the local concurrent-write race that the May changelog fixed.

The suspicious correlation: the desktop's refresh token that died at ~15:40 was minted at 06:59, before the laptop's 09:12 /login. Pattern repeats in both directions (whichever machine is not used gets logged out).

Ruled out

• Keep-warm/nudge scripts: all disabled since 07-21; monitor is read-only.
• Duplicate installations: single npm install; all 9 running processes use the same 2.1.217 binary.
• Local terminal race: credential file frozen for hours before each event.
• Other device active at the same moment: cross-device heartbeats show the other machine was not running in the hour before any logout (the invalidation appears lazy/deferred, not immediate).

Questions

1. Are subscription OAuth refresh grants per-device, or can a /login/refresh on one device invalidate refresh tokens stored on other devices of the same account (immediately or lazily)?
2. Is there an undocumented session/device cap for Max accounts that silently revokes older grants?
3. If cross-device invalidation is expected behavior, could the CLI surface a clear message (e.g. "signed out because this account signed in elsewhere") instead of a silent logout — and/or proactively refresh before the grant goes stale?

Related: #60503 (closed May 2026 — this reproduces on 2.1.217 which includes that fix), #61923, #54443, #43801.