Local CLI auth expires every ~12h during long-running Remote Control sessions (personal Max) — forced /login; docs claim credentials auto-refresh

Environment

• Claude Code: 2.1.198
• OS: macOS 26.2 (Darwin 25.2.0)
• Plan/auth: claude.ai Max (personal), OAuth via /login, credentials in macOS Keychain (single Claude Code-credentials slot verified — no stale duplicates)
• Terminal: iTerm2
• Typical workload: ~10 concurrent interactive claude processes sharing the same keychain credential

Bug

Long-running Remote Control sessions are the whole point of claude remote-control / /rc, but lately (recent regression, roughly the last few weeks) the local CLI loses authentication within ~12 hours: the terminal process itself drops to unauthenticated and requires /login again, which kills the Remote Control session from the machine side.

This is not the phone/browser surface logging out — the local process loses its grant.

Expected per docs

The Remote Control docs make long-running operation an explicit design goal and never state a session/sign-in lifetime for personal plans:

"Survive interruptions: if your laptop sleeps or your network drops, the session reconnects automatically when your machine comes back online"

"The connection uses multiple short-lived credentials, each scoped to a single purpose and expiring independently."

The only documented sign-in freshness window anywhere is the 18-hour rule for Trusted Devices, which is explicitly Team/Enterprise-only and shouldn't apply to a personal Max account. A ~12h forced re-login on personal Max matches no documented behavior.

Suspected mechanism

The symptom profile matches an OAuth refresh-token rotation race across concurrent sessions: N interactive processes share one keychain credential; if one process refreshes and rotates the refresh token, another process later presenting the stale (single-use) refresh token can invalidate the whole grant server-side → every session 401s → forced /login. This was previously reported and closed as #24317; #36482 (bridge should auto-refresh OAuth before expiry, closed) is also adjacent. If the fix for #24317 regressed, the ~12h cadence would be the refresh-token TTL surfacing.

Keychain evidence: the credential slot's mdat shows regular rewrites (last: 2026-07-02 18:19 UTC), consistent with refreshes happening — until one fails terminally.

Repro

1. Personal Max account, sign in via /login (claude.ai OAuth)
2. Start claude remote-control (or /rc in a session) and leave it running
3. Run several other interactive claude sessions concurrently on the same machine (~10 in my case)
4. Within ~12 hours the local process loses auth and requires /login; the RC session dies

Questions for the team

1. What is the intended sign-in/session lifetime for Remote Control on personal plans? If there is one, please document it on the Remote Control page.
2. If the refresh race is the cause, could refresh be deduplicated across processes (file-lock around refresh, or a single owner process refreshing for all)?

Related

• #24317 (closed) — OAuth refresh token race with concurrent sessions
• #36482 (closed) — remote control bridge should auto-refresh OAuth token before expiry
• #47000 (closed) — RC not auto-restored after mid-session re-login

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q3ofy8z84ncuDePUQrgCV4