Claude Code mit mehreren KI-Agenten: kompletter Workflow

Wenn mehrere Claude-Code-Sitzungen dieselben Dateien bearbeiten, entstehen schnell Überschreibungen, unklare Branches und schwer nachvollziehbare Merge-Konflikte.

Der zuverlässigste Weg für Claude Code mit mehreren KI-Agenten ist: Subagents für Recherche und klar abgegrenzte Nebenaufgaben, eigene Git Worktrees für parallele Änderungen, automatisierte Tests nach jedem Arbeitsschritt und eine zentrale manuelle Zusammenführung. Agent Teams oder Agent View eignen sich für die Koordination mehrerer Sitzungen, ersetzen aber weder Dateiisolation noch Code-Review.

Diese Anleitung richtet sich an Entwickler, die bereits Claude Code im Terminal verwenden, an technische Verantwortliche für parallele Feature-, Test- und Dokumentationsaufgaben sowie an Teams, die mehrere Sitzungen auf einem entfernten Mac betreiben möchten. Wer nur eine einzelne kleine Änderung umsetzen will, benötigt in der Regel keine parallele Architektur.

Zuletzt aktualisiert am 13.08.2026. Befehle, Konfigurationsfelder und das Verhalten von Subagents, Agent Teams, Agent View und Worktrees wurden am selben Tag anhand der offiziellen Claude-Code-Dokumentation geprüft.

Die vier Ebenen der Parallelisierung

Claude Code bietet nicht nur eine Methode für paralleles Arbeiten. Die häufigsten Fehler entstehen, wenn Kontextisolierung, Prozessverwaltung und Dateiisolation gleichgesetzt werden.

Subagents laufen innerhalb einer Sitzung mit einem eigenen Kontextfenster. Sie eignen sich für Aufgaben, deren Ergebnis als strukturierte Zusammenfassung in die Hauptsitzung zurückfließen soll: Codebase-Erkundung, Log-Analyse, Dokumentationssuche oder das Ausführen einer umfangreichen Testsuite. Ein Subagent sieht nicht automatisch die vollständige Unterhaltung der Hauptsitzung und startet gewöhnlich mit einem frischen Kontext. Weitere Details beschreibt die offizielle Dokumentation zu Subagents.

Worktrees isolieren dagegen den Dateistand. Jeder Worktree besitzt ein eigenes Arbeitsverzeichnis und einen eigenen Branch, teilt aber die Git-Historie und das Remote-Repository mit dem Hauptverzeichnis. Damit können zwei Sitzungen dieselbe Codebasis bearbeiten, ohne gleichzeitig dieselben Dateien zu verändern. Der spätere Merge bleibt trotzdem eine fachliche Prüfentscheidung. Die Claude-Code-Referenz zu Worktrees beschreibt diesen Mechanismus und die anschließende Bereinigung.

Agent Teams koordinieren mehrere Claude-Code-Instanzen mit einem Team-Lead, Aufgabenverwaltung und Nachrichten zwischen den Beteiligten. Die Funktion ist laut offizieller Dokumentation experimentell, standardmäßig deaktiviert und benötigt eine ausdrückliche Aktivierung. Außerdem isolieren Agent Teams die Dateibearbeitung nicht automatisch durch getrennte Worktrees. Die Dokumentation zu Agent Teams sollte deshalb vor einem produktiven Einsatz geprüft werden.

Agent View ist eine zentrale Ansicht für mehrere Hintergrundsitzungen. Mit claude agents lassen sich laufende, blockierte und abgeschlossene Sitzungen überwachen. Die Funktion ist als Research Preview dokumentiert und erfordert laut offizieller Referenz Claude Code v2.1.139 oder neuer. Die aktuelle Funktionsbeschreibung findet sich in der offiziellen Dokumentation zu Agent View; Versionsvoraussetzungen sollten bei späteren Aktualisierungen erneut kontrolliert werden.

Die praktische Zuordnung lautet daher:

• Recherche, Logs oder Tests ohne direkte Dateiarbeit: Subagent.
• Parallele Codeänderungen: eigene Worktrees und Branches.
• Mehrere langfristige Sitzungen mit zentraler Übersicht: Agent View.
• Direkte Zusammenarbeit mehrerer Claude-Code-Instanzen: Agent Teams, aber nur nach Prüfung der experimentellen Einschränkungen.

