Flere Claude Code-konti på én enhed

Jeg bruger Claude Code dagligt — til personlige projekter og til arbejde. Problemet: det er to helt forskellige konti med forskellige OAuth-sessioner, forskellige CLAUDE.md-instruktioner, forskellige MCP-servere og separat projekthukommelse. Sådan kører jeg dem parallelt på én enhed med et enkelt shell-alias.

Problemet

Claude Code gemmer alt i ~/.claude som standard — OAuth-token, samtalehistorik, global CLAUDE.md, projekthukommelse, MCP-serverkonfigurationer og indstillinger. Med to konti har du brug for to helt adskilte verdener:

• Personlig konto: eget Max/Pro-abonnement, personlig CLAUDE.md med dine præferencer, dine MCP-servere (Obsidian, personlige værktøjer)
• Virksomhedskonto: virksomhedsplan, arbejds-CLAUDE.md med Jira/Slack-integrationsinstruktioner, virksomhedens MCP-servere
• Forskellige OAuth-sessioner: du kan ikke være logget ind på to konti i samme konfigurationsmappe
• Separat projekthukommelse: du vil ikke have at arbejdskontekst lækker ind i personlige sessioner og omvendt

At logge ud og ind hver gang du skifter kontekst er ikke en mulighed. Du mister sessionstilstanden, og det er simpelthen smertefuldt.

Løsningen: CLAUDE_CONFIG_DIR

Claude Code respekterer én enkelt miljøvariabel: CLAUDE_CONFIG_DIR. Sæt den til en vilkårlig sti, og Claude bruger den mappe i stedet for ~/.claude til alt — auth, historik, indstillinger, hukommelse. Hele opsætningen tager 60 sekunder.

Trin 1: Opret en anden konfigurationsmappe

Vælg et navn der passer til dit brugsscenarie:

mkdir ~/.claude-work

Færdig. Claude udfylder den med den nødvendige struktur ved første start.

Trin 2: Autentificer den anden konto

Kør Claude én gang med den nye konfigurationsmappe for at udløse OAuth-login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Browseren åbner sig. Log ind med din virksomhedskonto. OAuth-tokenet gemmes i ~/.claude-work — fuldstændig adskilt fra din personlige session i ~/.claude.

Trin 3: Tilføj et shell-alias

Tilføj dette til din shell-konfiguration så du ikke behøver at huske variablen:

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

Genindlæs din shell:

source ~/.zshrc

Hvad du får

Nu har du to fuldstændig isolerede Claude-miljøer:

• claude — starter med personlig konto, personlig CLAUDE.md, personlig hukommelse
• claude-work — starter med virksomhedskonto, arbejdsspecifik CLAUDE.md, separat hukommelse
• Isoleret historik: arbejdssamtaler forbliver i arbejde, personlige forbliver personlige
• Separate MCP-servere: din personlige Obsidian vault MCP vises ikke i arbejdssessioner
• Uafhængige indstillinger: forskellige tilladte værktøjer, forskellige tilladelsesniveauer, forskellige modelpræferencer per konto

Sådan fungerer det under motorhjelmen

Konfigurationsmappen er den eneste sandhedskilde for Claude Codes tilstand. Her er hvad der lever inde i hver:

~/.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

Når du kører claude-work, læser Claude alt fra ~/.claude-work. Den ved ikke at ~/.claude eksisterer. De to instanser er fuldstændig uafhængige — du kan endda køre dem samtidigt i forskellige terminalfaner.

Skalering til N konti

Mønsteret udvides til et vilkårligt antal konti. Freelancer med flere kunder? Tilføj flere aliaser:

# 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'

Hvert alias får sin egen konfigurationsmappe, sin egen OAuth-session, sin egen CLAUDE.md med kundspecifikke instruktioner.

Praktiske tips

• Navngiv mapper tydeligt: ~/.claude-work, ~/.claude-clientname — du takker dig selv når der er tre eller fire
• Skriv tilpasset CLAUDE.md for hver: arbejds-CLAUDE.md kan inkludere virksomhedsspecifikke instruktioner (Jira-tickets, Slack-kanaler, deployment-procedurer). Den personlige forbliver slank.
• Forskellige MCP-servere per konto: konfigurer arbejdsværktøjer (Jira MCP, Slack MCP, interne API'er) kun i arbejdskonfigurationen. Hold din personlige ren.
• Tjek hvilken konto der er aktiv: kør claude config list i en session hvis du er i tvivl — viser stien til konfigurationsmappen

Hvor denne tilgang kommer til kort

CLAUDE_CONFIG_DIR isolerer per konto, ikke per projekt. Inde i en enkelt profil ser Claude hver MCP-server, du nogensinde har registreret for den konto — på tværs af alle dine projekter. Til ren personlig brug er det som regel fint. I det øjeblik du har flere produktionskritiske projekter under én konto, især i overlappende domæner som fakturering, adminværktøjer eller infrastruktur, introducerer det en konkret risiko mellem projekter: en AI-assistent kan kalde et værktøj fra projekt A, mens den arbejder på projekt B, særligt når begge eksponerer ensartet navngivne operationer.

Profilmønsteret besvarer spørgsmålet which account am I in?. Det besvarer ikke spørgsmålet which project's tools should be active right now?. Til arbejde med højere indsats, stabl et andet isolationslag ovenpå konto-opdelingen:

• Én profil per produktionskritisk projekt, ikke kun per konto: i stedet for ~/.claude og ~/.claude-work, opret ~/.claude-work-billing og ~/.claude-work-admin. Hver profil ser kun de MCP-servere, den faktisk har brug for.
• Projektspecifik MCP via .mcp.json: commit en .mcp.json i projektroden, der kun lister det projekts MCP-servere. Claude samler dem op, når den startes fra den mappe. Hold din globale konfiguration minimal — kun universelle værktøjer (noter, søgning), ingen produktionsendpoints.
• Navngiv MCP-servere utvetydigt: undgå generiske navne som admin, billing, mcp-server. Præfiks med projektet: acme_billing_prod, acme_admin_stage. Et beskrivende navn tvinger til en pause, når noget er ved at blive kaldt fra den forkerte kontekst.
• Gennemgå hvert MCP-værktøjskald inden godkendelse: kald som *_create_*, *_delete_*, *_charge_* fortjener et bevidst andet blik. Den hastighed du end vinder ved generel auto-godkendelse fordamper første gang et værktøj fra det forkerte projekt fyrer mod produktion.

Den generelle regel: opdel profiler aggressivt, hold produktionsklar MCP væk fra default-profilen, og behandl overlap i værktøjsnavne mellem projekter som en smell, der er værd at refaktorere.

Konklusion

Én miljøvariabel. Ét alias. Fuld isolation mellem konti. Ingen logout/login-dans, ingen konfigurationskonflikter, ingen kontekstlækage. Den slags løsning der er næsten skuffende simpel — men det er netop det der gør den god. Sæt op én gang og tænk aldrig på det igen.