Two Claudes, One Machine. A 20 min setup guide.

How I finally got personal and work AI to play nice.

Set the environment variable `CLAUDE_CONFIG_DIR` to point at different directories, and Claude Code becomes a different person — different login, different skills, different plugins. I use two terminal apps (Ghostty for personal, Warp for work), each automatically routing to its own config. Shared skills live in a third directory and get symlinked into both. The whole setup takes 20 minutes and runs on about 6 lines of shell config. Full walkthrough below.

I’ve been using Claude Code daily — for personal projects, for work, for the weird late-night “what if I built a...” experiments that never quite turn into anything. And for months, I had a problem that sounds trivial but was quietly driving me nuts: I only had one Claude Code account on my machine, and it was doing double duty.

My work prompts were bleeding into my personal context. Skills I’d built for side projects were showing up at work. My API keys, my MCP servers, my plugins — all jammed into one configuration directory that Claude reads every time it starts up.

I knew I needed to split them. I just didn’t know how Claude Code actually organizes itself on disk, and the docs weren’t making it obvious. So I spent a weekend figuring it out. Here’s what I learned.

The One Thing You Need to Understand

Claude Code stores everything about your account — your login credentials, your settings, your skills, your plugins — in a single directory. By default, that’s ~/.claude/ on your machine.

Here’s what I wish someone had told me upfront: there’s an environment variable called CLAUDE_CONFIG_DIR that tells Claude Code where to look. Change the variable, and Claude becomes a completely different person. Different login, different skills, different plugins. Same machine.

That’s it. That’s the whole trick. Everything else in this post is just making that one idea convenient.

Why Not Just Switch Accounts?

Sure, you can log out and log back in. But if you’re using Claude Code throughout the day — terminal open, context loaded, mid-conversation — logging out destroys all of that. You also lose your plugin configurations, custom skills, and MCP server setups every time you switch.

I wanted something dumber and more reliable. Open one terminal, you’re personal. Open the other, you’re work. No switching ritual.

The Setup: Two Terminals, Two Lives

I use two different terminal apps: one for personal, one for work. This isn’t strictly necessary — you could use one terminal with different profiles — but having two distinct apps makes the boundary feel real. You open the personal terminal and you’re in personal mode. There’s no ambiguity.

Here’s the structure I ended up with:

~/.claude-personal/     <- personal account config, credentials, plugins
~/.claude-work/         <- work account config, credentials, plugins
~/.claude-shared/       <- skills shared between both (symlinked into each)

Step 1: Create the directories

mkdir -p ~/.claude-personal/skills ~/.claude-personal/plugins
mkdir -p ~/.claude-work/skills ~/.claude-work/plugins
mkdir -p ~/.claude-shared/skills ~/.claude-shared/plugins

I started fresh for both — no copying from my existing ~/.claude/. That old config had accumulated cruft (stale plugin references, settings I’d forgotten about), and copying it would have just moved the mess into two places.

Back up your existing config first, though:

cp -a ~/.claude ~/.claude-backup-$(date +%Y%m%d)

Step 2: Set up each account’s config

Each directory needs a settings.json. Here’s a minimal one:

{
  "permissions": {
    "allow": ["WebSearch", "WebFetch"]
  },
  "enabledPlugins": {},
  "effortLevel": "medium"
}

If you use MCP servers, drop an mcp.json in each directory too:

{
  "mcpServers": {
    "your-server": {
      "command": "/path/to/your/server",
      "args": ["mcp"]
    }
  }
}

You can have the same servers in both accounts or different ones. Your call.

Step 3: Route each terminal to the right config

For your personal terminal (I use Ghostty), you can set the environment variable directly in the terminal’s config. In Ghostty, there’s a command option that lets you specify how shells start:

command = /bin/zsh --login -c "CLAUDE_CONFIG_DIR=$HOME/.claude-personal exec zsh"

Every shell that opens in Ghostty now automatically points Claude Code at the personal config.

For your work terminal (I use Warp), I added a block to my ~/.zshrc:

# Warp -> work account automatically
if [[ "$TERM_PROGRAM" == "WarpTerminal" ]]; then
  export CLAUDE_CONFIG_DIR="$HOME/.claude-work"
fi

Warp sets $TERM_PROGRAM to "WarpTerminal" in every shell session. So any shell opened in Warp automatically gets the work config. No extra steps. No remembering.

