Zehn Claude-Code-Agenten: Das Code-Review ist die Grenze

Wer schon einmal eine zweite Sitzung von Claude Code im selben Repository geöffnet hat und später vor einem halb gemergten Durcheinander stand, braucht keinen besseren Prompt. Er braucht pro Sitzung ein eigenes Arbeitsverzeichnis. Anthropic liefert dafür den Schalter --worktree (offizielle Dokumentation), und im ersten Halbjahr 2026 haben sämtliche größeren Wettbewerber dasselbe Prinzip nachgezogen. Wir arbeiten täglich so an unserer eigenen mehrsprachigen Publishing-Codebasis. Im Folgenden lesen Sie die Reihenfolge, die funktioniert, das Umgebungsproblem, vor dem niemand warnt, und die Obergrenze, die kein Werkzeug aufhebt.

Was tatsächlich kollidiert, wenn Agenten parallel laufen

Unter „die Agenten kommen sich in die Quere" werden drei verschiedene Konflikte zusammengefasst, die jeweils eine eigene Lösung verlangen.

Dateiänderungen. Bearbeiten zwei Sitzungen dieselbe Datei im selben Arbeitsverzeichnis, entsteht genau der Merge-Konflikt, dessen Auflösung länger dauert als die ursprüngliche Aufgabe (Developers Digest). Ein Branchwechsel im einen Terminal verändert dabei unbemerkt die Dateien unter einer laufenden Sitzung im anderen.

Umgebung. Ein zweites Arbeitsverzeichnis enthält weder .env noch installierte Abhängigkeiten, und häufig ist derselbe Port fest verdrahtet wie im ersten. Der Agent debuggt daraufhin Ihre Einrichtung statt Ihres Tickets.

Aufmerksamkeit. Zehn Agenten erzeugen zehn Diffs. Das ist der Konflikt, den kein Schalter löst, und er entscheidet darüber, wie viele Agenten Sie tatsächlich betreiben sollten.

Die beiden anderen Konflikte lösen sie nicht. Gehen Sie die folgenden Schritte deshalb der Reihe nach durch, denn wer direkt mit zehn Agenten startet, kommt schnell zu dem Schluss, paralleles Arbeiten funktioniere nicht.

Schritt 1: Jeder Sitzung ein eigenes Arbeitsverzeichnis geben

Ein git worktree ist ein eigenständiges Arbeitsverzeichnis mit eigenen Dateien und eigenem Branch, das Historie und Remote mit Ihrem Hauptverzeichnis teilt. Claude Code legt es an und startet die Sitzung direkt darin:

claude --worktree feature-auth

Standardmäßig entsteht das Verzeichnis unter .claude/worktrees/feature-auth/ im Wurzelverzeichnis des Repositorys, auf einem neuen Branch namens worktree-feature-auth. Rufen Sie denselben Befehl mit einem anderen Namen in einem weiteren Terminal auf, erhalten Sie eine zweite isolierte Sitzung. Lassen Sie den Namen weg, wird einer erzeugt, etwa bright-running-fox (offizielle Dokumentation).

Halten Sie die Verzeichnisse aus dem Status Ihres Hauptverzeichnisses heraus:

echo ".claude/worktrees/" >> .gitignore

Interaktive Läufe setzen voraus, dass Sie dem Verzeichnis vertrauen. Haben Sie Claude Code dort noch nie gestartet, rufen Sie es einmal ohne Schalter auf und bestätigen den Vertrauensdialog, sonst bricht der Aufruf mit einer Fehlermeldung ab. Nicht interaktive Läufe mit -p überspringen diese Prüfung vollständig.

Um statt vom Standardbranch von einem Pull Request auszugehen, übergeben Sie dessen Nummer mit vorangestelltem # in Anführungszeichen, damit die Shell sie nicht als Kommentar liest:

claude --worktree "#1234"

