So nutzt du mehrere Claude Code Accounts gleichzeitig

Ein Terminal, zwei Leben

Claude Code ist gerade das Werkzeug, das viele Entwicklerinnen und Entwickler neu fasziniert. Ein paar Tastendrücke im Terminal, und es läuft ein zweiter Kopf am Projekt mit – einer, der die Codebase kennt, den Build startet, Tests fährt und PRs aufräumt, während man selbst am eigentlichen Problem arbeitet. Der Hype ist entsprechend groß, und genau deshalb lohnt sich ein genauer Blick auf die Themen, die im Alltag mit dem Werkzeug schnell auftauchen.

Eines davon ist das Konto-Thema. Ein Account reicht vielen Nutzerinnen und Nutzern nach kurzer Zeit nicht mehr: eine Nutzungsgrenze für private Experimente, eine zweite für berufliche Kontexte. Oder zwei Team-Accounts, weil ein Kunde sein eigenes Claude-Abo stellt und sein Kontingent nicht mit projektfremden Aufgaben verbraucht werden soll. Der naheliegende Reflex ist, sich ständig aus- und wieder einzuloggen – und genau das kostet Zeit und Nerven.

Zum Glück ist die Lösung kein Hack, sondern in Claude Code sauber vorgesehen. Die Umgebungsvariable CLAUDE_CONFIG_DIR erlaubt mehrere vollständig getrennte Profile auf einer Maschine, die sich im selben Terminal parallel nutzen lassen. Das funktioniert sowohl unter macOS als auch unter Windows – die Schritte unterscheiden sich nur in Nuancen. Wir zeigen beide Wege, die Stolperfallen dazu und warum das Setup in vielen Arbeitskontexten Sinn ergibt.

Warum sich mehrere Profile lohnen

Es gibt drei gute Gründe, sich mit dem Mehrkonto-Thema zu beschäftigen – und keiner davon ist „das fühlt sich technischer an".

Trennung von privat und beruflich. Ein Claude-Pro-Account gehört in der Regel einer Person, ein Team-Account gehört einem Unternehmen. Beides im selben Profil zu mischen, heißt, dass Konversationen, Einstellungen und eventuelle Kundeninhalte durcheinanderlaufen. Sauber getrennt sieht jeder Kontext nur seine eigene Historie, und private Shell-Befehle, Notizen oder Testläufe landen nicht im beruflichen Profil.

Nutzungskontingente. Claude Pro und Claude Max haben pro Account klare Nutzungsgrenzen. Wer den ganzen Tag intensiv in einer Terminal-Session arbeitet, rennt irgendwann in das Limit – und bleibt dann bis zum nächsten Reset stehen. Mit einem zweiten Profil wechselt man das Fenster und arbeitet weiter, statt eine Stunde zu warten. Das klingt banal, verändert aber den Umgang mit dem Werkzeug grundlegend.

Unternehmen mit eigenen Abos. Viele Unternehmen stellen inzwischen eigene KI-Tokens für Dienstleister oder freie Mitarbeiter bereit – aus Compliance-Gründen, aus Abrechnungsgründen oder weil im Unternehmen ohnehin eine Anthropic-Enterprise-Lizenz liegt. In solchen Konstellationen ist es sauberer, nicht den privaten Account zu nutzen, sondern projektspezifisch zwischen Zugängen zu wechseln.

Was CLAUDE_CONFIG_DIR eigentlich macht

Unter der Haube ist das Setup weniger magisch, als es klingt. Claude Code legt all seinen Zustand – Login-Token, Einstellungen, Konversationshistorie, MCP-Konfiguration – in einem einzigen Ordner ab: ~/.claude/. Dazu kommt die Datei ~/.claude.json, in der kleinere Konfigurationswerte liegen.

Die Umgebungsvariable CLAUDE_CONFIG_DIR sagt dem Programm schlicht: „Benutze stattdessen einen anderen Ordner." Setzen wir sie vor dem Aufruf, arbeitet Claude Code auf einem komplett getrennten State – anderer Login, andere Historie, eigenes Kontingent. Der ursprüngliche Ordner bleibt davon vollkommen unberührt.

Das ist keine inoffizielle Lücke, sondern der saubere Weg, den Anthropic in der Dokumentation vorsieht. Wer das einmal verstanden hat, kann nicht nur zwei, sondern beliebig viele Profile parallel betreiben – pro Kontext eines, pro Projekt eines, pro Maschine eines. In Communitys wie Reddit oder auf Hacker News liest man regelmäßig von Setups mit drei oder vier Profilen: ein privates, eines fürs Tagesgeschäft, eines für Experimente mit neuen MCP-Servern, die erst freigegeben werden, wenn sie stabil laufen.

