How I Manage Multiple Claude and Codex Accounts: My Local Switching Setup

If you have multiple Claude Code or Codex accounts, the hard part is not logging in. The hard part is answering a few basic questions: which account am I using right now? How much usage is left? After switching accounts, did this terminal actually pick up the new identity?

I no longer log out and log in every time. I keep “account data” and “working environment” separate. For Claude Code, I use claude-swap. For Codex, I use codex-auth. Both sides can rotate accounts in the background, but I still keep task checkpoints and client restarts as explicit boundaries.

Core Logic: Separate Account State from the Working Environment

Multi-account management starts by splitting the problem into layers. Before thinking about how to log into the second account, I look at three things.

The first is each account’s own auth state. The second is the pointer that says which account is currently active. The third is the client process that is already running. The first two are config and auth problems. They may involve tokens, refresh tokens, credential stores, or tool-owned config files, so I do not copy them by hand or put them into .bashrc, a project repo, or synced dotfiles. The third one is where daily mistakes usually happen: after switching accounts, an already-open Claude Code session, Codex CLI, VS Code extension, or desktop app may not immediately read the new state.

So my setup is simple: let dedicated tools store account data, and let the tools run the switching rules. I do not switch accounts in the middle of a long task. When I really need to change accounts, I leave a checkpoint first, then confirm the state and restart the client.

Claude Code: I Use cswap to Move Switching into the Background

For Claude Code, I use the third-party tool claude-swap. After installing it, I usually run cswap; the full command name claude-swap works too. Account data lives under ~/.local/share/claude-swap/.

On my machine, I currently rotate between two Claude accounts. sequence.json records the account order and the current active account. Each account has its own Claude config snapshot and encrypted credential, so I do not need to edit ~/.claude.json by hand.

These are the commands I use most often:

cswap --add-account
cswap --list
cswap --status
cswap --switch
cswap --switch-to 2
cswap --tui

When adding an account for the first time, do not paste a token into cswap. Log into that account through Claude Code itself first, then run:

cswap --add-account

That lets cswap capture the current login state into its managed account list. To add a second account, log out from Claude Code or use /login to switch to another account, then run cswap --add-account again.

I like this because it separates “adding an account” from “switching accounts.” Adding an account still needs a manual login confirmation. Switching accounts becomes a daily command, without repeating browser authorization every time.

I also run a systemd service locally so it can keep watching in the background:

[Service]
ExecStart=/root/.local/bin/cswap auto
Restart=always
RestartSec=15

This service is not responsible for logging in. It only rotates accounts when usage gets close to the threshold. Claude Code was the first side where I felt comfortable enabling automatic switching, because claude-swap already wraps the account list, order, status checks, and auto mode into one tool.

I still keep one habit: before starting a long task, I check the state.

cswap --status
cswap --list

That is more stable than discovering halfway through a coding task that the current account is almost full. If I need to write code continuously, run tests, or fix bugs, I want to know which account I am starting from.

Codex: I Use codex-auth So Accounts Can Rotate Automatically Too

For Codex, I use another third-party tool: codex-auth. Its role is direct: manage multiple Codex accounts, switch the current active account, and rotate automatically by usage threshold after auto-switch is enabled.

On my machine, Codex’s own settings still live in ~/.codex/config.toml, including the default model, reasoning effort, and trusted projects. Multi-account data is handled under ~/.codex/accounts/:

~/.codex/auth.json
~/.codex/accounts/registry.json
~/.codex/accounts/*.auth.json

auth.json is the login state Codex currently reads. accounts/*.auth.json stores each account’s auth snapshot. registry.json records the active account, account list, usage data, and auto-switch settings.

On this machine, I currently have three Codex accounts. codex-auth auto-switch is enabled, with rotation triggered when the 5-hour remaining usage drops below 10% or weekly remaining usage drops below 5%. In other words, Codex now has a background process handling account switching just like Claude does. The difference is that I still treat “restart the client after switching” as a hard usage boundary.

I keep that boundary because Codex has multiple client types. The CLI, App, and VS Code extension may all read the same login state. The codex-auth documentation also notes that after switching accounts, Codex CLI or Codex App should be restarted so the new account takes effect.

When connecting automatic rotation for the first time, I enable auto-switch first. In daily use, I mostly check status and list, and only manually choose an account when needed.

codex-auth config auto enable
codex-auth status
codex-auth list
codex-auth switch
codex-auth switch work

After auto-switch is enabled, the background watcher handles active account rotation. When a switch happens, I still close and reopen the Codex client I am using so the new login state is applied cleanly.

To add an account, I can use:

codex-auth login
codex-auth login --device-auth

If the registry and actual auth files fall out of sync, codex-auth also provides a rebuild command:

codex-auth import --purge

I do not use repair commands like import --purge as part of my daily workflow. The daily basics are simpler: know whether auto-switch is running, know which account is active, and restart the client after switching.

codex-auth also supports usage API mode and local-only usage refresh. API mode uses the access token to check usage, so the data is more current. Local-only is more conservative, but can lag if local rollout files are incomplete. On this machine, I keep usage/account API enabled together with auto-switch, so rotation decisions are based on fresher usage data.

My Daily Flow: Check State Before Starting New Work

Multi-account management is mostly about the decision before work starts: do not begin a long task on an almost-full account, and do not discover halfway through that you picked the wrong identity.

My regular check looks like this:

cswap --status
cswap --list
codex-auth status
codex-auth list

If I am about to start a long Claude Code task, I check the current cswap account state first. Since Claude has an auto service, I am more comfortable letting it rotate in the background when it approaches the threshold.

If I am about to use Codex, I check codex-auth status for auto-switch and service state, then use codex-auth list to confirm the active account. Auto-switch handles rotation near the threshold. If I switch accounts manually, I still restart the Codex client afterward so the login state is clean.

I do not recommend switching accounts in the middle of a long-running task with a lot of context. In that situation, I would ask the agent to leave a progress summary, commit, or issue comment first, then continue in a new session. Account switching should happen at task boundaries, not in the middle of the thought process.

This is also why I manage Claude and Codex separately. Claude is handled by cswap auto; Codex is handled by codex-auth auto-switch. Both can rotate automatically, but I still keep task boundaries and client restarts as the last guardrail.

Do Not Turn Multiple Accounts into a Security Debt

The easiest way to make multi-account management dangerous is to build convenience on top of scattered tokens.

I avoid a few things:

• Do not put tokens, access tokens, or refresh tokens into shell rc files.
• Do not commit auth.json, .auth.json, or credential backups into a git repo.
• Do not sync account files to a cloud folder with unclear permissions.
• Do not paste real tokens into articles, notes, or issue comments.
• Do not treat “copy the entire home directory” as a backup strategy.

The more stable approach is to let the tools manage credentials, while I only record the workflow and paths. For example, I can remember that Claude uses cswap --status and cswap --switch, and Codex uses codex-auth status, codex-auth list, and codex-auth switch. I do not need to write any credential content into notes.

Minimum Viable Setup: Stabilize Manual Switching First, Then Enable Automation

If you also want to manage multiple Claude Code or Codex accounts, I would start with the smallest version: make manual switching stable first, then turn on automatic rotation.

For Claude Code, start here:

cswap --add-account
cswap --list
cswap --switch
cswap --status

After confirming both accounts can switch manually, consider:

cswap auto

Or run it as a systemd service like I do, so it stays in the background.

For Codex, start here:

codex-auth login
codex-auth list
codex-auth switch
codex-auth config auto enable
codex-auth status

Make sure each account can be saved and switched first, then enable usage API and auto-switch. My own setup is that Codex also enters automatic rotation, but I still keep switching flow, client restarts, and task checkpoints in place so recovery is easier when something goes wrong.

The point of multi-account management is not switching accounts as fast as possible. It is knowing three things before each task starts: which account is active, whether it is suitable for the next task, and how the work should stop safely when usage runs out. If those questions have clear answers, multiple accounts become a resource instead of a new source of confusion.