Erwartetes Ergebnis: git worktree list zeigt je laufender Sitzung einen Eintrag auf einem eigenen worktree-*-Branch, und keine Sitzung sieht die Änderungen einer anderen.

Schritt 2: Die Umgebung mitgeben, die das Arbeitsverzeichnis nicht erbt

Das ist der Schritt, der zuerst scheitert, und er scheitert lautlos. Ein neues Arbeitsverzeichnis ist ein frischer Checkout, weshalb von Git ignorierte Dateien nicht mitkommen.

❌ Vorher. Sie starten claude --worktree feature-auth, der Agent lässt die Tests laufen, und sie scheitern an fehlenden Umgebungsvariablen. Anschließend verbraucht der Agent sein Kontextfenster damit, Ihre lokale Einrichtung zu untersuchen, statt die Aufgabe zu lösen.

✅ Nachher. Legen Sie im Projektwurzelverzeichnis eine Datei .worktreeinclude an. Sie folgt der Syntax von .gitignore, und kopiert werden ausschließlich Dateien, die einem Muster entsprechen und von Git ignoriert werden. Versionierte Dateien werden also nie doppelt abgelegt:

.env
.env.local
config/secrets.json

Derselbe Aufruf claude --worktree feature-auth startet nun mit funktionierender Umgebung, und das gilt für jedes Arbeitsverzeichnis, das Claude Code anlegt (offizielle Dokumentation). Die Abhängigkeiten müssen im neuen Checkout weiterhin installiert werden: Entweder Sie machen das zur ersten Anweisung an den Agenten, oder Sie führen Ihr Einrichtungsskript dort selbst aus.

Eine Voreinstellung sollten Sie ändern. Neue Arbeitsverzeichnisse zweigen vom Standardbranch des Remotes ab, was meistens richtig ist. Verteilen Sie Agenten dagegen auf Arbeit, die nur lokal existiert, zweigen Sie besser von Ihrem aktuellen HEAD ab:

{
  "worktree": {
    "baseRef": "head"
  }
}

Zu beachtender Fehlerfall: Bleibt es bei der Voreinstellung, startet ein Arbeitsverzeichnis, das von einem nicht gepushten Feature-Branch ausgehen sollte, stillschweigend von main. Der Agent scheint dann Arbeit zu verlieren, die nie verloren war.

Schritt 3: Den Koordinationsmodus zur Aufgabe passend wählen

Isolation ist noch keine Orchestrierung. Anthropic dokumentiert vier verschiedene Wege, wie Claude Code parallel arbeitet, und die falsche Wahl kommt häufig vor und wird teuer (offizielle Dokumentation):

Genau darin liegt die Falle. Die Agentenansicht verschiebt jede gestartete Sitzung automatisch in ein eigenes Arbeitsverzeichnis, Agententeams tun das nicht. Wer Teams aktiviert und die Aufteilung der Dateizuständigkeiten überspringt, hat exakt den Konflikt zurückgeholt, den Schritt 1 beseitigt hat.

Sobald mehrere Sitzungen unbeaufsichtigt laufen, brauchen Sie einen Ort, an dem ihr Zustand sichtbar wird. Genau dafür haben wir für eine Steuerzentrale für Agenten argumentiert.

Für eigene Agentendefinitionen in .claude/agents/ machen Sie die Isolation mit einer einzigen Zeile im Frontmatter dauerhaft:

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

Apply the requested refactor across every affected file, then run the tests
and report the results.

Schritt 4: Sitzungen absichern, die Sie nicht mehr beobachten

Arbeitsverzeichnisse isolieren Dateien innerhalb Ihres Repositorys. Sonst isolieren sie nichts auf Ihrem Rechner, und Claude Code behauptet das auch nicht. Das wird in dem Moment relevant, in dem Agenten ohne Rückfragen bei Berechtigungen laufen.

Docker Sandboxes geben jedem Agenten eine verwerfbare Umgebung:

sbx run claude ~/my-project