Das Setup auf dem Mac – Schritt für Schritt

Das Vorgehen ist unter macOS schnell erklärt und funktioniert sowohl unter der Standard-zsh als auch unter bash. Ausgangspunkt: Ein Account ist bereits eingeloggt und Claude Code startet ganz normal via claude.

Bestehenden Account sichern. Zuerst kopieren wir den aktuellen State in ein benanntes Profil, damit der Login nicht verloren geht, wenn wir gleich den Account wechseln.

cp -r ~/.claude ~/.claude-profil1
cp ~/.claude.json ~/.claude-profil1.json

Abmelden und mit zweitem Account einloggen. Jetzt loggt man den aktuellen Account aus und meldet sich ganz normal mit dem zweiten an. Der Browser öffnet sich automatisch, man authentifiziert sich wie beim ersten Setup.

claude /logout
claude /login

Zweiten Account ebenfalls sichern. Nach dem erfolgreichen Login liegt jetzt der State des zweiten Accounts in ~/.claude/. Den sichern wir ebenfalls in ein eigenes Profil.

cp -r ~/.claude ~/.claude-profil2
cp ~/.claude.json ~/.claude-profil2.json

Ab hier gibt es zwei vollständig getrennte Profile auf der Maschine. Der Ordner ~/.claude/ selbst bleibt als „zuletzt benutzt" erhalten und ändert sich, je nachdem, mit welchem Account man arbeitet.

Aliase als Abkürzung

Jedes Mal die Umgebungsvariable vor claude zu setzen, wird schnell anstrengend. Wir richten deshalb zwei Kurzbefehle ein – claude1 und claude2 –, die direkt das jeweilige Profil ansteuern. Für die Standard-zsh sieht das so aus:

cat <<'EOF' >> ~/.zshrc

# Claude Code Profile
alias claude1='CLAUDE_CONFIG_DIR=~/.claude-profil1 claude'
alias claude2='CLAUDE_CONFIG_DIR=~/.claude-profil2 claude'
EOF

source ~/.zshrc

Wer noch mit bash arbeitet, ersetzt .zshrc durch .bash_profile. Die Prüfung, welche Shell aktiv ist, übernimmt echo $SHELL.

Ab jetzt startet claude1 immer das erste Profil, claude2 immer das zweite. Der unqualifizierte Befehl claude funktioniert weiterhin und nutzt den Standard-Ordner ~/.claude/. Sinnvoll ist, die Profile später in etwas Sprechendes umzubenennen – etwa claude-privat und claude-arbeit – und den Profilnamen gleich als Bestandteil der Shell-Prompt anzeigen zu lassen, damit man im Stress nicht aus Versehen im falschen Fenster arbeitet.

Das Setup unter Windows

Auf Windows-Rechnern gibt es zwei sinnvolle Wege, und welcher der richtige ist, hängt davon ab, wie Claude Code installiert wurde.

Variante 1: WSL (Windows Subsystem for Linux). Wer Claude Code über WSL (Ubuntu, Debian oder eine andere Distribution) installiert hat, arbeitet faktisch in einer Linux-Umgebung. Das Setup ist dann identisch zum Mac – alle oben gezeigten Befehle laufen unverändert in der WSL-Shell. Auch die ~/.claude-Ordner liegen innerhalb der WSL-Home, nicht auf dem Windows-Dateisystem. Wer sich unsicher ist, welcher Weg besser ist: WSL ist unter Windows der von vielen Nutzerinnen und Nutzern bevorzugte Weg, weil Claude Code ursprünglich für Unix-Shells gebaut wurde und sich in diesem Umfeld am robustesten verhält.

Variante 2: PowerShell nativ. Wer Claude Code direkt unter Windows in der PowerShell nutzt, muss ein paar Befehle übersetzen. Die Logik bleibt dieselbe – nur die Syntax ist anders. Ausgangspunkt ist auch hier ein bereits eingeloggter Account.

Bestehenden Account sichern:

Copy-Item -Recurse $HOME\.claude $HOME\.claude-profil1
Copy-Item $HOME\.claude.json $HOME\.claude-profil1.json

Abmelden und mit zweitem Account einloggen:

claude /logout
claude /login

Zweiten Account ebenfalls sichern:

Copy-Item -Recurse $HOME\.claude $HOME\.claude-profil2
Copy-Item $HOME\.claude.json $HOME\.claude-profil2.json

Für die Kurzbefehle legt man unter PowerShell keine Aliase an, sondern kleine Funktionen, weil die Umgebungsvariable vor dem Aufruf gesetzt werden muss. Dazu öffnet man das PowerShell-Profil, damit die Funktionen bei jedem Start automatisch geladen werden:

notepad $PROFILE

