OAuth access token revoked/invalidated twice in one week (4 of 7 days), disconnects both headless AND interactive sessions

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 12, 2026

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 by OAuth 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 -p job cannot self-heal this — /login requires 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