09-two-claude-accounts-one-machine

title: "Running Two Claude Accounts Side by Side on the Same Machine"
date: 2026-06-23
tags: [claude, ai, homelab, linux]

---

Running Two Claude Accounts Side by Side on the Same Machine

I have two Claude subscriptions — a personal one and a work one through the University of Salford. Anthropic's rate limits apply per account, so when one hits the wall mid-session (and it does, usually at the worst possible moment) I'd like to be able to switch to the other and carry on, ideally without losing the thread of what I was doing. This turned out to be straightforward, once I understood how Claude Code manages its authentication.

How Claude Code Picks an Account

Claude Code stores its OAuth token in ~/.claude/.credentials.json. Everything else — settings, memory, session history, installed plugins, custom slash commands — lives alongside it in ~/.claude/. The key insight is that the binary respects a CLAUDE_CONFIG_DIR environment variable: point it somewhere else and that becomes the active profile. The credentials file in that directory determines which account you're logged into.

So: two directories, one credential each, everything else shared. That's the whole trick.

The Setup

I created ~/.claude-work/ as the work account's config directory. A small script, ~/.local/bin/claude-work, handles the rest: it creates the directory, symlinks the account-agnostic config from ~/.claude into it, sets CLAUDE_CONFIG_DIR, and launches claude. The symlinked items are:

• settings.json and settings.local.json — permissions, allowlists, preferences
• projects/ — the full session history and memory store
• plugins/ — installed plugins
• CLAUDE.md — the user-level instructions
• commands/ — custom slash commands
• statusline-command.sh — the statusline helper

The one thing deliberately not symlinked is .credentials.json — that stays private to each profile. Everything else is shared. The result is that switching accounts costs nothing: same memory, same history, same environment. The only difference is whose API quota is being consumed.

On first run, the work directory has no credential, so Claude opens its /login OAuth flow. Sign in once as the work account and the token is cached; subsequent runs go straight in. (Worth noting: my work account is on a Claude Team plan, and the organisation has disabled Remote Control. That can't be changed locally — it's expected behaviour.)

Persistent Sessions with tmux

My other requirement was that sessions should survive terminal closures, the same way a remote SSH session to a server would. I added two shell functions to ~/.bashrc:

claude() {
  if [ -n "$TMUX" ] || [ ! -t 1 ]; then command claude "$@"; else tmux new-session -A -s personal "command claude"; fi
}
claude-work() {
  if [ -n "$TMUX" ] || [ ! -t 1 ]; then command claude-work "$@"; else tmux new-session -A -s work "command claude-work"; fi
}

Running claude from any terminal now attaches to (or creates) a persistent tmux session named personal; claude-work does the same for work. Detach with Ctrl-b d. Re-running the command from another terminal reattaches. The -A flag means you never accidentally create a second session when one is already running. To pass flags directly — say, a non-interactive -p prompt — command claude bypasses the wrapper.

Sharing MCP Servers

The one thing that can't be symlinked is ~/.claude.json. This file holds the active account identity and gets written constantly during a session; sharing it between two concurrently running instances would be asking for corruption. Unfortunately it's also where project-scoped MCP servers are configured.

The solution is Claude's project-level .mcp.json file. Drop one in the working directory and it's loaded by both profiles automatically:

{ "mcpServers": { "cloudflare": { "type": "http", "url": "https://mcp.cloudflare.com/mcp" } } }

The claude.ai integrations (Gmail, Drive, Calendar, etc.) are account-connected — they arrive automatically with whichever account is logged in, no extra configuration needed.

Switching After a Rate Limit

In practice the workflow is: hit the rate-limit message, open a new terminal, type claude-work. The tmux session picks up and I'm in the work profile. From there, /resume shows the full session history — because projects/ is symlinked, both profiles read from the same store. I can pick up the conversation exactly where I left off, just on a different quota.

When the personal limit clears I switch back. The work session stays attached in its tmux window; nothing is lost on either side.

The Knowledgebase

Separately, I've been thinking about a knowledgebase — a collection of PDFs, images, and reference documents that Claude sessions can draw on. The numbers involved (low gigabytes, lots of files around 500KB each) are well within what Git LFS handles comfortably. The Gitea instance I run (CT116 on Proxmox) already has LFS support and I've grown its disk from 8GB to 32GB to give it comfortable headroom.

The files themselves will live on a TrueNAS NFS share (/mnt/knowledgebase, ZFS with LZ4 compression and 128K record size — well-suited to small files), already mounted on the laptop. Version history in Gitea, actual bytes on TrueNAS. It's empty for now but the plumbing is in place.

Is Any of This Novel?

Probably not — but I couldn't find it documented clearly anywhere, so perhaps this is useful to someone. The CLAUDE_CONFIG_DIR variable isn't prominently advertised; I found it by looking at what the binary actually checks at startup. The symlink approach for sharing config while keeping credentials separate feels like the right level of hackery: low-tech, transparent, and easy to undo.

Fare thee well and I hope you find this helpful.