Der Standardstartbefehl innerhalb einer Sandbox lautet claude --dangerously-skip-permissions, was gerade deshalb vertretbar ist, weil der mögliche Schaden auf einen Container begrenzt bleibt und nicht Ihren Rechner trifft (Docker-Dokumentation). Der Klonmodus geht weiter: Der Agent arbeitet in einem privaten Git-Klon innerhalb der Sandbox, während Ihr Repository auf dem Host nur lesend eingebunden wird.

sbx run --clone claude

Zwei dokumentierte Einschränkungen werden Ihnen begegnen (Docker-Sandbox-Handbuch):

• Der Klonmodus wird beim Anlegen festgelegt. Eine bestehende Sandbox umzustellen bedeutet, sie zu entfernen und neu anzulegen.
• Der Klonmodus wird aus jedem Arbeitsverzeichnis außer dem Hauptverzeichnis abgelehnt, weil die nur lesend eingebundene Verknüpfung die Datei .git des Arbeitsverzeichnisses nicht auflösen kann. Führen Sie ihn deshalb im Hauptverzeichnis aus.

Sandboxes übernehmen außerdem keine Konfiguration auf Benutzerebene aus ~/.claude; sichtbar ist dort ausschließlich die Konfiguration des Projektverzeichnisses. Agenten, die auf Ihre persönlichen Einstellungen angewiesen sind, verhalten sich dort anders, und das mitten in einer Aufgabe zu bemerken ist unangenehmer, als es vorher zu wissen.

Schritt 5: Die Obergrenze an der eigenen Prüfkapazität ausrichten

Inzwischen liefert jeder Anbieter dasselbe Mittel zur Isolation. Cursor 3.0 hat Composer abgelöst und stattdessen ein Agentenfenster eingeführt, das Agenten über isolierte Arbeitsverzeichnisse und SSH-Verbindungen hinweg betreibt (Level Up Coding). Die Desktopanwendung von GitHub Copilot, vorgestellt auf der Microsoft Build am 2. Juni 2026, gibt jeder parallelen Sitzung ein eigenes Arbeitsverzeichnis (Digital Applied), und am 9. Juli 2026 hat GitHub parallele Sitzungen in VS Code allgemein verfügbar gemacht (TechTimes). Die Orchestrierungswerkzeuge für den Desktop sind beim selben Modell gelandet: ein Agent je Arbeitsverzeichnis, dazu ein Diff zur Freigabe (Parallel Code). In Anleitungen aus der Praxis gilt die sequenzielle Arbeitsweise inzwischen als Einschränkung des Werkzeugs und nicht als Eigenschaft der Aufgabe (Worktrees erklärt).

Wenn alle Werkzeuge die Isolation auf dieselbe Weise lösen, taugt sie nicht mehr zur Unterscheidung. Übrig bleibt Ihr eigener Durchsatz beim Prüfen.

Wir begrenzen uns auf vier gleichzeitige Sitzungen je Repository, weil uns jenseits davon das Prüfen und Zusammenführen der Ergebnisse mehr Zeit kostet, als die Parallelität einspart. Den zehnten Agenten bremst nicht Git. Ihn bremst der Umstand, dass zehn gleichzeitig eintreffende Diffs schlechter geprüft werden als drei nacheinander, und ein schlecht geprüfter Diff aus einem Agentenlauf kostet mehr als eine Aufgabe, die nie begonnen wurde.

Dieselbe Kostenlogik haben wir bei der tokenbasierten Abrechnung von Modellen angelegt: Der genannte Grundpreis entscheidet selten über die Rechnung.

Aus demselben Grund plädieren wir dafür, dem schlankeren Agenten den Vorzug zu geben, wenn die Aufgabe das größere Werkzeug nicht braucht.

Praktisch finden Sie Ihre eigene Zahl so: Lassen Sie eine Woche lang drei Agenten laufen und messen Sie, wie lange jeder Diff wartet, bis ihn ein Mensch öffnet. Wächst diese Wartezeit, fügen Sie keine Kapazität hinzu, sondern Warteschlange. Mehrere gleichzeitige Sitzungen vervielfachen zudem den Tokenverbrauch, sodass die Kostenkurve früher steigt als der Nutzen.

