Codex Lab multi-auth MVP

[shiny-code-bot]

Finish Line

Codex Lab can manage multiple authenticated accounts under CODEX_LAB_HOME, choose accounts cache-consciously for dogfood sessions, fall back when an account is exhausted, and optionally prime lazy weekly quota windows through the cheapest no-system-prompt lane.

Current Status

State: Paused behind #126. The first auth-profile and TUI /login slices landed, but they were developed while agents may have been consulting the wrong restored source tree for Every Code behavior.

Completed before the pause:

• Add auth profile login commands #116 added named auth profile metadata and CLI profile commands.
• Add runtime auth profile selection #117-Harden auth profile switching #124 added runtime selection, storage hardening, archive startup wiring, TUI profile picker/add flow, default identity display, and switch safety.

Current concern:

• The /login add account flow does not match the Every Code UX the user reported. In Every Code, selecting Add opens the auth webpage; Codex Lab currently behaves more like an improvised command prompt path.
• Therefore the whole auth/login/account-switching cluster needs an audit against ../code-prealign-new-skills/code-rs before more implementation builds on it.

Next recommended slice:

• Under Audit recent Codex Lab PRs against authoritative Every Code source #126, audit PRs Add auth profile login commands #116-Harden auth profile switching #124 against the authoritative Every Code auth/account/login sources.
• After the audit verdict, either keep and patch the current profile model, or rework it around the Every Code account flow.

Acceptance Criteria

• Users can add at least three named auth profiles without overwriting each other.
• Existing single-account auth continues to work without forced migration.
• Profile auth data stays in the Codex Lab home boundary and does not use repo-local state.
• A session can be explicitly pinned to a profile before auto-routing exists.
• Auto-sticky routing keeps a healthy existing session/profile for cache locality.
• Quota/auth failures mark an account unavailable and fall back to another eligible profile.
• Weekly reset priming is opt-in and uses a no-system-prompt minimal request lane.
• The implementation exposes enough profile state for a future settings command/panel/page without requiring that UI now.

Proposed Work Slices

1. Profile storage and CLI login primitives.
2. Explicit profile selection for runtime sessions.
3. Auto-sticky account routing and fallback on hard quota/auth signals.
4. Opt-in weekly reset priming with bounded retry/backoff.
5. App-server/TUI account session surfaces for /login, /auth, and future settings UI.

Design Notes

Preferred storage shape for MVP:

$CODEX_LAB_HOME/
  auth-profiles.json
  auth-profiles/
    main/
      auth.json
    backup/
      auth.json

Profile directories let Codex Lab reuse the existing AuthManager, refresh, logout, and keyring behavior with less risk than changing the single-account auth schema to hold a map of secrets.

Routing policy should prefer explicit profile selection, then a healthy sticky profile for the current thread/repo/model bucket, then the best available account by quota/reset metadata. It should not rotate mid-session unless the current profile is failing.

Relationships

• Parent: Codex Lab MVP dogfood plan #28 Codex Lab MVP dogfood plan.
• Related: Provider-agnostic worker decision spike #2 provider-agnostic worker decision spike.
• Follows: Make codex-lab easy to dogfood #114 dogfood launcher work, which made codex-lab easy to run from PATH.