Inhalt

Die agent view von Claude Code (geöffnet mit claude agents) ist der Ort, an dem Sie eine unabhängige Session nach der anderen im Hintergrund starten und alle von einem einzigen Bildschirm aus verwalten. In der offiziellen Formulierung erlaubt sie es, „viele Claude-Code-Sessions von einem Bildschirm aus zu dispatchen und zu verwalten“ (Manage multiple agents with agent view).

Dieser Artikel bleibt bei der Mechanik und dem Sicherheitsmodell. Die echte Gefahr ist nicht, dass „die KI durchdreht“ — sie besteht darin, zehn Sessions aufzureihen, ohne zu wissen, wie weit die Isolation reicht und mit welchen Berechtigungen sie laufen, während Sie gerade nicht hinschauen. Die Kurzfassung: Die Isolation ist mit echter Sorgfalt gebaut — aber drei Dinge dringen nach außen. Das ist der Teil, der Ihre Aufmerksamkeit verdient.

📌 Woher diese Angaben stammen: Jedes Verhalten, jede Versionsnummer und jeder Einstellungsname weiter unten wurde mit Stand vom 9. August 2026 gegen die offizielle Dokumentation geprüft. Agent view ist eine Research Preview und setzt Claude Code v2.1.139 oder neuer voraus. Preview-Funktionen bewegen sich, prüfen Sie Ihren eigenen Stand also mit claude --version und die Details gegen die aktuelle Doku.

🔀 Falls Sie auf der Suche nach „Dispatch“ hier gelandet sind. Claude hat zwei verschiedene Funktionen mit verwirrend ähnlichen Namen. Dispatch in der Seitenleiste der Desktop-App ist die Funktion, mit der Sie Claude vom Handy aus eine Nachricht schicken und es auf Ihrem eigenen Rechner arbeiten lassen, und darum geht es in diesem Artikel nicht — dieses Thema behandelt wie Dispatch funktioniert und wie sicher es ist. Hier geht es um agent view, eine Terminal-Funktion von Claude Code; die Namen kollidieren, weil die offizielle Dokumentation die Operation, die Sie dort ausführen, „dispatch“ nennt.

1. Was agent view ist — die Operation, die die Doku „dispatch“ nennt

Klären wir zuerst den Namen. Innerhalb von Claude Code ist „dispatch“ der Name einer Operation, die Sie in der agent view ausführen, und keine eigenständige Funktion, die so heißt. Die offizielle Dokumentation formuliert es so.

„Die agent view, geöffnet mit claude agents, ist ein einziger Bildschirm, der alle Ihre Hintergrund-Sessions zeigt — was gerade läuft, was auf Ihre Eingabe wartet und was fertig ist.“ (Agent view)

Ebenso deutlich ist die Doku dabei, wann man dazu greift: wenn Sie mehrere unabhängige Aufgaben haben, sie abgeben wollen, ihren Zustand auf einen Blick sehen wollen und nur dann eingreifen wollen, wenn es sein muss. Ein Bugfix, ein PR-Review, die Untersuchung eines instabilen Tests — werfen Sie diese drei als drei Zeilen hinein, arbeiten Sie in einem anderen Fenster an Ihrem eigenen Kram weiter, und schauen Sie hin, sobald eine Zeile in den Zustand „braucht Sie“ wechselt.

✅ Arbeit, die dazu passt

Aufgaben, die voneinander unabhängig sind und die Sie nicht im Verlauf beobachten müssen. Arbeit, bei der es genügt, am Ende das Ergebnis zu bekommen, während Sie in der Zwischenzeit etwas anderes tun.

❌ Arbeit, die nicht dazu passt

Alles, dessen Richtung auf halbem Weg neu entschieden werden muss, alles, was sich um dieselben Dateien streitet, und alles, was eine unumkehrbare Aktion enthält (ein Deploy, die Produktionsdatenbank, das Versenden nach außen).

2. Ein Prompt ergibt eine Session, keine Rückfrage

Das ist das Erste, worüber Leute stolpern. Die Dokumentation sagt es ausdrücklich: Jeder Prompt, den Sie hier eintippen, startet seine eigene neue Session. Tippen Sie einen zweiten Prompt und drücken Sie Enter, bekommen Sie eine zweite Session neben der ersten und keine zusätzliche Anweisung an die erste.

Wer aus dem Chat-Reflex heraus „noch eine Sache zu der letzten Aufgabe“ tippt, hat keine Ergänzung angehängt, sondern einen neuen Auftrag erzeugt. Das ist Absicht und kein Versehen, denn die agent view existiert überhaupt nur dafür, unabhängige Aufgaben aufzureihen. Wenn Sie tatsächlich eine weitere Anweisung schicken wollen, schicken Sie sie über das Peek-Panel, das weiter unten beschrieben wird.

