Multiple accounts in Claude Code: the complete setup

A developer documented a method for managing multiple Claude Code accounts by using the CLAUDE_CONFIG_DIR environment variable to create isolated config directories. The approach involves creating separate directories per account, setting shell aliases or a wrapper script, and authenticating each instance independently. The developer also highlighted pitfalls such as fragile absolute binary paths, shared project-level settings, and missing custom hooks in new config directories.

You have a personal Claude Code subscription and a work one. Or you freelance for two clients who each provide their own API key. Or you want a sandboxed account for experiments that won't pollute your main config. Whatever the reason, Claude Code doesn't ship with a built-in "switch account" command. But the architecture makes it straightforward: everything lives in a single config directory, and you can redirect it. Claude Code keeps all its state in ~/.claude by default. That includes: .claude/ inside each repo The key insight: the CLAUDE CONFIG DIR environment variable overrides where Claude Code looks for all of this. Point it somewhere else, and you get a completely independent instance. Create one config directory per account: mkdir -p ~/.claude-personal mkdir -p ~/.claude-work Find your Claude binary path: which claude e.g. /Users/you/.nvm/versions/node/v22.15.0/bin/claude Add aliases to your ~/.zshrc or ~/.bashrc : alias claude-personal='CLAUDE CONFIG DIR=~/.claude-personal claude' alias claude-work='CLAUDE CONFIG DIR=~/.claude-work claude' Reload your shell: source ~/.zshrc Then authenticate each one separately: claude-personal run /login inside the session claude-work run /login inside the session Each alias now opens Claude Code with its own auth, memory, and settings. The alias trick works, but it has gaps that will bite you in production use. If you hardcode the binary path in your alias as many guides suggest , upgrading Node via NVM silently breaks it. Use just claude instead of the absolute path, and let $PATH resolve it: fragile alias claude-work='CLAUDE CONFIG DIR=~/.claude-work /Users/you/.nvm/versions/node/v22.15.0/bin/claude' resilient alias claude-work='CLAUDE CONFIG DIR=~/.claude-work claude' Claude Code creates a .claude/ directory inside your project repo. That directory stores project settings, CLAUDE.md , and settings.json . These are shared across all your aliases because they live in the repo, not in the config dir. This means your work account and personal account see the same project-level instructions. That's usually fine, but if you need different MCP servers or permissions per account per project, you'll need to handle it differently see the wrapper script section below . If you've configured custom hooks or MCP servers in ~/.claude/settings.json , those won't exist in your new config directories. You'll need to copy or symlink the parts you want shared: share hooks across accounts ln -s ~/.claude/settings.json ~/.claude-work/settings.json Or, if you want different hooks per account, copy and customize: cp ~/.claude/settings.json ~/.claude-work/settings.json Each config directory has its own memory system. Your personal account won't remember what your work account learned. If you use memory-heavy workflows, that isolation is sometimes a feature, sometimes a problem. Instead of simple aliases, a small wrapper gives you account switching with validation: bash /usr/bin/env bash Save as ~/bin/claude-switch and chmod +x ACCOUNT="${1:?Usage: claude-switch <account-name claude args... }" shift CONFIG DIR="$HOME/.claude-$ACCOUNT" if -d "$CONFIG DIR" ; then echo "Account '$ACCOUNT' not found. Available accounts:" ls -d ~/.claude- 2 /dev/null | sed 's|. /.claude-||' exit 1 fi CLAUDE CONFIG DIR="$CONFIG DIR" exec claude "$@" Usage: claude-switch work claude-switch personal --resume claude-switch work -p "fix the login bug" This passes all arguments through, so flags like --resume , --print , and -p all work. If a specific repo should always use a specific account, you can set it in a .envrc file if you use direnv https://direnv.net : /path/to/work-project/.envrc export CLAUDE CONFIG DIR="$HOME/.claude-work" Now every time you cd into that project and run claude , it automatically uses the work account. No alias needed. Without direnv, you can add it to the project's shell history or a local .env file that your shell sources. There are two authentication modes in Claude Code, and they interact differently with multi-account setups: OAuth default : You run /login and authenticate through Anthropic's web flow. The token is stored in the config directory. This is what most people use with Claude Pro/Max subscriptions. API key: You set ANTHROPIC API KEY as an environment variable. This bypasses the config directory's auth entirely. For API key setups, you don't even need separate config directories for auth. You can just switch the key: alias claude-client-a='ANTHROPIC API KEY=$CLIENT A KEY claude' alias claude-client-b='ANTHROPIC API KEY=$CLIENT B KEY claude' But you'll still want separate config directories if you need isolated memory, hooks, or MCP servers. The most robust setup for freelancers or consultants: ~/.zshrc export CLIENT A KEY="sk-ant-..." or source from a secrets manager alias claude-client-a='ANTHROPIC API KEY=$CLIENT A KEY CLAUDE CONFIG DIR=~/.claude-client-a claude' alias claude-client-b='ANTHROPIC API KEY=$CLIENT B KEY CLAUDE CONFIG DIR=~/.claude-client-b claude' Each client gets: You can run multiple Claude Code instances in parallel, each in its own terminal tab. The config directories are independent, so there's no locking or conflict. Terminal 1 claude-work Terminal 2 claude-personal Both sessions run concurrently without interference. This is useful when you're waiting on a long task in one account and want to work on something else in another. | What you want | What to set | |---|---| | Different auth | CLAUDE CONFIG DIR | | Different API key | ANTHROPIC API KEY | | Different memory | CLAUDE CONFIG DIR | | Different MCP servers | CLAUDE CONFIG DIR + custom settings.json | | Per-project default | .envrc with CLAUDE CONFIG DIR | | All of the above | Combined alias with both env vars | Everything above covers Claude Code the CLI . If you also use the Claude desktop app and want two instances running side by side with different accounts, the approach is different: you need to duplicate the app itself. On macOS, Parallels Toolbox https://www.parallels.com/products/toolbox/ can create an "app shortcut" that acts as a second copy of Claude. Each copy maintains its own login session, so you can run your work account in one window and your personal account in another, without logging in and out. This walkthrough https://youtu.be/IF1qZmCLWFk shows the full setup. The process: open Parallels Toolbox, create an app shortcut pointing to Claude, give it a distinct name like "Claude Work" , approve it in macOS security settings, and log in with your second account. Both instances live in your dock and run independently. This pairs well with the CLI multi-account setup: use CLAUDE CONFIG DIR aliases for terminal work, and Parallels app shortcuts for the desktop GUI. Two config directories: ~/.claude-personal for my own projects, ~/.claude-work for client work. Direnv handles the switching per project, so I just type claude and it picks the right account. I symlink settings.json from my personal config to the work one because I want the same hooks everywhere, but memory stays separate. The total setup took five minutes. The part that took longest was realizing I needed to re-run /login in each config directory after creating it. Originally published on jguillaumesio.com