Setzen Sie die Grenze bewusst, isolieren Sie unterhalb davon sauber, und parallele Agenten werden zu einem echten Hebel. Wer die Zahl der Agenten zum Ziel erklärt, hat eine Warteschlange mit Zusatzaufwand gebaut. Für den Einstieg auf Bodenhöhe beginnen Sie mit unserem ehrlichen Einstieg für Nichtentwickler; wenn Sie das Ganze auf Ihre Codebasis zuschneiden lassen möchten statt auf eine Vorführung, übernimmt unser Entwicklungsteam genau diese Arbeit.

Häufig gestellte Fragen

Brauche ich eigene Arbeitsverzeichnisse schon bei zwei Agenten? Ja, sobald beide Dateien bearbeiten. Zwei Sitzungen von Claude Code in einem Arbeitsverzeichnis kollidieren unabhängig von ihrer Zahl bei Branchwechseln und beim Stashen (Developers Digest). Der Aufwand beträgt einen Schalter, weshalb es keine sinnvolle Wartemarke gibt.

Was geschieht mit dem Arbeitsverzeichnis, wenn eine Sitzung endet? Beim Beenden prüft Claude Code auf geänderte Dateien, nicht versionierte Dateien und neue Commits. Saubere, unbenannte Sitzungen werden automatisch entfernt; enthält das Verzeichnis Arbeit, werden Sie gefragt. Nicht interaktive Läufe mit -p räumen nie auf, diese entfernen Sie mit git worktree remove (offizielle Dokumentation).

Ersetzen Agententeams die Arbeitsverzeichnisse? Nein. Teams koordinieren Arbeit, Arbeitsverzeichnisse isolieren Dateien. Teams sind experimentell, standardmäßig deaktiviert und isolieren die Beteiligten ausdrücklich nicht, sodass Zuständigkeiten von Hand aufgeteilt werden müssen (offizielle Dokumentation).

Ist eine Sandbox nötig oder genügt ein Arbeitsverzeichnis? Ein Arbeitsverzeichnis isoliert nur Dateien des Repositorys. Laufen Agenten ohne Rückfragen bei Berechtigungen, nutzen Sie eine Sandbox, damit der mögliche Schaden auf einen Container begrenzt bleibt (Docker-Dokumentation). Für beaufsichtigte Sitzungen in einem vertrauenswürdigen Repository genügt das Arbeitsverzeichnis.

Wie viele parallele Agenten sind zu viele? Die Grenze liegt beim Prüfdurchsatz, nicht beim Werkzeug. Warten Diffs Woche für Woche länger, bis ein Mensch sie öffnet, haben Sie die Grenze überschritten. Wir nutzen vier je Repository und messen die Wartezeit statt der Zahl der Agenten.

Quellen

1. Parallele Sitzungen mit Arbeitsverzeichnissen — Dokumentation zu Claude Code — Anthropic, Stand 17.07.2026
2. Agenten parallel betreiben — Anthropic, Stand 18.07.2026
3. Claude Code in Docker Sandboxes — Docker, Stand 15.07.2026
4. Docker Sandboxes: Nutzung und Klonmodus — Docker, Stand 15.07.2026
5. GitHub schließt die Agentenschleife in VS Code — TechTimes, 09.07.2026
6. Parallel Code im Vergleich zu Conductor — Parallel Code, 15.06.2026
7. Git-Worktrees für parallele KI-Agenten erklärt — bri, 14.06.2026
8. Das Praxishandbuch 2026 für parallele Agenten — Developers Digest, 10.06.2026
9. Die GitHub-Copilot-Anwendung für den Desktop — Digital Applied, 06.06.2026
10. KI-Tagesüberblick vom 22. Mai 2026 — Level Up Coding, 22.05.2026