Die häufigsten Fehlerquellen

Überschreibungen durch gemeinsame Arbeitsordner

Starten mehrere Sitzungen im selben Verzeichnis, sehen sie denselben Dateistand. Ein Agent kann eine Datei lesen, während ein anderer sie verändert; anschließend schreibt der erste Agent seine ältere Annahme zurück. Selbst wenn Git die Änderung später erkennt, ist oft nicht mehr klar, welche fachliche Entscheidung gültig war.

Ein eigener Worktree löst die Dateikollision während der Bearbeitung:

claude --worktree feature-auth
claude --worktree test-auth
claude --worktree docs-auth

Jede Sitzung arbeitet dann in einem separaten Verzeichnis und auf einem eigenen Branch. Claude Code legt Worktrees standardmäßig unter .claude/worktrees/ an; dieser Pfad sollte in .gitignore berücksichtigt werden.

Kontextüberlastung in der Hauptsitzung

Eine Testsuite, mehrere Megabyte Logausgabe oder die Untersuchung vieler Module kann den Kontext der Hauptsitzung mit Informationen füllen, die für die eigentliche Implementierung nicht dauerhaft benötigt werden. Das verschlechtert nicht automatisch die Codequalität, macht aber spätere Entscheidungen schwerer nachvollziehbar.

Ein Subagent sollte deshalb nicht mit „Untersuche alles“ beauftragt werden. Besser ist ein enges Ziel mit einem festen Ausgabeformat:

Untersuche ausschließlich die Authentifizierungslogik.

Liefere:
1. betroffene Dateien,
2. beobachtete Fehlerpfade,
3. vermutete Ursache,
4. drei konkrete Tests,
5. keine Codeänderungen.

Fasse das Ergebnis in höchstens zehn Stichpunkten zusammen.

So erhält die Hauptsitzung nur die Informationen, die für die nächste Entscheidung erforderlich sind. Rohdaten, lange Logs und wiederholte Dateiinhalte bleiben beim spezialisierten Agenten. Die offizielle Übersicht über Agenten und parallele Arbeit trennt diese Einsatzformen ausdrücklich nach Kontext, Sitzung und Arbeitsverzeichnis.

Versteckte gemeinsame Abhängigkeiten

Zwei Aufgaben können auf dem Papier unabhängig aussehen und trotzdem dieselbe Schnittstelle, Migration oder Sperrdatei verändern. Besonders kritisch sind:

• API-Verträge und gemeinsam verwendete Typdefinitionen,
• Datenbankmigrationen,
• package-lock.json, pnpm-lock.yaml oder vergleichbare Abhängigkeitsdateien,
• zentrale Konfigurationsdateien,
• automatisch erzeugte Dateien,
• gemeinsame Test-Fixtures,
• Build- und Deployment-Skripte.

Vor dem Start muss daher festgelegt werden, welcher Agent Eigentümer der konfliktträchtigen Datei ist. Andere Agenten konsumieren nur das veröffentlichte Ergebnis, anstatt parallel eine eigene Variante zu erzeugen. Wenn zwei Agenten alternative Implementierungen liefern, werden sie nicht blind zusammenkopiert. Sie werden anhand derselben Abnahmekriterien verglichen, und nur eine Variante wird weitergeführt.

Fehlende lokale Konfiguration

Ein neuer Worktree ist ein frischer Checkout. Nicht versionierte Dateien wie .env oder .env.local fehlen zunächst. Claude Code dokumentiert dafür die Datei .worktreeinclude, mit der bestimmte ignorierte Dateien in neu erzeugte Worktrees übernommen werden können. Tracked Files werden dadurch nicht dupliziert.

Geheimnisse sollten trotzdem nicht in Git, Chatverläufe oder frei kopierbare Konfigurationsdateien geschrieben werden. Für einen entfernten Mac sind ein Secret Manager, kurzlebige Zugangsdaten und minimale Berechtigungen vorzuziehen. Wird .worktreeinclude verwendet, sollte jede darin genannte Datei darauf geprüft werden, ob sie wirklich ohne Sicherheitsrisiko in mehrere Arbeitsverzeichnisse kopiert werden darf.

