Mehrere Claude Code Accounts auf einem Gerät

Ich nutze Claude Code täglich — für persönliche Projekte und für die Arbeit im Unternehmen. Das Problem: Das sind zwei völlig verschiedene Accounts mit unterschiedlichen OAuth-Sessions, unterschiedlichen CLAUDE.md-Anweisungen, unterschiedlichen MCP-Servern und getrenntem Projekt-Gedächtnis. So betreibe ich beides parallel auf einem Gerät mit einem einzigen Shell-Alias.

Das Problem

Claude Code speichert standardmäßig alles in ~/.claude — OAuth-Token, Gesprächsverlauf, globale CLAUDE.md, Projekt-Gedächtnis, MCP-Server-Konfigurationen und Einstellungen. Bei zwei Accounts brauchst du zwei vollständig getrennte Welten:

• Persönlicher Account: eigenes Max/Pro-Abo, persönliche CLAUDE.md mit deinen Präferenzen, deine MCP-Server (Obsidian, persönliche Tools)
• Firmen-Account: vom Unternehmen verwalteter Plan, Arbeits-CLAUDE.md mit Jira/Slack-Integrationsanweisungen, Firmen-MCP-Server
• Unterschiedliche OAuth-Sessions: du kannst nicht in zwei Accounts im selben Konfigurationsverzeichnis eingeloggt sein
• Getrenntes Projekt-Gedächtnis: Arbeitskontext soll nicht in persönliche Sessions und umgekehrt gelangen

Sich jedes Mal aus- und einloggen beim Kontextwechsel ist keine Option. Du verlierst den Session-Zustand, und es ist einfach mühsam.

Die Lösung: CLAUDE_CONFIG_DIR

Claude Code respektiert eine einzige Umgebungsvariable: CLAUDE_CONFIG_DIR. Setze sie auf einen beliebigen Pfad, und Claude nutzt dieses Verzeichnis statt ~/.claude für alles — Auth, Verlauf, Einstellungen, Gedächtnis. Das gesamte Setup dauert 60 Sekunden.

Schritt 1: Zweites Konfigurationsverzeichnis erstellen

Wähle einen Namen, der zu deinem Anwendungsfall passt:

mkdir ~/.claude-work

Das war's. Claude füllt es beim ersten Start mit der nötigen Struktur.

Schritt 2: Zweiten Account authentifizieren

Starte Claude einmal mit dem neuen Konfigurationsverzeichnis für den OAuth-Login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Der Browser öffnet sich. Logge dich mit dem Firmen-Account ein. Das OAuth-Token wird in ~/.claude-work gespeichert — vollständig getrennt von deiner persönlichen Session in ~/.claude.

Schritt 3: Shell-Alias hinzufügen

Füge dies zu deiner Shell-Konfiguration hinzu, damit du dir die Variable nicht merken musst:

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

Shell neu laden:

source ~/.zshrc

Was du bekommst

Jetzt hast du zwei vollständig isolierte Claude-Umgebungen:

• claude — startet mit persönlichem Account, persönlicher CLAUDE.md, persönlichem Gedächtnis
• claude-work — startet mit Firmen-Account, arbeitsspezifischer CLAUDE.md, separatem Gedächtnis
• Isolierter Verlauf: Arbeitsgespräche bleiben bei der Arbeit, Persönliches bleibt persönlich
• Getrennte MCP-Server: dein persönlicher Obsidian-Vault-MCP erscheint nicht in Arbeitssessions
• Unabhängige Einstellungen: verschiedene erlaubte Tools, verschiedene Berechtigungsstufen, verschiedene Modellpräferenzen pro Account

Wie es unter der Haube funktioniert

Das Konfigurationsverzeichnis ist die einzige Wahrheitsquelle für den Zustand von Claude Code. Hier ist, was in jedem lebt:

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

Wenn du claude-work ausführst, liest Claude alles aus ~/.claude-work. Es weiß nichts von der Existenz von ~/.claude. Die beiden Instanzen sind komplett unabhängig — du kannst sie sogar gleichzeitig in verschiedenen Terminal-Tabs laufen lassen.

