Rotation gateway triggers mass OAuth token invalidation across accounts

[bre01]

Description

Using codex-multi-auth's rotation gateway (localhost proxy) triggers OpenAI's anti-abuse detection, causing OAuth tokens to be invalidated across multiple accounts. The gateway's account-switching pattern — rapidly rotating between different account tokens from the same IP/device — appears to be detected by OpenAI as suspicious activity.

Environment

• macOS Sequoia
• codex-multi-auth (latest)
• 4 accounts configured (3 Gmail, 1 Outlook)
• Rotation gateway enabled

Observed Behavior

After using Codex CLI through the rotation gateway for a period, accounts progressively get their tokens invalidated:

$ codex-multi-auth check

  ✓ Account 1 (...@gmail.com) | signed in and working
      (live check failed: Encountered invalidated oauth token for user, failing request)
  ✓ Account 2 (...@gmail.com) | signed in and working
      (live check failed: {"detail":"The 'gpt-5-codex' model is not supported ..."})
  ✓ Account 3 (...@gmail.com) | live session OK (5h 26% | 7d 10%)
  ✓ Account 4 (...@outlook.com) | signed in and working
      (live check failed: Your authentication token has been invalidated.)

Result: 4 working | 0 need re-login | 3 warnings

Accounts that were working fine before gateway usage get invalidated one by one. Re-logging in temporarily fixes it, but the token gets invalidated again once the gateway routes a request through that account.

Additional observations

• Account 4 (Outlook/Microsoft SSO): Especially affected — token gets invalidated immediately after every re-login on the first request. This is reproducible and persistent. The account works fine on ChatGPT web.
• Account 1 (Gmail): Was working, then invalidated after gateway usage.
• Account 2: Separate issue — account plan doesn't support gpt-5-codex model.
• Using codex-multi-auth switch <index> directly (without the gateway) does not seem to cause this issue.

Possible Cause

The rotation gateway rapidly switches between different OAuth tokens from the same IP/device. OpenAI's backend likely detects this pattern — multiple distinct user sessions originating from the same source in quick succession — and invalidates the tokens as a security measure.

Suggestions

1. Increase minimum rotation interval — avoid switching accounts too frequently; add configurable cooldown between rotations
2. Session affinity — keep using the same account for a longer period before rotating (e.g., stick with one account until it's actually rate-limited)
3. Investigate Microsoft/Outlook SSO — Account 4's immediate invalidation on every single request may indicate a separate issue with how Microsoft-linked OAuth tokens are handled through the proxy
4. Document the risk — warn users that aggressive rotation may trigger OpenAI's anti-abuse detection

Workaround

Disable the rotation gateway and use switch to manually select accounts:

codex-multi-auth rotation disable
codex-multi-auth switch 1

[coderabbitai]

🔗 Related PRs

#45 - fix: enforce automatic quota-based account rotation [merged]
#136 - feat: auto-rotate on disabled/expired workspace errors [merged]
#442 - feat: add rotation reset-rate-limits to clear stale pool timers [merged]
#463 - Fix runtime skip for deactivated accounts [merged]
#480 - Fix runtime rotation pool diagnostics [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ndycode]

Hi @bre01 — this is fixed and shipped to the beta dist-tag in v2.1.13-beta.2.

Try it:

npm i -g codex-multi-auth@beta

Root cause: your diagnosis was exactly right. The rotation gateway, on a 401, was rotating to the next account and presenting its OAuth token from the same IP in rapid succession. OpenAI's anti-abuse detection reads that burst of distinct tokens from one source as suspicious and invalidates them in sequence — so the rotation itself was causing the cascade.

What changed (PRs #496 + #497):

• Detect token invalidation specifically. The 401 handler now reads the response body and matches explicit invalidation phrases (e.g. invalidated oauth token, authentication token has been invalidated), distinguishing them from generic expired-token 401s.
• Stop the cascade. On a detected invalidation, the 401 is returned straight to the client instead of rotating — so one bad account can't drag the rest down. Generic 401s (expired token, wrong creds) still rotate as before.
• Long, monotonic cooldown. Invalidated accounts get a 5-minute cooldown (vs the generic 30s), and it only ever extends — a racing generic 401 can't shorten it. Configurable via CODEX_AUTH_TOKEN_INVALIDATION_COOLDOWN_MS.
• Session affinity cleared so the next request lands on a healthy account.
• minRotationIntervalMs sticky window (default 60s, CODEX_AUTH_MIN_ROTATION_INTERVAL_MS) — keeps serving the last-used account within the window so a different token isn't presented from the same IP back-to-back, directly addressing your suggestions feat: codex multi-auth runtime + TUI + docs overhaul #1 and feat: clean codex multi-auth runtime + tui + docs overhaul #2.

A couple of notes tied to your report:

• Account 4 (Outlook/Microsoft SSO) — being invalidated immediately on every re-login is consistent with this same cascade behavior. It should be much improved on the beta. If it still gets invalidated on the very first request after a fresh login (with rotation idle), that would point to a separate SSO-token-handling issue — please let us know and we'll dig in.
• Account 2 (gpt-5-codex not supported) is a plan/model issue, unrelated to this fix.
• Stable v2.1.13 is still gated on a separate 503 root cause ([bug] 503 Service Unavailable #486); this lands on beta now so you don't have to wait.

If you'd give the beta a run with your 4-account setup and confirm the invalidation cascade is gone, that'd be a big help. Thanks for the detailed report and the spot-on root-cause analysis. 🙏