Codex CLI requires repeated verification codes for every multi-account login #6506

Summary

Switching between two GitHub Codex CLI identities on the same workstation forces a fresh verification-code entry for every login, every day. When I cover an employee's queue in addition to my own, I have to enter four MFA codes daily (A→B→A→B) just to resume work.

Steps to Reproduce

1. Sign in to the Codex CLI with Account A and enter the emailed / 2FA verification code.
2. Sign out and back in with Account B; enter its code as well.
3. The next day, repeat the above—both logins require new codes even though the device is unchanged.

Expected Behavior

Once a device is trusted for an account, the CLI should remember the session for a reasonable period so subsequent logins (or account switches) only require credentials when the token actually expires or the user explicitly revokes trust.

Actual Behavior

Every login and every account switch triggers a brand-new verification challenge. Covering two accounts for a single workday means re-entering codes multiple times, even if each session ended only minutes earlier.

Impact

• Multi-account operators lose several minutes per context switch hunting down MFA codes.
• The friction discourages covering teammates or separating personal vs. shared queues.
• The user experience lags behind the "Remember this device" model that the GitHub web UI offers.

Environment

• GitHub Codex CLI public build (observed 2025-02-15)
• macOS Sonoma 14.4, iTerm2 Build 3.5.0beta10
• Both accounts secured via email+TOTP; no policy requiring daily re-auth exists.

Proposed Direction

Introduce durable per-account tokens (encrypted on disk) with a configurable TTL, plus a --forget option for sensitive environments. Alternatively, prompt once per day with a "Trust this device for 7 days" checkbox so that casual switches no longer invoke the full MFA loop.

Acceptance Criteria

• Switching between two previously trusted accounts does not require a new verification code unless the trust window has expired or the user explicitly flushes credentials.
• Administrators can opt out (e.g., via policy) but the default experience favors productivity.