Two Accounts in Codex CLI: How to Separate Work and Personal Logins

When using Codex CLI for personal projects alongside work tasks, you need a reliable way to isolate environments and accounts. The --profile flag is not designed for account switching: according to the basic configuration documentation, profiles only overlay $CODEX_HOME/<name>.config.toml on top of your main configuration (adjusting parameters such as model selection, sandbox level, or MCP servers), but they do not change the active authentication credentials.

To use different accounts, you must define independent directories via the CODEX_HOME environment variable and complete the login procedure (codex login) separately for each directory.

Risks of Manually Copying Session Files

An article on Habr illustrates a user practice: the author automated account switching by swapping authorization files using a bash script and queried remaining quota through an undocumented web interface endpoint. The author explicitly highlighted the primary drawback of this setup—its dependency on an internal, private backend API that can change at any moment.

Direct manipulation of session files also risks breaking token lifecycles: when a refresh token rotates in one location, a copied duplicate in another directory may be invalidated. A related authorization error following file copying is documented in issue #15410. While a single report does not prove that every copied session file will inevitably fail, copying files manually creates unnecessary operational risks. Do not read or copy auth.json, and do not call private backend APIs. The standard approach is to let the CLI manage sessions independently across distinct directories.

Credential Storage and Policy Constraints

Before configuring separate directories, it is important to understand where and how authentication data is stored. According to the authentication documentation, the cli_auth_credentials_store configuration setting supports the following modes:

• file — Credentials are saved in a local auth.json file inside the CODEX_HOME directory.
• keyring — Credentials are stored in the system keyring (Keychain on macOS, Secret Service on Linux).
• auto — The CLI attempts to use the system keyring and falls back to file storage if the keyring is unavailable.
• ephemeral — The session is retained only in the memory of the running process.

When planning environment separation, keep these caveats and constraints in mind:

• Separate CODEX_HOME directories do not guarantee full isolation if centralized organizational policies apply to the machine (Managed configuration / requirements.toml). If an administrator mandates a specific authentication method or storage type, those policies override local configuration.
• In the CLI source code, the keyring service distinguishes directories by hashing the CODEX_HOME path (see storage.rs). Consequently, assuming that different directories automatically share a single keyring entry is incorrect. However, this still does not guarantee full isolation across all environments: actual storage behavior depends on platform and operating system settings, so you should verify it on your target machine.
• You cannot assume tokens reside exclusively within a directory until the active storage mode is verified.

Step-by-Step Setup for Two Environments

We will set up two explicit directories: $HOME/.codex-personal and $HOME/.codex-work. Your existing ~/.codex directory is left unmodified and intact.

Step 1. Prepare Directories

Create dedicated directories with access permissions restricted to your user account:

mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"

If your organizational policies allow file-based storage, you can explicitly set cli_auth_credentials_store = "file" in config.toml inside each directory before logging in:

cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF

cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF

If mandatory corporate authentication requirements are enforced on your device, use the administrator-approved credential store mode instead.

Step 2. Independent Authentication

Browser-based authentication binds to the session currently active on chatgpt.com. The browser profile menu shows only the current web session and does not prove which credentials were saved to a specific CODEX_HOME. You must verify the intended account and Workspace during each browser login:

• Before logging into the personal environment, switch to your personal account in the browser.
• Before logging into the work environment, select the relevant corporate account or Workspace in the browser.

Run the login procedure for each environment separately:

env CODEX_HOME="$HOME/.codex-personal" codex login

env CODEX_HOME="$HOME/.codex-work" codex login

In each case, confirm the authorization prompt in the browser window that opens. If you have any doubts, run the standard env CODEX_HOME="..." codex logout and repeat the login for that specific directory while checking the active browser account (do not inspect or manually copy token files).

Step 3. Verifying Login Status

Check the authorization status in both directories:

env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status

The codex login status command displays the authentication method, but it does not prove the identity of a specific user account. Keep in mind the difference in billing sources: ChatGPT login relies on the subscription or included limits of the associated plan and Workspace, whereas API-key login is billed separately via OpenAI Platform.

This workflow is intended for ChatGPT logins across two distinct accounts. If status displays an API key, the target scenario has not been met—revisit the login step for that directory.

Step 4. Running a Test Task

To verify the work environment, run a real task in a test work repository while restricting permissions with the read-only sandbox:

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Read README.md and describe the project's purpose. Do not modify files"

A short read-only test confirms that the session and sandbox are functional. Reviewing the Usage section in your account or Workspace after running a test offers only an indirect signal with possible reporting delays, not verified proof of identity. If any uncertainty remains, execute env CODEX_HOME="$HOME/.codex-work" codex logout and repeat the login procedure while carefully checking the active account in your browser.

Daily Usage

For daily development, you can execute commands directly by prefixing CODEX_HOME, or define helper functions in your shell configuration file (~/.zshrc or ~/.bashrc):

codex-personal() {
  env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}

codex-work() {
  env CODEX_HOME="$HOME/.codex-work" codex "$@"
}

Examples of invoking these helpers with arguments forwarded through "$@":

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "Read README.md and describe the project's purpose. Do not modify files"

codex-personal