OAuth access token revoked/invalidated twice in one week (4 of 7 days), disconnects both headless AND interactive sessions
Running a long-lived interactive claude -c session on macOS, plus a separate scheduled headless claude -p job (launchd, no TTY) on the same account. Over the past week, the account's OAuth session has been invalidated twice, each time lasting roughly 2 days before a manual /login cleared it.
Timeline (all times from --debug-file logs, exact text below):
- 2026-09-09, 11:00 UTC — first occurrence.
API error (attempt 1/11): 401 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth access token has been revoked."}}, followed byOAuth refresh token is no longer valid; run /login to re-authenticate. Recurred identically on 2026-09-10. Cleared by an interactive/login. - 2026-09-11, 11:00 UTC — second occurrence, identical error signature (
OAuth access token has been revoked.→OAuth refresh token is no longer valid). Recurred identically on 2026-09-12. Also cleared by/login— and this time the interactive session itself was disconnected too, not just the headless job, requiring the user to re-authenticate mid-session.
Total: 4 of the last 7 calendar days showed this signature.
Impact:
- A headless
claude -pjob cannot self-heal this —/loginrequires an interactive browser-based flow, so any scheduled/unattended automation using the same account session silently fails for the full duration until someone notices and manually re-authenticates. - The second incident also killed the live interactive session, which is a more disruptive failure mode than the first.
Ruled out:
- Not a clock-skew issue (the errors are explicit server-side
authentication_error: OAuth access token has been revoked, not a token-expiry-style failure). - Not obviously an account compromise — checked directly, no security/account-alert emails from Anthropic beyond normal login-related mail in that window.
- Distinct from an earlier, narrower issue in this same environment where only the Gmail MCP connector's OAuth expired (that one didn't affect the core account session or other tool calls) — this is a full account-session revocation, broader blast radius.
Question: is this expected token-lifecycle behavior (e.g., a rotation policy that's more aggressive than expected) or a bug in refresh-token handling? Twice in a week, with one incident also dropping a live interactive session, seems too frequent to be routine.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