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.

Diagramm, wie Claude Code sein Konto auflöst: Die Umgebungsvariable CLAUDE_CONFIG_DIR zeigt auf ein einziges Verzeichnis mit credentials.json, Sitzungs-Metadaten und Projekthistorie und fällt auf ~/.claude zurück, wenn die Variable nicht gesetzt ist.

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.

Vergleichsdiagramm: links die Auswahl des Claude Code-Kontos über das Exportieren von CLAUDE_CONFIG_DIR in jedem einzelnen Terminal, wobei ein drittes Terminal keinerlei sichtbaren Hinweis darauf gibt, welches Konto gerade aktiv ist. Rechts das fest an das Projekt gebundene Konto mit einem Override pro Agent, das beim Start des Agenten automatisch aufgelöst wird.

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.

Diagramm der vierstufigen Auflösungsreihenfolge für Konten: Ein Override auf Agentenebene schlägt die feste Zuordnung des Projekts, diese schlägt den Standard der Anwendung, der wiederum auf das Standardverzeichnis des Systems ~/.claude zurückfällt.

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.

KostenlosAgentsRoom herunterladen

Companion-App: Agenten auch unterwegs im Blick behalten

Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen AI-Anbieter.

Erweiterung installieren
Chrome Web Store

Bugs und Wünsche direkt in dein öffentliches Backlog schicken.

Ein Blick auf AgentsRoom in Aktion.

Multi-Projekte
Multi-Provider
Multi-Agenten
Live-Status
Diff & Commit
Mobile App
Live-Vorschau
Agent-Teams
Browser-Tests
Backlog-getriebene Entwicklung
Prompt-Bibliothek
Skills-Bibliothek
Alle Funktionen ansehen

Weiterlesen