Aktion Was passiert
Prompt im Eingabefeld → Enter Startet eine neue Session (sie sammeln sich parallel an)
Space Öffnet das Peek-Panel. Sie sehen die letzte Ausgabe oder die Frage, auf die gewartet wird, nicht das ganze Protokoll
Antwort im Peek-Panel → Enter Antwortet dieser Session, ohne die agent view zu verlassen
→ oder Enter (bei ausgewählter Zeile) Springt in diese Session hinein (attach)
Ctrl+X Stoppt sie. Noch einmal gedrückt, löscht es (was direkt in die Falle aus Abschnitt 6 führt)
Ctrl+S / Ctrl+T / Ctrl+R Gruppieren (nach Zustand oder nach Verzeichnis) / anpinnen / umbenennen

Und noch etwas: Die Subagents und teammates, die eine Session sich selbst erzeugt, erscheinen nicht als eigene Zeilen. Der Bildschirm listet nur die Einheiten auf, die Sie dispatcht haben.

3. Wie die Isolation funktioniert — vor dem Schreiben geht es in ein worktree

Hier wohnt das Sicherheitsmodell. Eine Hintergrund-Session zieht in ein eigenes git worktree um, bevor sie irgendeine Datei bearbeitet. Die offizielle Beschreibung liest sich so.

„Jede Hintergrund-Session startet in Ihrem Arbeitsverzeichnis, gleich ob sie aus der agent view oder mit /bg oder claude --bg gestartet wurde. Bevor Dateien bearbeitet werden, verschiebt Claude die Session in ein isoliertes git worktree unterhalb von .claude/worktrees/. So lesen parallele Sessions denselben Checkout, schreiben aber jeweils in ihren eigenen.“ (Agent view)

Was dieses Design trägt, ist der Grundsatz gemeinsam lesen, getrennt schreiben. Parallele Sessions können den Code der anderen lesen, ihre Annahmen driften also nicht auseinander, während ihre Schreibvorgänge nicht kollidieren können. Drei Sessions, die im selben Verzeichnis laufen und sich gegenseitig die Dateien überschreiben — die schlimmste Version dieses Unfalls — sind strukturell ausgeschlossen.

Und dann kommt der Satz, auf den es am meisten ankommt. „Sobald eine Session in einem worktree ist, blockiert Claude Code Dateibearbeitungen und Befehle, die den Haupt-Checkout erreichen würden — sowohl für diese Session als auch für jeden Subagent, den sie erzeugt.“ Die Isolation wird an die Kinder vererbt. Ruft eine dispatchte Session intern fünf Subagents auf, sitzen alle fünf innerhalb derselben Mauer.

4. Die drei Prüfungen, die die Isolation tragen

Die Doku wird konkret, was „blockiert“ bedeutet. Es gibt drei Arten von Prüfung.

1. Dateibearbeitungen

Blockiert Edit, Write und NotebookEdit, die auf einen Pfad innerhalb des Haupt-Checkouts zielen.

2. Arbeitsverzeichnis von Befehlen

Blockiert Befehle, deren Arbeitsverzeichnis auf den Haupt-Checkout zeigt, und Befehle, bei denen sich nicht überprüfen lässt, dass sie draußen bleiben.

3. Umlenken von git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, ein cd vor dem git-Aufruf — all das wird abgeschnitten.

Dass auch die dritte Lücke geschlossen ist, zeugt von ernsthafter Arbeit. Es heißt nicht nur „nicht in den Haupt-Checkout schreiben“, sondern auch „git nicht dazu überreden, auf den Haupt-Checkout zu zeigen“. Und die Entscheidung fällt auf der sicheren Seite: Ein Befehl, der sich nicht überprüfen lässt, läuft nicht.

⚠️ Trotzdem ist das keine Mauer auf Betriebssystemebene. Die drei Prüfungen arbeiten, indem sie prüfen, worum ein Tool-Aufruf bittet, und nicht, indem sie einen Prozess einsperren. Was sie schützen, ist der Haupt-Checkout desselben Repositorys, und Dateien außerhalb des Repositorys sowie das Netzwerk fallen bei keiner der drei in den Geltungsbereich.

Die Doku sagt außerdem klar, dass PowerShell-Befehle nur Prüfung 2 bekommen, die des Arbeitsverzeichnisses. Wenn PowerShell unter Windows Ihre Hauptshell ist, rechnen Sie nicht mit dem dritten Schutz. Den Prozess selbst einzusperren, ist nicht Aufgabe des worktree, sondern die der Sandbox.

