How to Run Multiple Claude Code Accounts

Updated November 3, 2026 · first published August 8, 2026 · by the AQ team

Claude Code keeps one login per configuration directory, so the way to run multiple accounts is to give each account its own directory. Set the CLAUDE_CONFIG_DIR environment variable to a different folder per account and you can stay signed in to a work account and a personal account at the same time, in parallel terminals. On a shared machine, give each person their own OS user. For a team, use one account per person: Anthropic's consumer terms do not allow sharing a login. This guide was checked against Anthropic's Claude Code documentation on November 3, 2026.

Multiple accounts is a different problem from multiple sessions. One account can already run many Claude Code sessions at once on one machine; for that, see running multiple Claude Code sessions in parallel. You need multiple accounts when the logins themselves must differ: separate billing (work and personal), separate organizations, or separate people.

Where Claude Code keeps your login

Claude Code signs in through a browser OAuth flow the first time you run it. Per the authentication docs, the credential is stored like this:

• macOS: in the macOS Keychain. If the Keychain rejects the write (for example when it is locked in an SSH session), Claude Code falls back to ~/.claude/.credentials.json with file mode 0600.
• Linux: in ~/.claude/.credentials.json with file mode 0600.
• Windows: in %USERPROFILE%.claude.credentials.json, protected by your user profile's access controls.

When CLAUDE_CONFIG_DIR is set, the docs say Claude Code keeps .credentials.json under that directory instead, and on macOS it keys the Keychain entry to that directory too, so a session with a different CLAUDE_CONFIG_DIR reads a different entry. Settings, session history, and plugins live under the same directory, and the .claude.json state file (account details, personal MCP servers) moves with it. An "account" in Claude Code is therefore a config directory plus the login inside it.

Method 1: one config directory per account

The authentication docs give this as the way to stay signed in to several accounts at once: "give each account its own configuration directory" and set CLAUDE_CONFIG_DIR when you start claude. The first time you run each alias, Claude Code walks you through login and setup for that directory.

# ~/.bashrc or ~/.zshrc
alias claude-work='CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'
alias claude-personal='CLAUDE_CONFIG_DIR="$HOME/.claude-personal" claude'

# First run of each alias opens the browser login for that directory
claude-work
claude-personal

The docs' own example keeps your default account on plain claude and adds one alias for the second account; two named aliases work the same way. Both run side by side in separate terminals. To pin an account to a project, direnv works because it sets the variable in your shell: put export CLAUDE_CONFIG_DIR="$HOME/.claude-work" in the project's .envrc.

Where you set the variable matters:

• Shell, user settings, or managed settings work. The env-vars docs say project and local settings (.claude/settings.json and .claude/settings.local.json) cannot set CLAUDE_CONFIG_DIR, so a checked-in file will not choose an account for you.
• Use an absolute path in a settings file. Settings values are copied into the environment as written, so ~ and $HOME are not expanded there. The docs' example is "CLAUDE_CONFIG_DIR": "/home/you/.claude-work".
• Per-account state is per-directory. Settings, MCP servers configured in that directory, and session history do not carry over between accounts. Files in the repository itself, such as CLAUDE.md and .mcp.json, are shared by both.
• Check which account is active. Run /status inside a session to see the login method, organization, and email. The claude auth status subcommand also exists.

One limit from the docs: separate directories do not keep two Claude Console sign-ins (the keyless Console sign-in) apart, because Claude Code stores that kind of sign-in outside the configuration directory. If both of your accounts are Console accounts, use an API key per account instead. This is a different mechanism from Anthropic profiles and ant auth login, which store named credentials in a separate Anthropic configuration directory and are not how you run two claude.ai logins.

Method 2: switch in place with /logout and /login

For occasional changes, type /logout at the Claude Code prompt, then /login and authenticate as the other account. The docs note that logging out also resets your first-launch setup state, so the next start walks you through login and setup again. If you switch daily, separate directories save the repeated browser step.

Method 3: one OS user per person on a shared machine

When the machine is shared (a team dev server, a lab box), give each person an OS user. Each Unix user has their own home, so their own ~/.claude and their own login, and file permissions do the isolation.

# On the shared server, per teammate
sudo adduser priya
sudo su - priya
claude   # signs in as priya's own account, stored under /home/priya/.claude

Each person can run sessions in tmux under their own user, so sessions survive disconnects and nobody can read anyone else's credentials.

Account switchers people use

Three open-source tools come up in searches. All three are community projects that Anthropic does not maintain; check each README before relying on it.