Claude Code mit mehreren KI-Agenten richtig aufteilen

Die zentrale Steuerung bleibt bei einer Hauptsitzung oder einem klar benannten Lead. Dort werden Ziel, Abhängigkeiten, Abnahmekriterien und Merge-Reihenfolge festgelegt.

Eine belastbare Aufteilung könnte so aussehen:

• Analyse-Agent: untersucht die bestehende Architektur und meldet nur relevante Dateien und Risiken.
• Implementierungs-Agent: bearbeitet eine klar abgegrenzte Funktion in einem eigenen Worktree.
• Test-Agent: ergänzt oder führt Tests aus, ohne unaufgefordert die Implementierung umzubauen.
• Dokumentations-Agent: aktualisiert Bedienungs- oder API-Dokumentation auf Grundlage eines akzeptierten Verhaltens.
• Review-Agent: prüft den fertigen Branch gegen die ursprüngliche Aufgabenbeschreibung und die Testresultate.

Entscheidend ist nicht die Anzahl der Agenten, sondern die geringe Überschneidung ihrer Schreibbereiche. Ein Agent, der „das Backend verbessert“, ist zu unspezifisch. Eine bessere Aufgabe lautet: „Implementiere die Validierung für den Endpunkt X, ändere nur die Dateien A und B, ergänze die Tests C und melde alle Änderungen außerhalb dieses Bereichs.“

Die Aufgabenbeschreibung sollte mindestens fünf Elemente enthalten:

1. Ziel und fachlicher Nutzen,
2. erlaubte Dateien oder Verzeichnisse,
3. explizit ausgeschlossene Bereiche,
4. erwartete Tests und Kommandos,
5. Ausgabeformat mit Änderungen, Risiken und offenen Punkten.

Subagents können über natürliche Sprache, eine @-Erwähnung oder als Sitzungsstandard mit --agent aufgerufen werden. Ein Subagent kann jedoch nicht beliebig weitere Subagents erzeugen; verschachtelte Delegation sollte daher durch die Hauptsitzung oder durch eine bewusst aufgebaute Kette gesteuert werden.

Der robuste Ablauf in sieben Schritten

1. Ausgangszustand festhalten

Vor dem Start werden Branch, Arbeitsbaum, Toolchain und Teststatus geprüft:

git status
git branch --show-current
git worktree list

Der Ausgangsstand sollte sauber oder bewusst dokumentiert sein. Ein Agent darf nicht versehentlich uncommitted Änderungen aus einer anderen Aufgabe übernehmen. Wenn die parallelen Sitzungen auf einem unfertigen lokalen Stand aufbauen müssen, kann die Worktree-Basis in den Einstellungen von einem frischen Remote-Stand auf den aktuellen lokalen HEAD umgestellt werden. Diese Entscheidung muss ausdrücklich dokumentiert werden, weil sie die Ausgangsbasis aller neuen Worktrees verändert.

2. Aufgaben und Konfliktdateien markieren

Jede Aufgabe erhält einen eindeutigen Namen, einen Branch und einen Besitzer. Vor dem Dispatch werden gemeinsame Schnittstellen, Migrationen und Sperrdateien in einer kurzen Abhängigkeitsliste erfasst.

Beispiel:

feature-auth:
- darf src/auth und tests/auth ändern
- darf keine Migration erzeugen
- benötigt den bestehenden User-Typ

db-migration:
- besitzt migrations/2026_...
- meldet das endgültige Schema an feature-auth

So wird sichtbar, welche Aufgabe zuerst abgeschlossen werden muss.

3. Passendes Parallelmodell auswählen

Für eine reine Untersuchung reicht ein Subagent. Für drei dauerhaft laufende Entwicklungsaufgaben sind getrennte Worktrees geeigneter. Für viele Hintergrundsitzungen kann Agent View die Übersicht verbessern. Agent Teams kommen erst infrage, wenn direkte Kommunikation zwischen unabhängigen Claude-Code-Instanzen tatsächlich erforderlich ist und die experimentelle Funktion im Projekt akzeptiert wurde.

