Flere Claude Code-kontoer på én enhet

Jeg bruker Claude Code daglig — for personlige prosjekter og for jobb. Problemet: det er to helt forskjellige kontoer med ulike OAuth-sesjoner, ulike CLAUDE.md-instruksjoner, ulike MCP-servere og separat prosjektminne. Slik kjører jeg dem parallelt på én enhet med ett enkelt shell-alias.

Problemet

Claude Code lagrer alt i ~/.claude som standard — OAuth-token, samtalehistorikk, global CLAUDE.md, prosjektminne, MCP-serverkonfigurasjoner og innstillinger. Med to kontoer trenger du to helt adskilte verdener:

• Personlig konto: eget Max/Pro-abonnement, personlig CLAUDE.md med dine preferanser, dine MCP-servere (Obsidian, personlige verktøy)
• Bedriftskonto: bedriftsplan, arbeids-CLAUDE.md med Jira/Slack-integrasjonsinstruksjoner, bedriftens MCP-servere
• Ulike OAuth-sesjoner: du kan ikke være logget inn på to kontoer i samme konfigurasjonskatalog
• Separat prosjektminne: du vil ikke at arbeidskontekst lekker inn i personlige sesjoner og vice versa

Å logge ut og inn hver gang du bytter kontekst er ikke et alternativ. Du mister sesjonstilstanden, og det er rett og slett smertefullt.

Løsningen: CLAUDE_CONFIG_DIR

Claude Code respekterer én enkelt miljøvariabel: CLAUDE_CONFIG_DIR. Sett den til hvilken som helst bane, og Claude bruker den katalogen istedenfor ~/.claude for alt — auth, historikk, innstillinger, minne. Hele oppsettet tar 60 sekunder.

Steg 1: Opprett en andre konfigurasjonskatalog

Velg et navn som passer ditt brukstilfelle:

mkdir ~/.claude-work

Ferdig. Claude fyller den med nødvendig struktur ved første oppstart.

Steg 2: Autentiser den andre kontoen

Kjør Claude én gang med den nye konfigurasjonskatalogen for å trigge OAuth-innlogging:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Nettleseren åpnes. Logg inn med bedriftskontoen. OAuth-tokenet lagres i ~/.claude-work — helt adskilt fra din personlige sesjon i ~/.claude.

Steg 3: Legg til et shell-alias

Legg dette til i shell-konfigurasjonen din så du slipper å huske variabelen:

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

Last inn shell på nytt:

source ~/.zshrc

Hva du får

Nå har du to helt isolerte Claude-miljøer:

• claude — starter med personlig konto, personlig CLAUDE.md, personlig minne
• claude-work — starter med bedriftskonto, arbeidsspesifikk CLAUDE.md, separat minne
• Isolert historikk: arbeidssamtaler forblir i arbeid, personlige forblir personlige
• Separate MCP-servere: din personlige Obsidian vault MCP vises ikke i arbeidssesjoner
• Uavhengige innstillinger: ulike tillatte verktøy, ulike tilgangsnivåer, ulike modellpreferanser per konto

Hvordan det fungerer under panseret

Konfigurasjonskatalogen er den eneste sannhetskilden for Claude Codes tilstand. Her er hva som lever inni 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 kjører claude-work, leser Claude alt fra ~/.claude-work. Den vet ikke at ~/.claude eksisterer. De to instansene er helt uavhengige — du kan til og med kjøre dem samtidig i ulike terminalfaner.

Skalering til N kontoer

Mønsteret utvides til et vilkårlig antall kontoer. Frilanser med flere kunder? Legg til flere alias:

# 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 konfigurasjonskatalog, sin egen OAuth-sesjon, sin egen CLAUDE.md med kundespesifikke instruksjoner.

Praktiske tips

• Navngi kataloger tydelig: ~/.claude-work, ~/.claude-clientname — du takker deg selv når det er tre eller fire
• Skriv tilpasset CLAUDE.md for hver: arbeids-CLAUDE.md kan inkludere bedriftsspesifikke instruksjoner (Jira-tickets, Slack-kanaler, deployment-prosedyrer). Den personlige forblir slank.
• Ulike MCP-servere per konto: konfigurer arbeidsverktøy (Jira MCP, Slack MCP, interne API-er) kun i arbeidskonfigurasjonen. Hold din personlige ren.
• Sjekk hvilken konto som er aktiv: kjør claude config list i en sesjon om du er usikker — viser banen til konfigurasjonskatalogen

Der denne tilnærmingen ikke strekker til

CLAUDE_CONFIG_DIR isolerer per konto, ikke per prosjekt. Inne i én enkelt profil ser Claude hver MCP-server du noen gang har registrert for den kontoen — på tvers av alle prosjektene dine. For ren personlig bruk er det som regel greit. I det øyeblikket du har flere produksjonskritiske prosjekter under én konto, særlig i overlappende domener som fakturering, adminverktøy eller infrastruktur, introduserer det en konkret risiko mellom prosjekter: en KI-assistent kan kalle et verktøy fra prosjekt A mens den jobber med prosjekt B, spesielt når begge eksponerer likt navngitte operasjoner.

Profilmønsteret svarer på spørsmålet which account am I in?. Det svarer ikke på spørsmålet which project's tools should be active right now?. For arbeid med høyere innsats, stable et nytt isolasjonslag oppå konto-delingen:

• Én profil per produksjonskritisk prosjekt, ikke bare per konto: istedenfor ~/.claude og ~/.claude-work, opprett ~/.claude-work-billing og ~/.claude-work-admin. Hver profil ser bare de MCP-serverne den faktisk trenger.
• Prosjekt-scope MCP via .mcp.json: commit en .mcp.json i prosjektroten som lister bare det prosjektets MCP-servere. Claude plukker dem opp når den startes fra den katalogen. Hold den globale konfigurasjonen minimal — bare universelle verktøy (notater, søk), ingen produksjonsendepunkter.
• Navngi MCP-servere utvetydig: unngå generiske navn som admin, billing, mcp-server. Prefiks med prosjektet: acme_billing_prod, acme_admin_stage. Et beskrivende navn tvinger fram en pause når noe er i ferd med å bli kalt fra feil kontekst.
• Gå gjennom hvert MCP-verktøyskall før godkjenning: kall som *_create_*, *_delete_*, *_charge_* fortjener et bevisst andre blikk. Hvilken hastighet du enn vinner på generell auto-godkjenning fordamper første gang et verktøy fra feil prosjekt avfyres mot produksjon.

Den generelle regelen: del opp profiler aggressivt, hold produksjonsklar MCP unna default-profilen, og behandle overlapp i verktøysnavn mellom prosjekter som en smell verdt å refaktorere.

Konklusjon

Én miljøvariabel. Ett alias. Full isolasjon mellom kontoer. Ingen logout/login-dans, ingen konfigurasjonskonflikter, ingen kontekstlekkasje. Den typen løsning som er nesten skuffende enkel — men det er nettopp det som gjør den god. Sett opp én gang og tenk aldri på det igjen.