• claude-multiprofile creates named profiles for Claude Code (macOS and Linux) and Claude Desktop (macOS only), each with its own login, settings and MCP servers and its own terminal command. For Claude Code it sets CLAUDE_CONFIG_DIR; for Desktop it launches a separate app with its own data directory. It is MIT licensed and its README calls itself an unofficial community tool.
• claude-switch is a shell script for macOS and Linux with create, list, and switch commands. Its README says it sets CLAUDE_CONFIG_DIR and launches the official claude binary, and it can link shared files such as CLAUDE.md and plugins across profiles. It states it is not affiliated with Anthropic. The same README also promotes a paid Mac app.
• claude-swap works differently. It swaps the account-specific login in place (macOS, Linux and Windows for the terminal interface), adds a usage dashboard, and can rotate to another account before a rate limit. Its session mode runs parallel sessions with separate chat history per account.

The first two wrap the same config-directory mechanism as the aliases above, so what they add is convenience: naming, listing, sharing files between profiles, and for claude-multiprofile a Desktop launcher. claude-swap changes which stored login is active instead, which is a different trade-off: it can rotate accounts automatically, and it modifies credential storage that the official docs describe as managed by /login and /logout. For two accounts on one machine, two aliases do the same job with nothing to install.

Anthropic's own feature request for named account profiles (claude-code issue 27359, opened in February 2026) is closed. Per the issue, the maintainer's answer is a separate config directory per account, which is Method 1. T3 Code, an open-source agent harness from the pingdotgg organization on GitHub, documents the same approach: its Claude provider docs have you set a CLAUDE_CONFIG_DIR path per Claude instance and run claude auth login with that variable set, and say existing threads can switch only between instances that share a config directory.

Automation: tokens and API keys

CI and scripts do not need a second interactive login. claude setup-token opens the same browser authorization as /login and prints a one-year OAuth token without saving it; you set it as CLAUDE_CODE_OAUTH_TOKEN. It uses your subscription (Pro, Max, Ultra, Team, or Enterprise) and can only make model requests. An ANTHROPIC_API_KEY from the Claude Console is a separate credential billed per token.

Precedence matters when you run several accounts. Per the docs, Claude Code picks the first credential present in this order: cloud provider credentials, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY, an apiKeyHelper script, CLAUDE_CODE_OAUTH_TOKEN, Anthropic profile credentials, then your /login subscription login. An ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN exported in your shell profile therefore overrides the per-directory login in every terminal, and ANTHROPIC_API_KEY switches you from subscription usage to API billing once approved. Run /status to confirm which method is active, and unset ANTHROPIC_API_KEY to fall back to your subscription. For the cost trade-off see subscription vs API credits for coding agents.

Usage limits are per account

Anthropic's Claude Code plan article says limits on a Pro or Max plan are shared across Claude and Claude Code, so all activity in both tools counts against the same limits for that account. A second account has its own limits, and using up one does not touch the other. Claude Code usage limits explained covers the windows and what happens at the cap.

The rules: your accounts and a shared account

Holding more than one account that you own, such as an employer-paid account and a personal one, is what the methods above are for. Sharing one account is different. Section 2 of Anthropic's consumer terms (effective October 8, 2025) says: "You may not share your Account login information, Anthropic API key, or Account credentials with anyone else. You also may not make your Account available to anyone else." That rules out one login for a team. For background on how enforcement is discussed, see coding harness ban risk.

A shared account also fails on mechanics. Two heavy users on one login draw from one set of limits and starve each other. Project history, MCP servers, and permissions live in the same directory, so everyone sees everyone's context. And when every session runs as one identity, you cannot tell who did what.

For teams, give each engineer their own account: Team or Enterprise plan seats, where each member signs in to Claude Code with their own invited account, or individual Pro or Max subscriptions. The same per-person rule applies to every other credential an agent touches; running coding agents on your own keys explains why per-user keys beat shared org keys for cost and control.

Where AQ fits

AQ is the multiplayer coding harness where teams build and run bots with every AI coding agent. It is a harness around the agent CLIs you already subscribe to: each person connects Claude Code, Codex, and the other agent CLIs with their own accounts, so there is no shared login to break the terms and no pooled quota to fight over. AQ never marks up usage on your own subscriptions.

One person can connect more than one account of the same CLI, for example a work and a personal Claude login. When the account a thread is using reaches its plan limit, the thread can continue on another connected account that still has room, with a note in the transcript. On a plain shared server, the OS-user pattern above is something you set up and maintain by hand. In AQ, agents run as the real CLIs in persistent tmux sessions on your team's VM, each person signed in as themselves, with per-user GitHub auth so commits and pull requests carry the right identity. Teammates can open the same workspace and watch the same live session, and typing into someone else's terminal happens only after its owner approves a control request. Each workspace gets its own git worktree, so parallel work does not collide. For team conventions, see managing Claude Code sessions across a team.

The Free plan is a personal sandbox for one person with nothing to install. The AQ Pro plan is $50 per user per month in early access (standard $200, billed monthly), and your rate is locked for your first 12 months. If you are one person with two subscriptions, the aliases above are enough. A harness starts to pay off when several engineers share the machine the agents run on.