4. Worktrees und Umgebungen initialisieren

Für jede schreibende Aufgabe wird eine isolierte Sitzung gestartet:

claude --worktree feature-auth
claude --worktree api-tests
claude --worktree documentation

Danach wird in jedem Worktree dieselbe Initialisierung ausgeführt: Abhängigkeiten installieren, virtuelle Umgebung aktivieren, lokale Dienste starten und einen kurzen Basistest ausführen. Ein Worktree isoliert Dateien, installiert aber nicht automatisch die gesamte projektspezifische Umgebung. Abhängigkeiten und virtuelle Umgebungen müssen daher in jedem neuen Worktree eingerichtet werden.

5. Fortschritt über überprüfbare Ergebnisse steuern

„Aufgabe erledigt“ ist kein ausreichendes Ergebnis. Jeder Agent liefert mindestens:

• Commit oder nachvollziehbare Änderungsübersicht,
• ausgeführte Testkommandos,
• Ergebnis jedes relevanten Tests,
• bekannte Einschränkungen,
• offene Annahmen,
• Rückkehr- oder Rollback-Strategie.

Ein Agent, der wegen fehlender Berechtigungen oder fehlender Variablen keinen Test ausführen konnte, muss dies ausdrücklich melden. Hintergrund-Subagents können bei einer benötigten Rückfrage scheitern oder Berechtigungsaktionen automatisch ablehnen; in diesem Fall ist eine erneute Ausführung im Vordergrund mit interaktiver Bestätigung sinnvoll.

6. Nach Abhängigkeit statt nach Fertigstellungszeit mergen

Die schnellste Aufgabe wird nicht automatisch zuerst übernommen. Zuerst werden Grundlagen gemergt, danach abhängige Implementierungen und zuletzt Dokumentation oder kosmetische Anpassungen.

Nach jedem Merge folgt ein vollständiger Prüfpunkt:

git status
npm test
npm run build

Die konkreten Kommandos hängen vom Projekt ab. Wichtig ist die Regel: Ein Merge ohne erneuten Build und ohne relevante Tests gilt nicht als abgeschlossen. Wenn ein Konflikt in einer zentralen Datei auftritt, entscheidet der fachlich zuständige Verantwortliche; Claude Code sollte nicht einfach beide Textblöcke verbinden, wenn sie unterschiedliche Datenmodelle oder Kontrollflüsse voraussetzen.

7. Worktrees kontrolliert bereinigen

Nach Abschluss werden alle Arbeitsverzeichnisse geprüft:

git worktree list
git worktree remove ../projekt-feature

Claude Code kann Worktrees abhängig vom Sitzungszustand automatisch zur Entfernung anbieten. Bei nicht interaktiven Läufen erfolgt die Bereinigung nicht automatisch, sodass git worktree remove erforderlich sein kann. Vor dem Entfernen werden offene Commits, untracked Files und nicht übertragene Testergebnisse kontrolliert.

Entscheidungsregeln für die Architektur

Die folgende Liste verhindert, dass für jede Aufgabe dieselbe Paralleltechnik eingesetzt wird:

• Wenn keine Datei geändert werden muss, wählen Sie einen Subagenten und verlangen Sie eine kurze strukturierte Zusammenfassung.
• Wenn eine Aufgabe Dateien ändert, aber vollständig unabhängig ist, verwenden Sie einen eigenen Worktree und Branch.
• Wenn mehrere Sitzungen auf dieselbe zentrale Datei zugreifen müssen, bestimmen Sie einen einzigen schreibenden Eigentümer; alle anderen Agenten arbeiten lesend oder warten auf dessen Commit.
• Wenn viele Sitzungen über längere Zeit laufen, verwenden Sie Agent View zur Überwachung und definieren Sie Stop-Bedingungen.
• Wenn Agenten direkt miteinander kommunizieren und Zwischenentscheidungen austauschen müssen, prüfen Sie Agent Teams; aktivieren Sie sie nicht allein deshalb, weil mehrere Aufgaben parallel laufen.
• Wenn ein Worktree eine geheime Konfigurationsdatei benötigt, verwenden Sie eine sichere Initialisierung oder kontrolliertes Kopieren über .worktreeinclude; schreiben Sie keine Zugangsdaten in den Branch.
• Wenn ein Agent keinen reproduzierbaren Test ausführen kann, stoppen Sie die Übergabe und beheben Sie zuerst die Umgebung.
• Wenn die parallelen Aufgaben nur wenige Minuten dauern und kaum Dateien berühren, ist eine einzelne Claude-Code-Sitzung mit sequenziellen Subagents oft einfacher und stabiler.

Remote-Mac-Betrieb und Ressourcenplanung

Mehrere Claude-Code-Sitzungen bedeuten nicht nur mehrere Textausgaben. Jede Sitzung kann gleichzeitig Dateien lesen, Prozesse starten, Tests ausführen, Builds erzeugen und auf Berechtigungen warten. Bei einem entfernten Mac kommen Netzwerkverbindung, Terminal-Sitzungen, Bildschirmzugriff, lokale Dienste und Schlaf- oder Abbruchverhalten hinzu.

Für eine stabile Umgebung sollten folgende Punkte vorab geprüft werden:

• Git-Repository und Workspace-Vertrauen sind eingerichtet.
• Claude Code und die projektbezogenen Laufzeiten sind verfügbar.
• Build-, Test- und Formatierungswerkzeuge liegen im PATH.
• Die Initialisierung jedes Worktrees ist reproduzierbar.
• Geheimnisse werden außerhalb des Repositorys verwaltet.
• Logs werden pro Sitzung getrennt gespeichert.
• Leerlaufende Prozesse und nicht mehr benötigte Worktrees werden beendet.
• Datenschutzanforderungen nach DSGVO werden für Quellcode, Logs und Sitzungsdaten bewertet.

Claude Code speichert Sitzungsdaten lokal in einer JSONL-Struktur unter dem Claude-Konfigurationsbereich. Bei Remote-Setups sollte deshalb geklärt werden, wer Zugriff auf diesen Rechner, die Sitzungsverläufe und die darin möglicherweise enthaltenen Code- oder Logausschnitte hat. Die offizielle Beschreibung der Sitzungs- und Arbeitsweise von Claude Code ist dafür die maßgebliche technische Referenz.

Eine Remote-Umgebung ist besonders sinnvoll, wenn mehrere Sitzungen über längere Zeit laufen sollen, der lokale Rechner währenddessen weiter genutzt werden muss oder Builds und Tests lokal zu viel Arbeitsspeicher beziehungsweise Prozessorzeit beanspruchen. Für sporadische Einzelaufgaben kann die zusätzliche Verwaltung dagegen unnötig sein. Hinweise zu verfügbaren Zugangs- und Betriebsoptionen finden sich im Zutcloud Help Center; für eine konkrete Anfrage steht außerdem die Kontaktseite von Zutcloud bereit.

Abnahme-Checkliste für jeden Agenten

Vor dem Merge sollte die zuständige Person alle zutreffenden Punkte abhaken:

• [ ] Aufgabe und erlaubter Änderungsbereich sind eindeutig.
• [ ] Der Agent arbeitete im richtigen Worktree und Branch.
• [ ] Keine Zugangsdaten wurden in Dateien oder Commits geschrieben.
• [ ] Abhängigkeiten und Migrationen sind dokumentiert.
• [ ] Unit-, Integrations- oder End-to-End-Tests wurden tatsächlich ausgeführt.
• [ ] Build und Formatierung sind erfolgreich oder die Abweichung ist erklärt.
• [ ] Die Änderungsübersicht nennt bewusst nicht veränderte Bereiche.
• [ ] Bekannte Einschränkungen und Rollback-Schritte sind vorhanden.
• [ ] Ein Review-Agent oder die Hauptsitzung hat den Diff gegen die Aufgabenbeschreibung geprüft.
• [ ] Nach dem Merge wurde die gemeinsame Testsuite erneut ausgeführt.
• [ ] Nicht mehr benötigte Worktrees und Hintergrundprozesse wurden entfernt.

