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

What feature would you like to see?

Today Codex CLI assumes a single account, with state stored under ~/.codex/. Users who need to juggle multiple ChatGPT/API accounts (for example, those with multiple accounts, multiple API keys, or who work for different clients) must manually swap CODEX_HOME, copy auth files, or repeatedly log in and out. This is tedious, time-consuming, and not user-friendly.

I would like to see first-class multi-account support:

A global --auth-profile <name> flag that routes all config, auth, and session state into ~/.codex/profiles/<name>/.
A default profile can be set via CODEX_PROFILE env var, so bare codex … still works as expected.
Profile names are normalized/validated (safe slugs, no .., etc).
Interactive hints (login, exec, resume) include the active profile name so it’s clear which account you’re in.
Backwards compatibility: if no flag/env is set, Codex continues to use ~/.codex exactly as before.

This matches common CLI conventions (like aws --profile) and makes it trivial to keep personal/work accounts isolated without shell hacks.

Are you interested in implementing this feature?

Yes. I have already implemented a working version in a fork:

Added --auth-profile parsing and defaulting logic.
Automatically sets CODEX_HOME/CODEX_ACTIVE_AUTH_PROFILE internally.
Updated login/logout, exec, and resume flows to respect the active profile.
Added tests to confirm per-profile isolation of auth.json, config.toml, and sessions.
Updated interactive exit hints to show the profile.
Updated getting-started docs to explain both the legacy single-account flow and the new multi-profile workflow.

Happy to open a PR once the team acknowledges this direction.

Additional information

No response

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

@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

@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

@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

@Ducksss

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.

Adding a concrete multi-host quota-rotation use case.

Environment:

Codex Windows app 26.810.7004.0
bundled codex-cli 0.148.0-alpha.9
Windows 10.0.19045
three headless/server CLI hosts plus the Desktop app

We rotate between two subscription accounts when a weekly quota is exhausted. The current workaround is not just an authentication switch: changing CODEX_HOME or logging out/in also changes the effective config, session namespace, skill/plugin discovery, and local runtime state. In practice, this creates configuration drift between hosts and makes it hard to tell whether a failure is caused by the selected account or by a different runtime/config generation.

A first-class profile feature would be much safer if it separated these dimensions:

credential/entitlement profile (account and cached tokens);
declarative base config shared by several credential profiles;
optional per-profile overrides;
session/runtime generation, with an explicit indication of which auth profile and config generation a session is pinned to.

Desired UX:

codex auth profile list/status/switch without copying auth.json;
a new session can select another auth profile without invalidating a healthy session pinned to the original profile;
switching auth does not silently replace skills/plugins/MCP configuration;
diagnostics show authProfile, configGeneration, and whether a new lifecycle is required;
headless/device-code login works per profile.

The operational impact is repeated authentication/config diagnosis and duplicated turns. The user reports roughly twice the usual token/time consumption during affected rotations; I do not have a clean token baseline, so that number should be treated as user-reported impact rather than measured telemetry.

No auth.json, token, account email, or private config is attached.

I put together a server-side proposal for the variant where accounts share the same local sessions and memories instead of using separate CODEX_HOME directories: patrickallensimpson#1

The implementation keeps one home for threads, rollouts, config, skills, and memories, but namespaces credentials per account session in the existing auth backend. The shared account-sessions.json contains metadata only—no access or refresh tokens. It implements the merged v2 add/list/switch/logout protocol, blocks account changes during active turns, and includes a two-account end-to-end isolation test.

GitHub denied this account permission to create a PR directly against openai/codex, so the fork PR is the reviewable branch of record. It is based on current main and also cross-references the existing lifecycle draft in #25383.

changing CODEX_HOME or logging out/in also changes the effective config, session namespace, skill/plugin discovery

Had the same drift problem. What I do now is give each account its own CODEX_HOME but symlink config.toml, AGENTS.md, skills/ and plugins back to the main ~/.codex, so it's mainly auth.json and the state/log dbs that are actually per account. Config and skills stay the same whichever account is active. Sessions can go either way, keep sessions/ and history.jsonl per home, or symlink them too if you want one shared resume list.

Put this into a small tool if it helps anyone: https://github.com/larcane97/clausona (mine, it also handles claude code). It's a stopgap though, +1 for native --auth-profile.

Until something like --auth-profile lands, a workaround that works today is to give every account its own CODEX_HOME. I wrapped that in a small tool, multi-codex (https://github.com/jakoes-wu/multi-codex): multi-codex add work creates ~/.cx/work and a codex-work launcher, multi-codex login work logs in, and codex-work / codex-personal then run side by side in different terminals. It can also give each account its own proxy, pick the account per project directory (multi-codex bind work once, then codex-auto), and turn an existing ~/.codex into an account without logging in again. It's a third-party wrapper around CODEX_HOME, so it doesn't change how Codex itself handles auth.

Navigation Menu

Repository navigation

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

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

Activity

bashar94 commented on Sep 29, 2025

RW21 commented on Oct 28, 2025

rirze commented on Oct 29, 2025

bashar94 commented on Oct 30, 2025

cdrum commented on Mar 6, 2026

etraut-openai commented on Mar 6, 2026

burakdede commented on Mar 26, 2026

prashantchoudhary commented on Mar 30, 2026

slatkisasa commented on Apr 6, 2026

venkatd commented on May 8, 2026

etraut-openai commented on May 8, 2026

cdrum commented on May 8, 2026

deksden commented on May 27, 2026

Ducksss commented on Jun 3, 2026

drogers0 commented on Jun 3, 2026

Ducksss commented on Jun 11, 2026

burakdede commented on Jun 15, 2026

jyongchul commented on Aug 17, 2026

patrickallensimpson commented on Sep 2, 2026

larcane97 commented on Sep 29, 2026

jakoes-wu commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions