Claude Code hält immer nur einen Login aktiv. So nutzen Sie mehrere Konten parallel.
Ein Praxisleitfaden für den Parallelbetrieb eines Arbeitskontos und eines privaten Kontos auf derselben Maschine: die eine Umgebungsvariable, die entscheidet, welcher Login aktiv ist, warum der Weg über die shell ab dem dritten Terminal scheitert, und wie Sie ein Konto fest an ein Projekt binden.
Es gibt einen Moment, den fast jeder erlebt, der Claude Code sowohl beruflich als auch für eigene Projekte einsetzt. Sie beenden eine Arbeitssitzung, wechseln zu einem Nebenprojekt und merken, dass der Agent immer noch mit dem Konto angemeldet ist, das Ihr Arbeitgeber bezahlt. Also melden Sie sich ab, melden sich mit Ihrem eigenen Konto wieder an, und eine halbe Stunde später steht dasselbe in umgekehrter Richtung an.
Diese Schleife ist kein fehlendes Feature. Sie ist eine Folge davon, wo Claude Code seinen Login ablegt. Und sobald Sie wissen, wo das ist, wird der Parallelbetrieb mehrerer Konten zu einem Konfigurationsdetail statt zu einem Workflow-Problem.
Eine einzige Umgebungsvariable entscheidet, welches Konto aktiv ist
Claude Code speichert Anmeldedaten weder in einer Datenbank noch in einem Keyring-Eintrag pro Profil. Alles, was es braucht, liest es aus einem einzigen Verzeichnis: Anmeldedaten, Sitzungs-Metadaten und die Historie pro Projekt.
Dieses Verzeichnis ist das, worauf CLAUDE_CONFIG_DIR zeigt. Wenn Sie die Variable nie setzen, ist es ~/.claude.

Das ist der gesamte Mechanismus, und er hat eine nützliche Eigenschaft: Weil ein Konto ein Verzeichnis ist und keine globale Einstellung, bedeuten zwei Konten schlicht zwei Verzeichnisse. Zwischen ihnen wird nichts geteilt. Beide bleiben unbegrenzt angemeldet, und keines weiß, dass das andere existiert.
Die naive Variante funktioniert also:
# privat
CLAUDE_CONFIG_DIR=~/.claude claude
# beruflich
CLAUDE_CONFIG_DIR=~/.claude-work claude
Führen Sie im zweiten Verzeichnis einmal /login aus, und Sie haben zwei aktive Konten auf einer Maschine.
Wo der Weg über die shell anfängt, weh zu tun
Die zweizeilige Variante oben ist völlig in Ordnung, solange Sie immer nur ein Terminal offen haben und diszipliniert bleiben. Sie hört aus drei Gründen auf, in Ordnung zu sein, und die Gründe verstärken sich gegenseitig.
Die Variable gilt pro Prozess, nicht pro Maschine. Jedes neue Terminal, jedes neue Pane, jede in den Editor integrierte shell startet mit dem Standardwert aus Ihrem Profil. Exportieren Sie sie in .zshrc, haben Sie das Problem nur verschoben: Jetzt ist das andere Konto dasjenige, das Sie ständig vergessen.
Nichts zeigt Ihnen, welches Konto gerade aktiv ist. Claude Code gibt das Konto nicht im Prompt aus. Wenn Sie zwei Terminals offen haben und eines davon auf dem Arbeitskonto läuft, sehen beide identisch aus. Der Moment, in dem es Ihnen auffällt, ist meistens der Moment, in dem Sie die Abrechnung prüfen.
Es überlebt keine Parallelität. Die interessanten Setups führen mehrere Agenten gleichzeitig aus, auf mehreren Projekten. Ab der dritten gleichzeitigen Sitzung ist die Frage, welches Pane mit welcher Variable gestartet wurde, kein Disziplinproblem mehr, sondern ein Designproblem.

Die Lösung ist nicht noch mehr shell. Die Lösung besteht darin, die Entscheidung nicht länger beim Start zu treffen, sondern das Konto an das zu binden, was es tatsächlich bestimmt: das Projekt.
Binden Sie das Konto an das Projekt, nicht an das Terminal
Was Sie normalerweise wollen, ist eine Regel, kein Befehl. Etwa: Das Repository dieses Kunden läuft immer auf dem Konto dieses Kunden. Sobald diese Regel existiert, muss sich niemand mehr etwas merken.
Das sauber umzusetzen bedeutet, das Konto in einer definierten Reihenfolge aufzulösen, denn die Regel braucht Ausnahmen. Ein projektweiter Standard passt meistens, aber ein bestimmter Agent muss vielleicht woanders laufen: ein Wegwerf-Experiment auf einem Testkonto oder ein Review-Agent auf einem Platz mit größerem Kontingent.

