Use multiple Claude Code accounts on one machine: work and personal

Updated 2026-10-10

Claude Code keeps one login per configuration directory, and the CLAUDE_CONFIG_DIR environment variable chooses that directory. Give the second account its own directory, start Claude Code with the variable pointing at it, and both accounts stay signed in at once: switching needs no /logout and /login round trip, and a work session and a personal session can run side by side in two terminals.

#Set up a second account

Anthropic documents this under Log in with multiple accounts: each configuration directory has its own settings, session history, and claude.ai login or API key. One alias per extra account in ~/.bashrc or ~/.zshrc is enough:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Open a new terminal and run claude-work. The directory is new, so Claude Code walks you through login and first-run setup; sign in with the work account. Plain claude keeps using ~/.claude and your personal login. Expect each project to ask about folder trust again on its first launch under the new account, because trust decisions are stored per configuration directory (see the table below).

Leave the variable unset for the default account. Setting it to ~/.claude is not the same thing: with the variable set, Claude Code keeps its .claude.json file inside that directory instead of at ~/.claude.json (Anthropic's dev container guide relies on exactly this), so your existing ~/.claude.json is no longer the file it reads.

In PowerShell, a function does the same job:

function claude-work {
  $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-work"
  try { claude @args } finally { Remove-Item Env:CLAUDE_CONFIG_DIR }
}

Two limits on where the variable can come from. Project and local settings cannot set it, so a repository cannot pin itself to an account; use the alias, or a per-directory environment tool such as direnv that exports it when you enter work repositories. And the VS Code extension applies a CLAUDE_CONFIG_DIR entry in its environmentVariables setting only when the value is an absolute path: it does not expand ~ and ignores a relative value.

#Check which account a session is using

Inside a session, /status opens the Status tab with the version, model, account and connectivity. It works while Claude is responding, so you can check mid-task.

From a shell, claude auth status prints JSON and exits 0 when logged in, 1 when not. Its authMethod field names the credential type, and on v2.1.268 or later configDirectory names the directory in use:

claude-work auth status --text
claude-work auth status | jq -r '.configDirectory, .authMethod'

If the account shown is not the one you logged in with, look for a credential in the environment. Claude Code's authentication precedence ranks cloud provider variables, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY (in interactive mode once you approve it, in -p always), apiKeyHelper and CLAUDE_CODE_OAUTH_TOKEN above the subscription login from /login. One of those variables exported in your shell profile applies to every alias and overrides the login stored in each directory. When both a login and an API key are configured, /status marks the one that is not in use.

#Where the credentials live

From Anthropic's credential management docs:

• Linux: .credentials.json, file mode 0600, inside the configuration directory.
• Windows: .credentials.json inside the configuration directory, restricted by your user profile's access controls.
• macOS: the Keychain, with the entry keyed to the configuration directory, so a session with a different CLAUDE_CONFIG_DIR reads a different entry. When the Keychain rejects the write, for example while it is locked in an SSH session, the login goes to .credentials.json inside the configuration directory instead.

One sign-in type does not separate this way. A Claude Console sign-in without an API key is stored as an Anthropic profile in a directory of its own (by default ~/.config/anthropic on macOS and Linux), outside the Claude Code configuration directory, so two of those cannot be kept apart with CLAUDE_CONFIG_DIR. Whatever the platform, run /status after the first login in each directory to confirm which account it holds.

#What each account keeps separately

With the variable set, every path Claude Code documents under ~/.claude lives under the new directory instead. Files in the repository are not touched:

What that means in practice:

• Your setup does not carry over. A new directory starts empty. Copy what you want in both accounts, such as settings.json, CLAUDE.md, skills/ and agents/, from ~/.claude. Do not copy .credentials.json or .claude.json: they hold the other account's login and state.
• MCP servers are per account. User-scope servers are stored in .claude.json, so add them again through the alias: claude-work mcp add --scope user .... Servers in a repository's .mcp.json load for both accounts. Connectors added in claude.ai follow the claude.ai account the session is logged into.
• Session history is per account. Each account writes transcripts to its own projects/ directory (where transcripts are stored), so claude --continue and /resume under one alias do not see conversations started under the other.

#Tools that read ~/.claude/projects

Anything that reads transcripts from a hardcoded ~/.claude/projects (your own scripts, transcript viewers, usage dashboards) will not see the second account's sessions. If the tool cannot be pointed at another directory, a symlink puts the transcripts back into the default tree:

mkdir -p ~/.claude-work
ln -s ~/.claude/projects ~/.claude-work/projects

Create the link before the account's first session, while ~/.claude-work/projects does not exist yet. If it is already a directory, ln -s puts the link inside it, so move its contents into ~/.claude/projects and remove it first. The trade-off: both accounts then read and write the same transcripts and auto memory (auto memory lives under projects/<project>/memory/ too), so session history is no longer separated. Logins, settings and MCP servers stay per account.

#How Codeman handles it

Codeman runs each agent session in its own tmux session, and a Claude session can be pointed at a separate configuration directory through its per-session environment overrides, so sessions on different accounts run side by side in one dashboard. CLAUDE_CONFIG_DIR is the one key in the environment allowlist that is accepted by exact name rather than by prefix (Agent CLIs).

• API only. The web UI has no field for it. Send it as envOverrides on POST /api/quick-start, or on POST /api/sessions followed by POST /api/sessions/:id/interactive to start the session. Authentication and the base URL are covered in HTTP API.

  curl -s -X POST "$API/api/quick-start" -H 'Content-Type: application/json' \
    -d '{"caseName":"acme","envOverrides":{"CLAUDE_CONFIG_DIR":"/home/you/.claude-work"}}'
  

• Absolute path. The value is handed to tmux setenv exactly as sent, so no shell expands ~.

• First login. Open the new session in the browser and run /login with that account once. Later sessions pointed at the same directory use the stored login.

• Persistence. The key is saved with the session, so respawns, a Codeman restart and reboot restore relaunch it on the same account.

• Multi-user mode. Only admins and users with the bypass-permissions grant can set it. For anyone else the key is silently dropped from the request, and a saved one is dropped at reboot restore, which returns that session to the default account (Multi-User Mode).

• Local cases only. Quick-start refuses envOverrides for remote SSH and Docker cases.

• The transcript blind spot applies. The response viewer, subagent windows, ultracode panel and Read My Mind read ~/.claude/projects, so they show nothing for such a session until you add the symlink above.

• MCP server sync follows a CLAUDE_CONFIG_DIR set in Codeman's own environment, not a per-session one (Settings Reference).