Diese Liste trennt die Erzeugung von Code von seiner Abnahme. Genau diese Trennung ist bei Claude Code mit mehreren KI-Agenten wichtiger als eine möglichst große Zahl gleichzeitig laufender Sitzungen.

Häufige Fehlentscheidungen

Ein häufiger Fehler besteht darin, Subagents als Ersatz für Worktrees zu behandeln. Ein Subagent kann einen eigenen Kontext besitzen und trotzdem im selben Arbeitsverzeichnis Änderungen vorbereiten. Kontextschutz verhindert keine Dateikollision.

Der umgekehrte Fehler ist ebenfalls verbreitet: Für jede kleine Recherche wird ein eigener Worktree erzeugt. Das vervielfacht Initialisierung, Abhängigkeiten und Aufräumarbeit, obwohl lediglich eine Zusammenfassung benötigt wird.

Auch Agent Teams werden gelegentlich als automatische Konfliktlösung missverstanden. Sie koordinieren Aufgaben und Nachrichten, aber die Aufteilung der Dateien bleibt eine Architekturentscheidung. Die offizielle Anleitung empfiehlt, Dateikonflikte zu vermeiden und Aufgaben so zu partitionieren, dass Teammitglieder nicht dieselben Dateien bearbeiten.

Schließlich sollte keine Sitzung unbegrenzt laufen. Jede Aufgabe benötigt eine Abbruchbedingung, etwa „nach zwei fehlgeschlagenen Testläufen stoppen“, „bei fehlender Umgebungsvariable warten“ oder „nach Abschluss des vereinbarten Commits beenden“. Das schützt sowohl die Wartbarkeit als auch die laufenden Ressourcen.

FAQ

Mehrere Agenten starten

Claude Code kann Subagents innerhalb einer Sitzung delegieren. Für getrennte Sitzungen nutzt die Agent View den Befehl claude agents; alternativ startet jede Shell eine eigene Worktree-Sitzung. Agent Teams sind eine separate, experimentelle Funktion. Die Wahl hängt davon ab, ob nur Kontext ausgelagert, tatsächlich parallel geschrieben oder eine Gruppe von Sitzungen koordiniert werden soll.

Subagents und Worktrees trennen

Subagents isolieren hauptsächlich Aufgaben, Kontexte, Werkzeuge und Rückgaben. Worktrees isolieren Dateien und Branches. Ein Subagent kann daher für Recherche und Log-Analyse ohne Worktree ausreichen. Sobald zwei Prozesse gleichzeitig Code schreiben, sollte jede Schreibaufgabe einen eigenen Worktree verwenden. Beide Mechanismen können kombiniert werden.

Konflikte zwischen Sitzungen vermeiden

Konflikte werden nicht erst beim Merge gelöst, sondern vor dem Start reduziert. Gemeinsame Schnittstellen, Migrationen, Sperrdateien und generierter Code erhalten jeweils einen einzigen Besitzer. Andere Agenten konsumieren dessen Ergebnis. Zusätzlich werden Branches getrennt, Änderungsbereiche begrenzt und nach jedem Merge Build sowie Tests erneut ausgeführt.

Parallele Branches einsetzen

Git Worktrees sind dafür vorgesehen, mehrere Branches gleichzeitig als Arbeitsverzeichnisse verfügbar zu machen. Claude Code kann mit --worktree eine isolierte Sitzung starten. Die Branches teilen die Historie, nicht aber den aktuellen Dateistand. Deshalb bleiben fachliche Konflikte möglich, wenn zwei Agenten dieselbe Schnittstelle unterschiedlich verändern.

Remote-Sitzungen auf einem Mac

Ein entfernter Mac benötigt eine reproduzierbare Entwicklungsumgebung, eine stabile Verbindung, getrennte Worktrees, sichere Geheimnisverwaltung und überprüfbare Testkommandos. Für längere Läufe sollten Sitzungen überwacht und Leerlaufprozesse beendet werden. Vor dem Einsatz sind außerdem DSGVO-Anforderungen für Quellcode, Logs und lokal gespeicherte Sitzungsdaten zu klären.

Fazit und nächster Schritt

