Feature: Multi-account ChatGPT OAuth rotation and management

What feature would you like to see?

Today Codex only stores a single ChatGPT OAuth credential. I’d like multi‑account support with automatic rotation so requests can fail over when one account hits rate limits or auth failures.

Concretely:

Persist multiple ChatGPT OAuth accounts in the local auth store.
Add an automatic rotation strategy for OpenAI requests that:
- skips accounts in cooldown/exhausted states,
- refreshes once on 401/403 and retries the same account,
- honors Retry‑After on 429 before trying the next account,
- retries network/timeout/build errors on the same account before rotating.
Provide CLI workflows to list/remove accounts (e.g., codex login accounts, codex logout --account, codex logout --all-accounts).
Surface a compact rotation/health summary in the TUI status view.
Allow tuning via config (cooldowns, network retries, max attempts).

Additional information

Motivation: power users hit rate limits and auth refresh issues that interrupt long sessions. Rotation + account management would improve reliability without forcing API key usage. I have a draft implementation on a feature branch (oauth-marathon) and can iterate based on maintainer feedback.

Thanks for the suggestion.

This feature request largely overlaps #3366 which already has some upvotes. I'm going to close this one to consolidate. Feel free to add ideas to the other one if you think that it doesn't quite capture what you have in mind.

Thanks for the response. I don’t think this is a duplicate of #3366: that issue focuses on re‑auth/entering a new credential after plan‑limit termination within the same session, whereas this proposal is automatic multi‑account rotation + storage (rate‑limit/auth failure handling, per‑account cooldowns, CLI account management, TUI summary, config controls). If you prefer consolidation, I can move the full details into #3366, but I believe the scope is materially different. Would you consider reopening so it can be tracked separately?

For visibility: the implementation in PR #9651 is ready to go (tests passing). I’m disappointed it can’t be included under the current feature freeze, but I understand the policy. If/when this enhancement is green‑lit, the PR is available as a starting point, and I can fold any additional feedback into it.

I agree 100% of this featue.
I need to add my openai account and failover to api when tokens are consumed or rate limited.

fix(auth): prevent Codex multi-account refresh_token family revocation

fix(sse): stop Codex multi-account family-revocation cascade on quota…

fix(api): guard rotating providers in manual token-refresh route (Cod…

It's not very clear if this is even allowed by OpenAI. Isn't this technically circumventing limits/restrictions?

Prior art for the rotation spec here: I built aistat, which ships much of this pattern (multi-account OAuth store, Retry-After-aware HTTP, a per-account usage cache, and auto-pick by remaining 5h headroom on switch) — Claude side today, Codex side on the same machinery:

$ aistat switch codex
switched to work@example.com (uuid 5e9c1a47-3b8f-42d1-a6e0-7c2f9b4d8e13); was personal@example.com

The reporting side shows where each account sits, which is what auto-pick reads:

$ aistat -h
Claude usage
- personal@example.com (active) [Max 5x]
  - 5-hour: 92.0% (resets in 4h 53m)
  - 7-day: 71.0% (resets in 2d 5h)
- work@example.com [Max 20x]
  - 5-hour: 4.0% (resets in 4h 12m)
  - 7-day: 12.0% (resets in 5d 9h)

Codex usage
- personal@example.com (active) [Pro]
  - 5-hour: 85.0% (resets in 1h 22m)
  - 7-day: 41.0% (resets in 4d 18h)
- work@example.com [Plus]
  - 5-hour: 4.0% (resets in 4h 12m)
  - 7-day: 9.0% (resets in 5d 11h)

Two notes that might shorten PR #9651 review:

Split "fetch usage" from "refresh": the switch path is no-refresh, no-store-mutation, so it can't publish a stale post-refresh token. Expired-access-token accounts are excluded from auto-pick with a per-account warn rather than refreshed silently.
90s cache TTL on the per-account read is small enough that a rate-limited account doesn't get silently excluded from rotation because its data is stale.

https://github.com/drogers0/aistat — rotation in internal/providers/claude/reconcile.go, Retry-After in internal/httpx/. Credential-store-rather-than-fetch-rotation design, so applicable as a tradeoffs data point rather than copy-paste.

My personal Codex symphony implementation + multi-account management + usage load balance

https://github.com/hack-ink/decodex
https://x.com/hackink/status/2054951370177057224
https://x.com/hackink/status/2056903691211530666

fix(providers/test): probe real Codex /responses endpoint instead of …