How To Run Personal and Work Claude Code Accounts Side-by-Side

Say you have two Claude accounts: a personal one you pay for, and a work one your company pays for. The work account should only ever touch company repos. The personal one is for everything else.

By default, Claude Code doesn't know the difference. Everything lives in ~/.claude, and switching accounts means logging out and back in — which means losing whatever session you were in the middle of. That's annoying enough in a terminal. It's worse when you're also using Claude Code through an IDE's agent panel and can't just pop open a second tab.

Here's how I set mine up to run both, fully isolated, so I never have to run /status to check which account I'm on ever again.

The fix: CLAUDE_CONFIG_DIR

Claude Code reads an environment variable called CLAUDE_CONFIG_DIR at startup. Point it at a folder, and that's where Claude Code stores its credentials, session history, and settings — instead of the default ~/.claude.

Give each account its own folder, and you get two fully independent Claude Code identities that never touch each other's data.

This used to be an undocumented trick — for a long time the only reference was a GitHub issue asking Anthropic to document it, with people using it anyway because it clearly worked. It's since graduated to officially documented status, multi-account use case and all.

Terminal setup

1. Create a config folder for each account

mkdir -p ~/.claude-personal
mkdir -p ~/.claude-work

2. Add shell functions

Drop these in your ~/.zshrc (or ~/.bashrc):

claude-personal() {
    CLAUDE_CONFIG_DIR=~/.claude-personal claude "$@"
}

claude-work() {
    CLAUDE_CONFIG_DIR=~/.claude-work claude "$@"
}

Reload your shell:

source ~/.zshrc

3. Log in to each one, once

claude-personal /login
claude-work /login

Each stores its credentials in its own folder. From here on, claude-personal and claude-work are two totally separate Claude Code instances — separate auth, separate conversation history, separate everything. You can even run them at the same time in separate terminals.

4. Don't share history between them

You'll find posts out there suggesting you symlink the two projects folders together so both accounts can --resume each other's sessions. I'd skip that. If your work account is only supposed to touch company repos, merging its session history with your personal one means company code and conversations end up sitting in the same directory tree as your personal projects — which is exactly the kind of thing that ends up in a dotfiles backup or a personal cloud sync without you noticing. Keep them separate.

Automatically summon the correct Claude

Nothing stops you from typing claude (personal) while sitting inside a work repo. It's just two commands; remembering which one to use is on you.

I never want to run my personal Claude in a work directory; I never want to run my work Claude in a personal directory. direnv solves this by setting the variable automatically based on which directory you're in:

# .envrc in the root of a company repo
export CLAUDE_CONFIG_DIR=~/.claude-work

direnv allow

Now cd-ing into that repo sets CLAUDE_CONFIG_DIR for you — plain claude just does the right thing. Keep .envrc out of the repo's history with a local, unshared ignore rule (don't touch the project's actual .gitignore — this is your workflow, not the team's):

echo '.envrc' >> .git/info/exclude

Doing the same thing in Zed's Agent Panel

If you're only using Claude Code from the terminal, you're done. If you're also using it through an IDE's built-in agent panel — I use Zed — there's an extra step, because the panel doesn't necessarily inherit your shell environment or your shell functions.

In Zed, the built-in Claude Agent is installed from the ACP Registry, and registry-installed agents are locked to a single instance — you can't just duplicate the entry under a new name and expect it to behave differently. Instead, add two custom entries that each launch Claude Code's ACP adapter directly, with their own CLAUDE_CONFIG_DIR:

{
  "agent_servers": {
    "Claude Agent (Personal)": {
      "type": "custom",
      "command": "npx",
      "args": ["@agentclientprotocol/claude-agent-acp@latest", "--acp"],
      "env": {
        "CLAUDE_CONFIG_DIR": "/Users/you/.claude-personal"
      }
    },
    "Claude Agent (Work)": {
      "type": "custom",
      "command": "npx",
      "args": ["@agentclientprotocol/claude-agent-acp@latest", "--acp"],
      "env": {
        "CLAUDE_CONFIG_DIR": "/Users/you/.claude-work"
      }
    }
  }
}

Now the Agent Panel's new-thread menu shows two named agents instead of one generic one. Pick the right one when you start a thread, /login each the first time, and you're set. This is honestly a little safer than the terminal aliases — you're explicitly picking an account from a list each time, instead of relying on muscle memory.

Usage cheat sheet

Context	Command / selection	Account
Terminal	claude-personal	Personal
Terminal	claude-work	Work
Terminal, inside a direnv-tagged repo	plain claude	Work (automatic)
Zed Agent Panel	"Claude Agent (Personal)"	Personal
Zed Agent Panel	"Claude Agent (Work)"	Work

Wrapping up

• CLAUDE_CONFIG_DIR gives you fully isolated Claude Code accounts — separate credentials, separate session history — by pointing each one at its own folder.

• Don't symlink the two accounts' history together, even though it's tempting. It defeats the point of keeping them separate in the first place.

• Shell aliases solve this for the terminal, but they can't enforce anything — direnv can, if you want the switch to happen automatically instead of relying on memory.

• If you're also using an IDE's agent panel, check whether it actually inherits your shell environment. In Zed's case it doesn't, so the account split needs to be configured separately as two named agent_servers entries.