5. Woher die Berechtigungen kommen

Während Sie nicht hinsehen: Mit welchem Berechtigungsmodus läuft diese Session eigentlich? Sessions aufzureihen, ohne eine Antwort auf diese Frage zu haben, ist das Gefährlichste, was Sie hier tun können.

Die offizielle Regel ist eindeutig. Wenn Sie aus dem Eingabefeld der agent view dispatchen oder claude --bg aus einer Shell starten, wird der defaultMode aus den Einstellungen dieses Verzeichnisses verwendet. Haben Sie einen Subagent dispatcht, wird stattdessen der permissionMode aus dessen Frontmatter verwendet.

Mit anderen Worten: Die Berechtigungen werden nicht spontan gewählt, sondern aus Ihrer Konfiguration geerbt. Je lockerer Ihr üblicher defaultMode in der settings.json ist, desto wörtlicher stimmt der Satz, dass in dem Moment, in dem Sie dispatchen, zehn unbeaufsichtigte Sessions mit lockeren Rechten entstehen. Ihre Berechtigungsmodi und Berechtigungsregeln vorher zu ordnen, ist eine Voraussetzung und keine Fleißaufgabe.

Wo es allerdings anhalten soll, hält es ordentlich an. Wenn eine Session etwas braucht, das nur Sie liefern können — eine Antwort auf eine Frage, eine Berechtigungsentscheidung, die nächste Anweisung —, wechselt die Zeile auf „Needs input“ (wartet auf Eingabe). Dieser Zustand ist der eine Kontrollpunkt, der Ihnen bleibt. Deshalb ist die agent view kein „Bildschirm, auf dem man Dinge aufreiht und weggeht“, sondern „ein Bildschirm, zu dem man zurückkehrt, um die wartenden Zeilen abzuholen“.

6. Die Fallen, die man leicht übersieht

Die Isolation ist sorgfältig gebaut. Trotzdem dringen drei Dinge nach außen. Das ist der Teil, der in der echten Arbeit zubeißt.

1. Eine Zustimmung mit „nicht mehr fragen“ spaziert aus dem worktree hinaus

Laut Dokumentation speichert die Wahl von „Ja, nicht mehr fragen“ für einen Bash-Befehl in einer worktree-Session diese Regel in der .claude/settings.local.json des Haupt-Checkouts. Das Ergebnis: Sie gilt im Haupt-Checkout und in jedem anderen worktree, und sie überlebt das Löschen genau des worktree, in dem sie entstanden ist.
Damit wird eine einzelne Berechtigungsentscheidung, die an einem isolierten Ort gefallen ist, zu dauerhafter Konfiguration außerhalb davon. Ein „nicht mehr fragen“, das gedrückt wurde, während Sie nicht hinsahen, und zwar in etwas, das Sie für einen Wegwerf-Arbeitsplatz hielten, gilt von da an. Greifen Sie also nicht leichtfertig zu „nicht mehr fragen“, wenn das Peek-Panel einer dispatchten Session Sie um eine Berechtigung bittet.

2. Eine Session zu löschen, löscht die nicht committete Arbeit gleich mit

In den offiziellen Einschränkungen steht es unverblümt: „Von Claude erzeugte worktrees werden zusammen mit der Session gelöscht, wenn Sie diese in der agent view löschen. Committen Sie Ihre Änderungen, bevor Sie eine Session löschen, die Dateien in ihrem eigenen worktree bearbeitet hat.“
Ctrl+X heißt beim ersten Druck stoppen, beim zweiten löschen. Drücken Sie es beim Aufräumen einer fertigen Session zweimal, ist das Ergebnis mit weg. „Fertig“ und „eingesammelt“ sind nicht dasselbe — sobald Sie das Ergebnis haben, committen oder mergen Sie es, bevor Sie löschen.

3. .worktreeinclude reicht Ihre Geheimnisse an jedes worktree weiter

Ein worktree ist ein frischer Checkout, eine per gitignore ausgeschlossene .env ist darin also nicht enthalten. Weil ohne sie nichts läuft, tragen Sie sie in .worktreeinclude ein, und dann wird sie bei jeder Neuanlage eines worktree automatisch hineinkopiert.
Praktisch — nur bedeutet es umgekehrt, dass mit jeder dispatchten Session eine weitere Kopie Ihrer Zugangsdaten auf der Platte landet. Wer das parallel betreibt, verteilt vernünftigerweise Entwicklungsschlüssel und keine Produktionsschlüssel.

