First-class multi-account auth via '--auth-profile'

PR #4457

There is an issue of unintended messing up of MCP auths between profiles, but overall I think this feature is needed. Especially in the case of working between multiple openAI organization keys.

Definitely need this as I have a personal account and corporate account. At this point, I might just maintain two installations of codex.

Since they are not merging this feature and we all need it, I have a bash script for you to do the same thing. It is not as smooth as Codex's built-in functionality but you can log in and switch accounts easily using this: https://github.com/bashar94/codex-cli-account-switcher

surprised OpenAI seems uninterested in this.. odd.

@cdrum, we generally prioritize feature requests based on upvotes. It's not that we're uninterested. Just focused on features that are more highly requested.

Native --auth-profile is the right long-term answer.

For anyone who needs this today without patching the binary: aisw takes a similar approach externally. Manages isolated CODEX_HOME directories per profile:

aisw add codex personal     # sets CODEX_HOME to profile dir, runs codex login
aisw add codex work
aisw use codex work         # shell hook exports CODEX_HOME

Each profile gets its own auth.json and config.toml. Forces cli_auth_credentials_store = "file" so credentials are portable rather than stuck in OS keyring.

The cross-tool part is the main differentiator from Codex-specific solutions: same commands also work for Claude Code (via CLAUDE_CONFIG_DIR) and Gemini CLI. One tool instead of separate per-tool hacks.

Docs: https://burakdede.github.io/aisw/

A jenv/pyenv/ssh-config like support will be the best. Where we can configure folder level accounts that can be used for all the subfodlers. And Codex automatically switches account based on this rule, just like jenv switches Java versions.

Sharing in case this helps someone else:

I ended up putting together a small Go CLI to manage multiple Codex accounts more easily (codexmux). Mostly vibe-coded, but it’s lightweight and fast:
https://github.com/slatkisasa/codexmux

You can also install it via Homebrew:
brew install slatkisasa/tap/codexmux

I assume most people here have multiple accounts as a workaround to the codex limits. They run out so they have to buy a 2nd account.

If there was a way to pay $200 more to get double limits, etc, that would solve the problem at the root cause.

@venkatd, we offer the ability to purchase additional credits if you need more usage on top of your subscription.

I assume most people here have multiple accounts as a workaround to the codex limits. They run out so they have to buy a 2nd account. If there was a way to pay $200 more to get double limits, etc, that would solve the problem at the root cause.

I have a work account, and a personal account.

@etraut-openai

Do simple trick: allow profile customisation of auth file in profiles v2, so people can have different auth files via profile if needed.

If they need separate sessions between personal/work accounts, they can use different codex homes. Cli already fully support it, but you need to support CODEX_HOME in codex.app!

This all can be done via simlinks tricks and cli utils / wrappers / automation, but official support can make things simplier.

Sharing a candidate implementation I put together for this request:

Branch: https://github.com/Ducksss/codex/tree/PinZheng/auth-profiles-review
Compare: https://github.com/openai/codex/compare/main...Ducksss:PinZheng/auth-profiles-review?expand=1

It adds first-class auth profiles via --auth-profile NAME and CODEX_PROFILE=NAME, resolving each profile to an isolated Codex home under $CODEX_HOME/profiles/NAME. The branch wires the selected profile through CLI/TUI/app-server/daemon/MCP/plugin/marketplace/cloud-task flows, scopes MCP OAuth state by profile, preserves existing default-profile MCP keyring credentials, and documents the difference between config profiles and auth profiles.

I could not open an upstream PR from this account because GitHub rejected PR creation against openai/codex, but the branch is pushed and ready for maintainers to inspect or pull.

Validation run:

• cargo fmt --all
• git diff --check
• cargo test -p codex-utils-home-dir
• cargo test -p codex-rmcp-client oauth::tests
• cargo test -p codex-cli --bin codex auth_profile
• cargo test -p codex-core build_exec_request_preserves_windows_workspace_roots
• broad affected-crate cargo check across home-dir, cli, core, rmcp, mcp, app-server, daemon, chatgpt, cloud-tasks, tui, and exec crates

Nice to see @Ducksss's candidate --auth-profile branch — native profiles are the right fix here. For anyone who needs something in the meantime (and across providers), I built aistat: it switches both Claude and Codex from one binary, plus live usage reporting. The existing external switchers like aisw cover storage and manual switching cleanly; aistat's different axis is the reporting, which is what I needed for headroom-based routing. Codex switching rewrites the live ~/.codex/auth.json in place:

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

It also reports usage per account (the input to headroom-based auto-pick):

$ 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)

Without --to, auto-pick goes by 5h headroom — the rate-limit-aware behavior proposed in #9648 / PR #9651, just applied at the switch boundary instead of per-request. It reports Copilot too, though there's no switch there since GitHub's auth model differs.

https://github.com/drogers0/aistat

Quick follow-up: I refreshed the candidate branch against current main (273a4aa) and force-pushed the updated commit: https://github.com/Ducksss/codex/tree/PinZheng/auth-profiles-review

Validation on the refreshed branch: cargo test -p codex-utils-home-dir; cargo test -p codex-rmcp-client oauth::tests; cargo test -p codex-cli --bin codex auth_profile; cargo test -p codex-core build_exec_request_preserves_windows_workspace_roots; and a multi-package cargo check across the touched crates. Since fork PRs are restricted to collaborators, I can split this into smaller reviewable branches if maintainers prefer.

I've been following account/profile management requests not only in Codex, but also in Claude Code and Gemini CLI.
At this point, I think this is becoming a coding-agent-agnostic workflow problem rather than a tool-specific feature request.

A lot of developers now juggle:

• work accounts
• personal accounts
• client-specific accounts
• different organizations/subscriptions
• API-key and OAuth identities side-by-side

The current workaround across most tools is some combination of logout/login cycles, environment variables, credential file swapping, shell aliases, or separate terminals.

Because I kept running into this across multiple coding agents, I've been maintaining AI Switcher (aisw):

https://github.com/burakdede/aisw

Not suggesting it as a replacement for first-party support here. If anything, it has convinced me that the demand is real because exactly the same requests keep appearing across Codex, Claude Code, and Gemini CLI issue trackers.

One thing I've learned while building it is that users usually need more than just account switching:

• named profiles
• visible active identity
• isolation between work/personal/client contexts
• project/context bindings
• cross-tool consistency

Recently I added contexts, which are essentially bundles of profiles that can be switched together:

aisw context create acme \
  --claude acme-claude \
  --codex acme-codex \
  --gemini acme-gemini

aisw context use acme

That experience made me think the long-term solution might be broader than just auth switch and closer to first-class identity/context management.

Would love to see native support land because I think this is becoming a common workflow for power users regardless of which coding agent they use.