Sollte die Datei noch nicht existieren, fragt Windows einmalig nach, ob sie angelegt werden soll. In das Profil kommen diese Zeilen:

# Claude Code Profile
function claude1 { $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-profil1"; claude @args }
function claude2 { $env:CLAUDE_CONFIG_DIR = "$HOME\.claude-profil2"; claude @args }

Speichern, PowerShell schließen und neu öffnen – anschließend funktionieren claude1 und claude2 genau wie auf dem Mac. Sollte Windows beim ersten Start des Profils klagen, dass die Ausführung von Skripten blockiert ist, lässt sich das einmalig mit Set-ExecutionPolicy -Scope CurrentUser RemoteSigned freischalten.

Kurzer Hinweis zur Namenswahl. Die Profilordner können heißen, wie man möchte – .claude-profil-1, .claude-privat oder .claude-work sind alle erlaubt. Bei Alias- und Funktionsnamen gilt unter zsh und bash dasselbe. PowerShell erwartet bei Funktionen dagegen ein Verb-Noun-Muster. Namen mit Bindestrich funktionieren dort zwar, werfen aber eine gelbe Warnung beim Laden des Profils – wer die vermeiden will, bleibt bei claude1 und claude2.

Was passiert, wenn ein Login abläuft

Nach ein paar Wochen läuft gelegentlich ein Token aus. Claude Code merkt das selbst und fordert zum Re-Login auf. Wichtig: Wer einfach claude /login tippt, loggt sich im Standardprofil neu ein – nicht unbedingt in dem Profil, in dem der Fehler aufgetreten ist. Der gezielte Weg ist deshalb auf macOS und Linux:

CLAUDE_CONFIG_DIR=~/.claude-profil1 claude /login

Unter PowerShell entsprechend:

$env:CLAUDE_CONFIG_DIR = "$HOME\.claude-profil1"; claude /login

Funktional tun claude1 /login bzw. die PowerShell-Funktion dasselbe – der Alias expandiert intern ja genau zu diesem Befehl. Die explizite Schreibweise hat nur einen praktischen Vorteil: Man sieht im Terminal schwarz auf weiß, welches Profil gerade neu eingeloggt wird. Bei mehr als zwei Profilen hilft das, Verwechslungen auszuschließen.

Wo die Grenzen liegen

So praktisch das Setup ist, es löst nicht alles.

Die Profile teilen sich die installierte Version von Claude Code. Wer zwischen stabiler und Beta-Version wechseln will, braucht dafür eine zweite Installation – das ist eine andere Baustelle als das Account-Switching.

Die CLAUDE.md im Projektordner wird von allen Profilen gelesen, weil sie Teil des Projekts ist, nicht des Accounts. Das ist fast immer gewollt – die Projektkonventionen gelten ja für beide Nutzer – aber wer sich ansatzweise paranoid machen will, sollte bewusst prüfen, dass in CLAUDE.md keine accountspezifischen Informationen landen. Keine privaten API-Keys, keine internen URLs, keine Tokens.

Und: Wer ein gemischtes Team mit macOS- und Windows-Rechnern hat, sollte das gewählte Setup im Onboarding-Dokument festhalten. Wer unter Windows zwischen WSL und PowerShell springt, arbeitet sonst schnell an zwei völlig verschiedenen Profil-Ordnern vorbei.

Fazit

Wer Claude Code in mehr als einem Kontext nutzt, sollte das Multi-Profil-Setup nicht als Luxus, sondern als Hygiene betrachten. Der Einrichtungsaufwand liegt bei zehn Minuten einmalig, der Gewinn in Fokus, Sauberkeit und Planbarkeit ist deutlich höher. Wer im Auftrag eines Unternehmens arbeitet oder mit fremden Tokens hantiert, umgeht damit außerdem Compliance-Fragen, die sonst gerne unter den Tisch fallen.

Für Einsteiger gilt: Fang mit einem Profil an, lerne das Werkzeug kennen, und richte dir das zweite Profil in dem Moment ein, in dem du zum ersten Mal denkst „Mist, jetzt müsste ich mich kurz ausloggen". Spätestens dann lohnt sich die Viertelstunde Setup garantiert.

Und für alle, die KI im eigenen Unternehmen sinnvoll einsetzen wollen, jenseits des einzelnen Entwickler-Terminals: Da, wo LLMs in Produkte, Prozesse oder Kundenschnittstellen eingebaut werden, geht es um mehr als Account-Setups. Wenn bei euch gerade die Frage aufkommt, wie ein seriöser KI-Einsatz jenseits des Hypes aussehen könnte – von der strategischen Einordnung über Datenschutz bis zur technischen Integration – sprecht uns gerne an. Wir beraten Unternehmen, die KI mit klarem Kopf angehen wollen statt mit Buzzword-Bingo.