Drei weitere Einschränkungen sind offiziell aufgeführt. Das Kontingent schmilzt multiplikativ („zehn Agenten parallel laufen zu lassen, verbraucht Ihr Kontingent etwa zehnmal so schnell wie einer“). Sessions laufen lokal — sie überstehen den Ruhezustand, aber das Herunterfahren der Maschine beendet sie. Und dazu die Tatsache, dass das Ganze eine Research Preview ist.

7. Die Wahl treffen — es gibt vier Wege zu parallelisieren

Die offizielle Dokumentation ordnet die Parallelisierung in vier Ansätze. Dispatch (agent view) ist nur einer davon, den falschen zu wählen, kostet Sie also schlicht etwas.

Ansatz Wer führt Regie Wann man ihn wählt
Subagents Claude delegiert innerhalb eines Gesprächs und sammelt das Ergebnis ein Sie wollen nicht, dass Ausgaben von Nebenarbeiten (Suchtreffer, Logs, Dateien) den Hauptkontext verschmutzen
Agent view (dispatch) Sie geben ab und schauen später nach Mehrere unabhängige Aufgaben. Dieser Artikel. Research Preview
Agent Teams Claude plant, verteilt und beaufsichtigt Sie wollen Arbeitsteilung und Abstimmung abgeben. Experimentell, standardmäßig deaktiviert. In einem eigenen Artikel behandelt
Dynamische Workflows Ein Skript hält den Plan Ein Audit der gesamten Codebasis, eine Migration über 500 Dateien — eine Größenordnung, die kein einzelner Zug dirigieren kann. Und wenn Ergebnisse gegengeprüft werden müssen

Die Trennlinie ist die Frage, wer Regie führt. Erledigt es sich innerhalb eines Gesprächs, dann Subagents. Führen Sie Regie und sammeln später ein, dann agent view. Soll Claude Regie führen, dann Agent Teams. Verlangt die Größenordnung ein festes Verfahren statt einer Entscheidung im Moment, dann dynamische Workflows.

Worktrees sind übrigens nicht als Weg zur Parallelisierung eingeordnet, sondern als Werkzeug zur Isolation. Die agent view verwendet sie automatisch. Für parallele Sessions, die Sie selbst starten, benennen Sie eines ausdrücklich, etwa mit claude --worktree <name>.

8. Ein Ablauf, um das sicher zu betreiben

Bevor Sie dispatchen

  • Prüfen Sie den defaultMode für dieses Verzeichnis. Er wird wortwörtlich zur Berechtigungsstufe einer Session, die niemand beobachtet
  • Geben Sie keine Arbeit ab, die unumkehrbare Aktionen enthält. Deploys, die Produktionsdatenbank und ausgehende Sendungen gehören in eine Session, die Sie beobachten
  • Sind die Aufgaben wirklich unabhängig? Hängen sie an derselben Designentscheidung, klären Sie diese zuerst und geben Sie sie dann ab
  • Was steht in Ihrer .worktreeinclude? Ihre Schlüssel werden einmal pro aufgereihter Session kopiert

Während sie laufen

  • Kommen Sie für die Zeilen mit „Needs input“ zurück. Das ist der einzige Kontrollpunkt
  • Werden Sie um eine Berechtigung gebeten, wählen Sie nicht „nicht mehr fragen“. Diese Entscheidung überlebt das worktree
  • Parallelität bildet sich direkt im Kontingent ab. Zehn auf einmal leeren es zehnmal so schnell

Nachdem sie fertig sind

  • Committen Sie, bevor Sie löschen. Der zweite Ctrl+X löscht, und der Inhalt des worktree geht mit
  • Nehmen Sie die Ergebnisse nicht auf Treu und Glauben. Alles, was Sie parallel laufen ließen, hat eine weitere ungeprüfte Behauptung hinzugefügt

Der letzte Punkt verdient als Faustregel besondere Betonung. Parallelisieren erhöht die Gesamtmenge an Review. Zehn Aufträge kommen mit zehn angehängten Fragen der Sorte „stimmt das eigentlich?“ zurück; das Prüfen wird nicht zusammen mit der Arbeit parallelisiert. Die Obergrenze dafür, wie viele Sie dispatchen, ergibt sich daraus, wie viele Ergebnisse Sie überprüfen können.

Zusammenfassung

Dispatch ist der Vorgang, aus der agent view (claude agents) heraus eine unabhängige Hintergrund-Session zu starten, und es ist eine Research Preview (v2.1.139 oder neuer). Ein Prompt wird zu einer Session, nie zu einer Rückfrage.