Skalierung auf N Accounts

Das Muster lässt sich auf beliebig viele Accounts erweitern. Freelancer mit mehreren Kunden? Füge mehr Aliase hinzu:

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

Jeder Alias bekommt sein eigenes Konfigurationsverzeichnis, seine eigene OAuth-Session, seine eigene CLAUDE.md mit kundenspezifischen Anweisungen.

Praktische Tipps

• Verzeichnisse klar benennen: ~/.claude-work, ~/.claude-clientname — du wirst dir dankbar sein, wenn es drei oder vier davon gibt
• Eigene CLAUDE.md für jeden schreiben: die Arbeits-CLAUDE.md kann firmenspezifische Anweisungen enthalten (Jira-Tickets, Slack-Kanäle, Deployment-Prozeduren). Die persönliche bleibt schlank.
• Verschiedene MCP-Server pro Account: Arbeits-Tools (Jira MCP, Slack MCP, interne APIs) nur in der Arbeitskonfiguration. Persönliche Konfiguration sauber halten.
• Aktiven Account prüfen: claude config list in einer Session ausführen — zeigt den Pfad zum Konfigurationsverzeichnis

Wo dieser Ansatz an Grenzen stößt

CLAUDE_CONFIG_DIR isoliert nach Account, nicht nach Projekt. Innerhalb eines einzelnen Profils sieht Claude jeden MCP-Server, den du jemals für diesen Account registriert hast — über all deine Projekte hinweg. Für rein persönliche Nutzung ist das meist unproblematisch. Sobald aber mehrere produktionskritische Projekte unter einem Account liegen, besonders in überlappenden Domänen wie Billing, Admin-Tooling oder Infrastruktur, entsteht ein konkretes projektübergreifendes Risiko: Ein KI-Assistent kann ein Tool aus Projekt A aufrufen, während er an Projekt B arbeitet — gerade dann, wenn beide Projekte ähnlich benannte Operationen exponieren.

Das Profil-Pattern beantwortet die Frage which account am I in?. Es beantwortet nicht die Frage which project's tools should be active right now?. Bei höherem Risikoeinsatz solltest du eine zweite Isolationsschicht über die Account-Trennung legen:

• Ein Profil pro produktionskritischem Projekt, nicht nur pro Account: Statt ~/.claude und ~/.claude-work lege ~/.claude-work-billing und ~/.claude-work-admin an. Jedes Profil sieht nur die MCP-Server, die es wirklich braucht.
• Projektbezogenes MCP über .mcp.json: Commite eine .mcp.json im Projekt-Root, die nur die MCP-Server dieses Projekts auflistet. Claude lädt sie, wenn es aus diesem Verzeichnis gestartet wird. Halte deine globale Konfiguration minimal — nur universelle Tools (Notizen, Suche), keine Produktions-Endpunkte.
• MCP-Server eindeutig benennen: Vermeide generische Namen wie admin, billing, mcp-server. Präfixiere mit dem Projektnamen: acme_billing_prod, acme_admin_stage. Ein aussagekräftiger Name erzwingt ein kurzes Innehalten, wenn etwas im falschen Kontext aufgerufen werden soll.
• Jeden MCP-Tool-Call vor dem Approve prüfen: Aufrufe wie *_create_*, *_delete_*, *_charge_* verdienen einen bewussten zweiten Blick. Die Geschwindigkeit, die pauschales Auto-Approve bringt, verpufft beim ersten Mal, wenn ein Tool aus dem falschen Projekt in Produktion feuert.

Die allgemeine Regel: Trenne Profile aggressiv, halte produktionsreife MCP-Server aus dem Default-Profil heraus, und behandle Überschneidungen bei Tool-Namen zwischen Projekten als Smell, der Refactoring verdient.

Fazit

Eine Umgebungsvariable. Ein Alias. Vollständige Isolation zwischen Accounts. Kein Logout/Login-Tanz, keine Konfigurationskonflikte, kein Kontextleck. Die Art von Lösung, die fast enttäuschend einfach ist — aber genau das macht sie gut. Einmal einrichten und nie wieder daran denken.