How to Run Multiple Claude Code Accounts

Published August 8, 2026 · by the AQ team

Claude Code keeps exactly one active login per configuration directory, so the way to run multiple accounts is to give each account its own directory. Point the officially documented CLAUDE_CONFIG_DIR environment variable at a different folder per account and you can stay logged into a work account and a personal account at the same time, in parallel terminals, with no logout dance. On a shared machine the cleaner cut is one OS user per person, and for a whole team the honest answer is per-user accounts rather than one shared login, which Anthropic's consumer terms prohibit sharing anyway. This guide covers all three setups and the caveats on each platform.

One disambiguation first: multiple accounts is a different problem from multiple sessions. A single account can already run many Claude Code sessions at once on one machine; if that is what you want, see running multiple Claude Code sessions in parallel. You need multiple accounts when the logins themselves must differ: separate billing (work vs personal), separate organizations, or separate people.

Where Claude Code keeps your login

Claude Code authenticates through a browser OAuth flow the first time you run it, and stores the resulting credential per platform, as of August 2026:

• macOS: in the encrypted macOS Keychain.
• Linux: in a file at ~/.claude/.credentials.json with owner-only permissions.
• Windows: in .credentials.json under your user profile's .claude directory.

Alongside the credential, the ~/.claude directory and the ~/.claude.json state file hold your settings, project list, MCP servers, and session history. That combination is the important part: an "account" in Claude Code is really a config directory, and everything in it travels with the login. Switching accounts by running /logout and /login in place works, but it also swaps that whole world, and /logout resets the first-launch setup state, so the next start walks you through setup again.

Method 1: one config directory per account

Anthropic's documentation states that when the CLAUDE_CONFIG_DIR environment variable is set on Linux or Windows, the credentials file lives under that directory instead of the default. In practice this is the standard multi-account pattern on every platform: each directory holds its own login, settings, and MCP servers, so two accounts never interfere.

# One-time: log each account in to its own directory
CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude   # complete the browser login
CLAUDE_CONFIG_DIR="$HOME/.claude-personal" claude

# Make it permanent with shell aliases (~/.zshrc or ~/.bashrc)
alias claude-work='CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'
alias claude-personal='CLAUDE_CONFIG_DIR="$HOME/.claude-personal" claude'

Now claude-work and claude-personal run side by side in separate terminal tabs, each logged into its own account. If certain repositories should always use a particular account, tools like direnv can pin it per project: put an export of CLAUDE_CONFIG_DIR in the project's .envrc and the right account activates whenever you cd in.

Caveats worth knowing:

• Per-account state is really per-directory. MCP servers, permission grants, and history configured under one directory do not exist under the other. Anything that lives in the repository itself (CLAUDE.md, checked-in .claude project settings) is shared by both accounts automatically.
• macOS stores the token in the Keychain, not in the directory, so separation on macOS is less airtight than on Linux. After setting up, run /status inside each session and confirm the Login method row shows the account you expect.
• Usage limits do not blend. Each account keeps its own quota. Burning through one account's limit does not touch the other, which is exactly why some people run two subscriptions this way.

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

If you only change accounts occasionally, the built-in flow is fine: /logout, then /login, then complete the browser authentication as the other account. It costs a minute each time and re-runs first-launch setup. The moment you find yourself doing this daily, set up separate directories instead.

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

When the machine itself is shared (a team dev server, a lab box, a family desktop), environment-variable juggling is the wrong tool, because everyone would be flipping switches inside the same home directory. The operating system already solves this: give each person their own OS user. Each Unix user gets their own home, therefore their own ~/.claude, therefore their own independent Claude Code login, with file permissions doing the isolation instead of discipline.

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

This is the model that scales to teams, and it composes with the usual server workflow: each person runs their sessions inside tmux under their own user, so sessions survive disconnects and nobody can read anyone else's credentials.

Automation: tokens and API keys instead of more logins

Two adjacent cases look like a multiple-accounts problem but are not. For CI pipelines and scripts, claude setup-token generates a one-year OAuth token tied to your subscription that you set as CLAUDE_CODE_OAUTH_TOKEN, so headless environments never need a browser login. And an ANTHROPIC_API_KEY from the Claude Console is a separate credential with separate pay-per-token billing. One precedence gotcha from the official docs: if ANTHROPIC_API_KEY is set and approved, it overrides your subscription login even when you are signed in. Run /status to see which credential is actually active.

The rules: your accounts vs a shared account

Holding more than one account that you own (say, an employer-paid account and a personal one) is normal, and the methods above exist to make it livable. Sharing one account between people is different: as of August 2026, Anthropic's consumer terms prohibit sharing your account credentials or making your account available to anyone else, and reports of enforcement focus on credential resale and heavy concurrent use from one login.

Even setting the terms aside, a shared account fails on mechanics:

• One quota, many people. Subscription usage is pooled per account across Claude Code and Claude chat, within five-hour windows and weekly caps as of August 2026. Two heavy users on one login starve each other at exactly the moment both are productive.
• State bleeds. Project history, MCP servers, and permission grants are account-level, so everyone inherits everyone else's context and settings.
• No attribution. When every agent session runs as the same identity, you cannot tell who shipped what, and a single compromised credential exposes everyone at once.

For teams, the supported route as of August 2026 is a plan built for multiple people: Claude Team premium seats (roughly $100 per seat per month billed annually, five-seat minimum) or Enterprise, where each member logs into Claude Code with their own invited account, or individual Pro or Max subscriptions per engineer. Each person gets their own login and their own limits. The same per-person principle applies to every other credential an agent touches; our guide to running coding agents on your own keys covers why per-user beats shared org keys for cost and control.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. The account model in this guide is AQ's native design rather than an add-on: every engineer connects the CLIs with their own Claude or OpenAI account, so there is no shared login to violate terms with, no pooled quota to starve, and AQ never marks up model usage.

On a plain shared server, the OS-user pattern above is something you build and maintain by hand. On AQ, agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, each person authenticated as themselves, with per-user GitHub auth so commits and pull requests carry the right identity too. Sessions survive a closed laptop and resume from any device, and teammates can open the same workspace and watch the same live session; typing into someone else's terminal happens only after its owner approves a control request in one click. Each workspace gets its own isolated git worktree, so parallel work from different people never collides. For the day-to-day conventions on top (naming, ownership, visibility, handoffs), see managing Claude Code sessions across a team.

Pricing keeps the per-person logic: the Free plan is the full product on a VM you bring (you pay only your cloud provider), and the Team plan is $100 per user per month (promotional; standard $200, billed monthly) with a dedicated always-on VM managed by AQ in its own isolated network, your rate locked for your first 12 months.

If you are one person juggling two subscriptions, the aliases above are all you need. The account-per-person model earns a real harness when several engineers share the machine the agents run on.