Das Herz des Sicherheitsmodells ist die Isolation über worktrees. Vor dem Schreiben zieht die Session nach .claude/worktrees/ um, und von dort an wird gemeinsam gelesen und getrennt geschrieben. Bearbeitungen, Befehle und git-Umlenkungen, die den Haupt-Checkout erreichen würden, werden von drei Prüfungen abgeschnitten, und dieser Schutz wird an jeden Subagent vererbt, den die Session erzeugt.

Aber drei Dinge kommen aus der Isolation heraus. Eine Zustimmung mit „nicht mehr fragen“ wird auf der Hauptseite gespeichert, gilt in jedem worktree und überlebt dessen Löschung. Eine Session zu löschen, vernichtet nicht committete Arbeit. .worktreeinclude kopiert Ihre Geheimnisse einmal pro worktree. Und weil ein worktree keine Mauer auf Betriebssystemebene ist, bleibt alles außerhalb des Repositorys sowie das Netzwerk ungeschützt — dafür ist die Sandbox zuständig.

FAQ

Q1. Gibt es in Claude Code tatsächlich eine Funktion namens „Dispatch“?

Nicht als eigenständigen Funktionsnamen. Dispatch ist der Name einer Operation innerhalb der agent view. Die offizielle Dokumentation beschreibt agent view als die Funktion, mit der Sie „viele Claude-Code-Sessions von einem Bildschirm aus dispatchen und verwalten“ können. Der Befehl, der sie öffnet, lautet claude agents.

Q2. Sind /agents und claude agents dasselbe?

Nein. Die Dokumentation warnt direkt davor: Trotz des ähnlichen Namens ist /agents nicht claude agents. claude agents ist der Shell-Befehl, der die agent view öffnet. /agents öffnet seit v2.1.198 überhaupt kein Panel mehr — es sagt Ihnen nur noch, wo Ihre Subagent-Definitionsdateien liegen.

Q3. Kann eine dispatchte Session meine Hauptarbeitskopie kaputt machen?

Was den Haupt-Checkout desselben Repositorys angeht, sind Sie strukturell geschützt. Dateibearbeitungen, Arbeitsverzeichnisse von Befehlen und git-Umlenkungen werden von den drei Prüfungen blockiert, und derselbe Schutz umfasst jeden Subagent, den die Session erzeugt. Allerdings fallen Dateien außerhalb des Repositorys und das Netzwerk nicht in den Geltungsbereich, und unter PowerShell greift nur die Prüfung des Arbeitsverzeichnisses.

Q4. Was macht paralleles Laufenlassen mit den Kosten?

Sie steigen ungefähr proportional zur Anzahl. Die offiziellen Einschränkungen sagen genau das: Zehn Agenten parallel laufen zu lassen, verbraucht Ihr Kontingent etwa zehnmal so schnell wie einer. Hintergrund heißt nicht billig.

Q5. Kann ich eine Session löschen, sobald sie fertig ist?

Erst committen, dann löschen. Die Dokumentation hält fest, dass von Claude erzeugte worktrees zusammen mit der Session gelöscht werden, wenn Sie diese in der agent view löschen. Ctrl+X stoppt beim ersten Druck und löscht beim zweiten. Das Ergebnis erhalten zu haben, ist nicht dasselbe, wie es übernommen zu haben.

Q6. Kann ich den Berechtigungsmodus bei jedem Dispatch wählen?

Nicht spontan. Verwendet wird der defaultMode aus den Einstellungen dieses Verzeichnisses — oder, wenn Sie einen Subagent dispatcht haben, der permissionMode aus dessen Frontmatter. Ist Ihr üblicher defaultMode locker, dann läuft genau diese Lockerheit unbeaufsichtigt. Sehen Sie Ihre Berechtigungseinstellungen durch, bevor Sie mit Dispatch anfangen.

Q7. Worin unterscheidet sich das von Subagents?

Der Unterschied liegt darin, wer Regie führt. Bei Subagents delegiert Claude innerhalb eines Gesprächs und gibt das Ergebnis an dieses Gespräch zurück. Bei der agent view geben Sie unabhängige Aufgaben ab und sammeln die Ergebnisse anschließend ein. Subagents, die eine Session erzeugt, werden in der agent view nicht als Zeilen angezeigt.

Q8. Was passiert, wenn ich meinen Laptop zuklappe?

Sie halten an. Die offiziellen Einschränkungen sagen, dass Hintergrund-Sessions auf Ihrer Maschine laufen: Sie überstehen den Ruhezustand, aber das Herunterfahren der Maschine beendet sie. Nichts läuft in der Cloud, das ist also nicht das Werkzeug, um einen langen Auftrag über die Mauer zu werfen und nach Hause zu gehen.

Verwandte Artikel