# 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](https://github.com/anthropics/claude-code/issues/33430) asking Anthropic to document it, with people using it anyway because it clearly worked. It's since graduated to [officially documented status](https://code.claude.com/docs/en/env-vars#variables), multi-account use case and all.

## Terminal setup

### 1\. Create a config folder for each account

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

### 2\. Add shell functions

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

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

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

Reload your shell:

```bash
source ~/.zshrc
```

### 3\. Log in to each one, once

```bash
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`](https://direnv.net/) solves this by setting the variable automatically based on which directory you're in:

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

```bash
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):

```bash
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`:

```json
{
  "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.