Die aktuelle lokale Lösung bleibt für kurze, sequenzielle Änderungen oft die vernünftigste Wahl. Bei mehreren parallelen Claude-Code-Sitzungen entstehen jedoch schnell drei konkrete Nachteile: Der lokale Rechner muss gleichzeitig Builds, Tests und Agentenprozesse tragen; ein schlafendes oder ausgelastetes Gerät unterbricht lange Aufgaben; und die Überwachung mehrerer Worktrees wird unübersichtlich, wenn kein dauerhaft verfügbarer Entwicklungsplatz vorhanden ist.

Wenn ein Team regelmäßig mehrere Sitzungen über längere Zeit plant, kann ein gemieteter Mac die Umgebung vom persönlichen Arbeitsgerät entkoppeln. Entscheidend ist nicht, dauerhaft zusätzliche Hardware zu reservieren, sondern die geplante Sitzungszahl, die Build-Dauer und die tatsächliche Online-Zeit mit der lokalen Leistungsfähigkeit zu vergleichen. Für zeitlich begrenzte Entwicklungs- und Testphasen kann die Mac-Mini-Mietlösung von Zutcloud deshalb die passendere Option sein; für dauerhaft gleichbleibende Schwerlast oder spezielle physische Schnittstellen bleibt ein eigener Mac die ehrlichere Wahl.

FAQ

Wie startet man mehrere Claude-Code-Agenten gleichzeitig?

Für unabhängige Nebenaufgaben kann Claude Code mehrere Subagents innerhalb einer Sitzung starten. Für dauerhaft getrennte Sitzungen eignet sich die Agent View mit „claude agents“ oder jeweils eine eigene Sitzung mit „claude --worktree name“. Agent Teams koordinieren mehrere Claude-Code-Instanzen, sind jedoch experimentell und müssen ausdrücklich aktiviert werden.

Was ist der Unterschied zwischen Subagents und Worktrees?

Subagents trennen vor allem den Kontext und die Zuständigkeit einer Aufgabe. Ein Subagent untersucht beispielsweise Logs und liefert nur eine Zusammenfassung zurück. Ein Worktree trennt dagegen den tatsächlichen Dateistand und die Branches. Sobald mehrere Agenten Dateien verändern, ist ein eigener Worktree pro Schreibaufgabe die sicherere Isolation.

Wie verhindert Claude Code bei mehreren Sitzungen Dateikonflikte?

Jede parallel schreibende Sitzung sollte in einem eigenen Git Worktree und auf einem eigenen Branch laufen. Zusätzlich müssen gemeinsam genutzte Dateien wie Schnittstellen, Migrationen, Sperrdateien und generierter Code vorab einem einzigen Agenten zugeordnet werden. Nach jedem Merge werden Formatierung, Build und Tests erneut ausgeführt.

Können Claude-Code-Agenten gleichzeitig in verschiedenen Branches arbeiten?

Ja. Mit „claude --worktree feature-name“ erstellt Claude Code einen separaten Arbeitsordner und Branch. Die Worktrees teilen zwar die Git-Historie, verändern aber jeweils ihren eigenen Dateistand. Dadurch können mehrere Agenten parallel entwickeln. Das verhindert jedoch keine inhaltlichen Konflikte beim späteren Merge, weshalb eine Reihenfolge und gemeinsame Abnahmekriterien erforderlich bleiben.

Welche Umgebung braucht man für mehrere Claude-Code-Sitzungen auf einem entfernten Mac?

Benötigt werden ein vertrauenswürdiges Git-Arbeitsverzeichnis, Claude Code, die passende Laufzeit für das Projekt, installierte Build- und Testwerkzeuge sowie ein sicherer Umgang mit Umgebungsvariablen und Zugangsdaten. Für stabile Remote-Sitzungen sollten Abhängigkeiten über ein reproduzierbares Initialisierungsskript eingerichtet und Leerlaufzeiten sowie laufende Prozesse überwacht werden.

Weiterlesen

• Agent-Dateisysteme mit Sandboxes, Speicherschichten und isolierten Arbeitsbereichen
• Agent-Architekturen im Vergleich: Rollen, Orchestrierung und kontrollierte Workflows