Von oben gelesen gewinnt die erste Regel, die zutrifft. Ein Override auf Agentenebene schlägt die Zuordnung des Projekts. Die Zuordnung des Projekts schlägt den allgemeinen Standard, den Sie gesetzt haben. Ist nirgends etwas konfiguriert, landen Sie bei ~/.claude, also genau dort, wo eine frische Installation ohnehin landet. Dieser letzte Fallback ist wichtig: Er bedeutet, dass das Hinzufügen zu einem bestehenden Setup nichts verändert, solange Sie nicht ausdrücklich etwas zuordnen.
Das ist das Modell, das AgentsRoom umsetzt. Jedes Konto ist ein verwaltetes Verzeichnis, die Anmeldung passiert in der App statt in einer shell, und die oben beschriebene Auflösung läuft beim Start eines Agenten und setzt CLAUDE_CONFIG_DIR nur für diesen einen Prozess. Wenn Sie bereits einen Switcher eines Drittanbieters wie CCS nutzen, können Sie ein Konto auf ein vorhandenes Profilverzeichnis zeigen lassen, statt sich erneut anzumelden.
Dasselbe Problem gibt es bei Codex, nur mit einer anderen Variable
Wenn Sie mehr als einen Provider einsetzen, trifft Sie das zweimal. Die Form ist identisch, die Variable nicht, deshalb deckt ein Switcher, der für den einen gebaut wurde, den anderen nicht ab. Die Codex-Seite dokumentieren wir separat unter Multi-Konto für Codex, samt der Unterschiede im Anmeldeablauf.
Der allgemeine Punkt ist es wert, einmal ausgesprochen zu werden: Konto-Isolation ist ein Mechanismus pro Provider. Jedes Tool, das behauptet, das global zu lösen, kapselt entweder jeden Provider einzeln oder unterstützt nur einen.
Wissen, welches Konto tatsächlich Tokens verbrennt
Konten zu trennen ist nur die halbe Motivation. Die andere Hälfte ist zu wissen, wo der Verbrauch landet, besonders wenn ein Kunde dafür zahlt.
Genau das bricht beim Weg über die shell still und leise. Auswertungen, die nur auf ~/.claude schauen, melden zu wenig, sobald ein Agent woanders läuft, und die Zahlen wirken plausibel genug, dass es wochenlang niemandem auffällt. Eine kontobewusste Auswertung muss über jedes konfigurierte Verzeichnis iterieren, nicht nur über das Standardverzeichnis.
Wenn Sie Zahlen pro Konto und pro Sitzung wollen: Die Messseite haben wir in wie man die Token-Nutzung von Claude Code überprüft behandelt, und die Live-Ansicht finden Sie auf der Seite zur Token-Nutzung.
Wofür das nicht gedacht ist
Eine Klarstellung, weil die Frage aufkommt und eine gerade Antwort verdient statt Schweigen.
Alles oben dreht sich darum, Konten zu trennen, die ohnehin legitim existieren. Ein Platz, den Ihr Arbeitgeber bezahlt, und ein privates Abonnement, das Sie selbst bezahlen, sind zwei verschiedene Geschäftsbeziehungen, und beide ohne gegenseitige Kontamination auf einer Maschine zu halten, ist ein echter, ganz gewöhnlicher Bedarf. Genauso legitim ist es, die Tokens eines Kunden diesem Kunden in Rechnung zu stellen, oder ein Experimentierkonto von einem Produktionskonto fernzuhalten.
Zusätzliche Konten anzulegen, um die Kapazitätsgrenzen des Tarifs zu umgehen, in dem Sie sich befinden, ist etwas völlig anderes, und genau darauf zielen die Nutzungsrichtlinien. Der hier beschriebene Mechanismus macht das nicht akzeptabel, und ein Tool, das so etwas automatisieren würde, würde Ihnen dabei helfen, eine von Ihnen unterschriebene Vereinbarung zu brechen. Wenn Ihr zweites Konto existiert, weil jemand anderes dafür zahlt, stehen Sie auf sicherem Boden. Wenn es existiert, um ein Rate-Limit zurückzusetzen, nicht. Maßgeblich sind die Nutzungsrichtlinien von Anthropic, nicht dieser Artikel.
Fragen, die wirklich gestellt werden
Kann ich zwei Claude Code-Konten auf demselben Computer nutzen?
Ja. Claude Code liest seine Anmeldedaten, die Sitzungs-Metadaten und die Projekthistorie aus dem Verzeichnis, auf das CLAUDE_CONFIG_DIR zeigt, standardmäßig also aus ~/.claude. Lassen Sie diese Variable auf ein zweites Verzeichnis zeigen und melden Sie sich dort an, dann haben Sie zwei unabhängige Konten auf derselben Maschine. Zwischen den beiden Verzeichnissen wird nichts geteilt, beide bleiben also gleichzeitig angemeldet.
Wie wechsle ich zwischen Claude Code-Konten, ohne mich abzumelden?
Sie melden sich gar nicht ab. Abmelden und neu anmelden nutzt dasselbe Verzeichnis, Sie verlieren also die erste Sitzung, um die zweite zu bekommen. Geben Sie stattdessen jedem Konto sein eigenes Konfigurationsverzeichnis und wählen Sie zwischen ihnen aus, indem Sie beim Start der CLI CLAUDE_CONFIG_DIR setzen. Beide Anmeldedaten bleiben auf der Festplatte gültig, und der Wechsel kostet nichts.
Wo speichert Claude Code seinen Login?
In dem Verzeichnis, auf das CLAUDE_CONFIG_DIR zeigt, also in ~/.claude, solange Sie daran nichts ändern. Die Anmeldedaten selbst landen in einer Datei .credentials.json in diesem Verzeichnis, direkt neben den Sitzungs-Metadaten und der Historie pro Projekt. Dieses eine Verzeichnis ist das ganze Konto, und genau deshalb ist der Austausch ein sauberer Wechsel und kein Hack.
Können zwei Agenten gleichzeitig auf zwei verschiedenen Claude-Konten laufen?
Ja, solange jeder Agentenprozess sein eigenes CLAUDE_CONFIG_DIR in seiner Umgebung bekommt. Die Variable wird pro Prozess beim Start gelesen, nicht global, deshalb laufen zwei mit unterschiedlichen Werten gestartete Agenten parallel auf zwei verschiedenen Konten. Genau das macht ein berufliches und ein privates Projekt im selben Fenster nutzbar.
Verstößt es gegen die Bedingungen von Anthropic, mehr als ein Claude-Konto zu haben?
Getrennte Konten für getrennte Zwecke zu halten, ist völlig normal: Ein Platz, den Ihr Arbeitgeber bezahlt, und ein privates Abonnement, das Sie selbst bezahlen, sind zwei verschiedene Geschäftsbeziehungen. Worauf die Nutzungsrichtlinien zielen, ist das Anlegen von Konten, um die Kapazitätsgrenzen des eigenen Tarifs zu umgehen. Wenn Ihr zweites Konto existiert, weil jemand anderes dafür zahlt, stehen Sie auf sicherem Boden. Wenn es existiert, um ein Rate-Limit zurückzusetzen, nicht. Maßgeblich sind die Nutzungsrichtlinien von Anthropic.
Die Kurzfassung
Claude Code speichert ein Konto als Verzeichnis, und CLAUDE_CONFIG_DIR entscheidet, welches davon aktiv ist. Zwei Verzeichnisse bedeuten zwei Konten, dauerhaft angemeldet, ohne dass zwischen ihnen etwas geteilt wird.
Die Variante über die shell funktioniert, bis Sie mehr als ein Terminal offen haben. Danach wollen Sie, dass das Konto eine Eigenschaft des Projekts ist, mit einem Override pro Agent für die Ausnahmen, damit beim Start die richtigen Anmeldedaten gesetzt werden und sich niemand mehr etwas merken muss.
AgentsRoom herunterladen
Führe deine KI-Agenten (Claude, Codex, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code) auf all deinen Projekten aus, von einem einzigen Fenster.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen AI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.
Weiterlesen
Wie man KI-Coding-Agenten in einem Entwicklerteam skalieren kann
Ein Entwickler mit einem Coding-Agenten ist eine Produktivitätsgeschichte. Fünf Entwickler mit zwanzig Agenten sind ein Koordinationsproblem. Hier ist, was zuerst bricht, wenn ein Team wächst, und das Setup, das funktioniert: engagierte Kontextdateien, klare Dateieigentümerschaft, Überprüfung nach Blast-Radius und Kosten, die man tatsächlich sehen kann.
Zum ArtikelDie besten Gedächtnislösungen für Ihre Claude KI-Agenten im Jahr 2026
CLAUDE.md, mem0, Letta, Zep, basic-memory, Obsidian plus MCP, AgentsRoom Projekt Gedächtnis: eine ehrliche Übersicht über die Gedächtnisoptionen für KI-Coding-Agenten und wie man eine auswählt.
Zum ArtikelEin Feedback-Board für KI-Agenten: Lass deine Nutzer den Prompt schreiben
Feedback-Tools sammeln Wünsche. Bauen kann keins davon. Wenn das Board, in das deine Nutzer schreiben, dasselbe Board ist, aus dem deine Coding-Agenten arbeiten, fällt das Neuschreiben einfach weg.
Zum Artikel