Step 4: Log in from each terminal

Open your personal terminal:

claude login    # browser opens, sign in with personal account
claude /status  # verify it shows your personal email

Open your work terminal:

claude login    # browser opens, sign in with work account
claude /status  # verify it shows your work email

That’s it. From now on, claude in each terminal knows who it is.

Step 5: Install plugins per-account

One thing that tripped me up: plugins can’t be file-copied between configs. You have to install them through Claude Code, and each install goes into whatever config directory is currently active.

# In your work terminal
claude install frontend-design@claude-plugins-official
claude install swift-lsp@claude-plugins-official

# In your personal terminal
claude install frontend-design@claude-plugins-official

The claude install command automatically updates settings.json for you. Don’t manually edit the enabledPlugins section — I tried, and stale references to plugins that no longer exist caused “plugins failed to load” errors on every startup.

Sharing Skills Between Accounts

This was the part I cared about most. I have skills — sets of instructions and reference files that tell Claude how to do specific things — and some of them are useful everywhere. A research report generator, for instance, is useful at work and at home.

The solution is symlinks. Put the real skill in ~/.claude-shared/, then create symlinks from each account’s skills/ directory:

# Put the skill in shared
cp -a ~/my-useful-skill ~/.claude-shared/skills/

# Symlink into both accounts
ln -sfn $HOME/.claude-shared/skills/my-useful-skill ~/.claude-personal/skills/
ln -sfn $HOME/.claude-shared/skills/my-useful-skill ~/.claude-work/skills/

Now both accounts see the skill. Edit it from either side, and the other picks up changes instantly — because they’re both pointing to the same files.

Important gotcha: symlinks must use absolute paths on your actual machine (like /Users/yourname/...). Relative paths or paths inside sandboxed environments silently fail, and the skill just won’t show up. I lost an hour to this.

For skills that should only exist in one account — say, a company-specific presentation template — just drop them directly in that account’s skills/ folder. No symlink needed.

Skills vs. Commands: When to Use Which

This confused me at first because they live in similar places and do similar-sounding things. But once I understood the difference, I started reaching for the right one instinctively.

A command is a saved prompt. It’s a markdown file that lives in your-project/.claude/commands/ and gets injected into the conversation when you type its name with a slash. I have one called /daily that asks Claude to review what changed in my notes today and surface anything I should act on. The whole thing is a single markdown file — maybe 15 lines of instructions. That’s it. No supporting files, no context beyond what’s in the prompt itself.

A skill is a command with a brain. It lives in your-project/.claude/skills/ (or ~/.claude-{account}/skills/ at the user level) and it’s a folder, not a file. Inside that folder you can put a SKILL.md with instructions, but you can also include reference files, templates, example outputs, knowledge directories — anything Claude should read before doing the work. I have a skill for generating research reports that includes an HTML template, a CSS file for styling, and examples of what good output looks like. Claude reads all of that before it starts writing. A command can’t do that.

The rule of thumb I landed on: if your prompt needs to reference other files to do its job well, make it a skill. If it’s self-contained instructions, a command is simpler and works fine.

A few examples from my setup:

My /daily and /startday prompts are commands. They’re short instructions that tell Claude what to review and how to summarize it. No reference material needed.

My research report generator is a skill. It needs an HTML template, styling rules, and example outputs to produce something that looks professional. A bare prompt wouldn’t get close.

My presentation builder is a skill. It references a corporate slide template file so Claude generates .pptx files with the right fonts, colors, and layouts. Without that template file sitting in the skill folder, Claude would just guess at the formatting.

One more thing worth knowing: commands only work at the project level. You cd into a project, and its commands show up. Skills work at both levels — project-level skills activate when you’re in that directory, and user-level skills (the ones in ~/.claude-personal/skills/ or ~/.claude-work/skills/) follow you everywhere regardless of what directory you’re in.

Understanding the Layers

There’s a subtlety here that took me a while to grasp. Claude Code actually looks for skills and configuration in multiple places, layered on top of each other:

User-level skills (~/.claude-{account}/skills/) — these are what we’ve been setting up. They’re tied to your account and follow you everywhere.

Project-level skills (your-project/.claude/skills/) — these live inside a specific project directory. When you run Claude Code inside that project, these skills activate automatically, regardless of which account you’re using. They’re great for project-specific workflows.

