Running Multiple Claude Code Accounts on One Device

I use Claude Code daily for both personal projects and work at my company. The problem: these are two completely different accounts with different OAuth sessions, different CLAUDE.md instructions, different MCP servers, and different project memory. Here's how I run them side by side on one machine with a single one-line shell alias.

The problem

Claude Code stores everything in ~/.claude by default — your OAuth token, conversation history, global CLAUDE.md, project memory, MCP server configs, and settings. When you have two accounts, you need two completely separate worlds:

• Personal account: your own Max/Pro subscription, personal CLAUDE.md with your preferences, your MCP servers (Obsidian, personal tools)
• Corporate account: company-managed plan, work CLAUDE.md with Jira/Slack integration instructions, company MCP servers
• Different OAuth sessions: you can't be logged into two accounts in the same config directory
• Different project memory: you don't want your work projects' context leaking into personal sessions and vice versa

Logging out and back in every time you switch context is not an option. You'd lose session state, and it's just painful.

The solution: CLAUDE_CONFIG_DIR

Claude Code respects a single environment variable: CLAUDE_CONFIG_DIR. Set it to any path, and Claude uses that directory instead of ~/.claude for everything — auth, history, settings, memory, the lot. The entire setup takes 60 seconds.

Step 1: Create a second config directory

Pick a name that makes sense for your use case:

mkdir ~/.claude-work

That's it. Claude will populate it with the necessary structure on first launch.

Step 2: Authenticate the second account

Run Claude once with the new config directory to trigger OAuth login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

This opens your browser. Log in with your corporate account. The OAuth token gets stored in ~/.claude-work — completely separate from your personal session in ~/.claude.

Step 3: Add a shell alias

Add this to your shell config so you don't have to remember the variable:

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

Reload your shell:

source ~/.zshrc

What you get

Now you have two completely isolated Claude environments:

• claude — launches with your personal account, personal CLAUDE.md, personal memory
• claude-work — launches with your corporate account, work-specific CLAUDE.md, separate memory
• Isolated history: work conversations stay in work, personal stays in personal
• Separate MCP servers: your personal Obsidian vault MCP doesn't show up in work sessions
• Independent settings: different allowed tools, different permission levels, different model preferences per account

How it works under the hood

The config directory is the single source of truth for Claude Code's state. Here's what lives inside each one:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

When you run claude-work, Claude reads everything from ~/.claude-work. It has no awareness that ~/.claude exists. The two instances are completely independent — you can even run them simultaneously in different terminal tabs.

Scaling to N accounts

The pattern extends to any number of accounts. Freelancer with multiple clients? Add more aliases:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Each alias gets its own config directory, its own OAuth session, its own CLAUDE.md with client-specific instructions. You could have a CLAUDE.md for Client A that knows their codebase conventions and Jira project, and a completely different one for Client B.

Practical tips

• Name your directories clearly: ~/.claude-work, ~/.claude-clientname — you'll thank yourself when you have three or four of these
• Write a tailored CLAUDE.md for each: your work CLAUDE.md can include company-specific instructions (how to create Jira tickets, Slack channels to reference, deployment procedures). Your personal one stays lean.
• Different MCP servers per account: configure work-specific tools (Jira MCP, Slack MCP, internal APIs) only in the work config. Keep your personal config clean.
• Check which account is active: run claude config list inside a session if you're ever unsure which account you're in — it shows the config directory path

Where this falls short

CLAUDE_CONFIG_DIR isolates by account, not by project. Inside a single profile, Claude sees every MCP server you've ever registered for that account — across all your projects. For solo personal use this is usually fine. The moment you have multiple production-critical projects under one account, especially in overlapping domains like billing, admin tooling, or infrastructure, it introduces a concrete cross-project risk: an AI assistant can call a tool from project A while working on project B, particularly when both expose similarly-named operations.

The profile pattern answers which account am I in?. It does not answer which project's tools should be active right now?. For higher-stakes work, stack a second layer of isolation on top of the account split:

• One profile per production-critical project, not just per account: instead of ~/.claude and ~/.claude-work, create ~/.claude-work-billing and ~/.claude-work-admin. Each profile sees only the MCP servers it actually needs.
• Project-scope MCP via .mcp.json: commit a .mcp.json at the project root listing only that project's MCP servers. Claude picks them up when launched from that directory. Keep your global config minimal — universal tools only (notes, search), no production endpoints.
• Name MCP servers unambiguously: avoid generic names like admin, billing, mcp-server. Prefix with the project: acme_billing_prod, acme_admin_stage. A descriptive name forces a pause when something is about to be called from the wrong context.
• Review every MCP tool call before approving: calls like *_create_*, *_delete_*, *_charge_* deserve a deliberate second look. Whatever speed you gain from blanket auto-approval evaporates the first time a tool from the wrong project fires against production.

The general rule: split profiles aggressively, keep production-grade MCP off the default profile, and treat tool-name overlap between projects as a smell worth refactoring.

Conclusion

One environment variable. One alias. Full isolation between accounts. No logout/login dance, no config conflicts, no context leakage. It's the kind of solution that's almost disappointingly simple — but that's what makes it good. Set it up once and never think about it again.