Project-level commands (your-project/.claude/commands/) — similar to skills but simpler. A command is a prompt template that gets injected into the conversation when you invoke it (like /daily or /startday). A skill is richer — it can include reference files, knowledge directories, and scripts alongside its instructions.

The dual-account setup only affects the user level. Project-level skills and commands work exactly the same as before.

The Override Aliases

Most of the time, the terminal-based routing handles everything. But occasionally you need to cross the line — run a personal command from your work terminal, or vice versa. For those moments, I added two aliases to my ~/.zshrc:

alias pclaude='CLAUDE_CONFIG_DIR=~/.claude-personal claude'
alias wclaude='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Type pclaude in any terminal, and it runs Claude Code with your personal config, just for that one session. These are the escape hatches. I use them maybe once a week.

What About Claude Desktop?

Here’s the honest answer: Claude Desktop (and its Cowork mode) doesn’t support CLAUDE_CONFIG_DIR. It manages its own authentication through the app’s UI, and there’s no profile switching — you sign out and sign back in. It’s a known gap, and there’s an open GitHub issue tracking it.

My workaround: I keep Desktop signed into my work account (since that’s where I use it most during the day). For personal GUI access, I use a different client that supports the environment variable.

Not ideal, but functional.

The Gotchas I Hit So You Don’t Have To

Stale plugin references break startup. If enabledPlugins in your settings.json references a plugin that isn’t actually installed, Claude Code throws a “plugins failed to load” error every time. Some plugins that existed a few months ago have been deprecated. Only list what’s actually installed.

Symlinks must use real absolute paths. Not relative paths, not paths from inside a VM or container. The symlink target has to resolve on your actual machine, or Claude Code silently ignores the skill.

Start fresh, don’t copy. Copying your existing ~/.claude/ into the new directories brings along all the accumulated weirdness — broken references, settings you forgot you changed, credentials in the wrong state. A clean start takes five extra minutes and saves hours of debugging.

claude install is the only safe way to add plugins. It handles updating settings.json correctly. Manual edits tend to get the format wrong or reference plugins by their old names.

Is This Worth It?

For me, absolutely. The cognitive load of having one tangled config was small on any given day, but it accumulated. Work plugins showing up in personal projects. Personal skills cluttering my work environment. The nagging feeling that my contexts were cross-contaminating each other.

Now I open Ghostty and I’m home. I open Warp and I’m at work. Same tool, same AI, right context. The whole thing runs on one environment variable and a few lines in my shell config.

The whole setup takes about 20 minutes if you follow these steps. The rollback is trivial — delete the new directories, restore your backup, remove the shell config lines. Low risk, high reward.

---

Quick Reference Card

The magic variable:

export CLAUDE_CONFIG_DIR="$HOME/.claude-personal"

Directory structure:

~/.claude-personal/          # personal config, credentials, plugins
~/.claude-work/              # work config, credentials, plugins
~/.claude-shared/skills/     # skills symlinked into both

Terminal routing (in ~/.zshrc):

# Route by terminal app
if [[ "$TERM_PROGRAM" == "WarpTerminal" ]]; then
  export CLAUDE_CONFIG_DIR="$HOME/.claude-work"
fi

Override aliases (in ~/.zshrc):

alias pclaude='CLAUDE_CONFIG_DIR=~/.claude-personal claude'
alias wclaude='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Share a skill between accounts:

ln -sfn $HOME/.claude-shared/skills/my-skill ~/.claude-personal/skills/
ln -sfn $HOME/.claude-shared/skills/my-skill ~/.claude-work/skills/

Skills vs. commands:

Command — a saved prompt. Single .md file in project/.claude/commands/. Project-level only. Use when your instructions are self-contained.

Skill — a folder with instructions + reference files. Lives in project/.claude/skills/ or ~/.claude-{account}/skills/. Works at project level or user level (follows you everywhere). Use when your prompt needs templates, examples, or supporting files.

Gotchas:

• Symlinks must use absolute paths (/Users/you/...), not relative

• Install plugins with claude install, never edit enabledPlugins by hand

• Start fresh — don’t copy your old ~/.claude/ into the new directories

• Claude Desktop doesn’t support CLAUDE_CONFIG_DIR yet

---

The key insight came from a post by Jacques Thibodeau about using aliases for multi-account Claude Code, and a GitHub gist documenting the CLAUDE_CONFIG_DIR approach.