Claude Code Plan Mode: erst den Plan, dann die Änderung

Es gibt zwei Arten, mit einem Coding-Agenten zu arbeiten. Die eine beginnt mit einem Satz wie „bau mir das ein" und endet damit, dass man zwanzig Minuten später einen Diff über neun Dateien vor sich hat und nicht mehr sagen kann, an welcher Stelle die Sache abgebogen ist. Die andere beginnt damit, dass der Agent erst einmal nichts tut, außer zu lesen und aufzuschreiben, was er vorhat.

Genau das ist der Plan Mode in Claude Code. Er ist kein Zusatzwerkzeug und kein Plugin, sondern einer von sechs Berechtigungsmodi, und er verschiebt den Moment der Kontrolle nach vorn: Statt eine fertige Änderung zu prüfen, prüft ihr einen Vorschlag in Prosa. Das ist der eigentliche Grund, warum der Modus im Team so viel wert ist. Einen Plan kann auch jemand beurteilen, der den Diff nicht liest.

Dieser Beitrag setzt voraus, dass Claude Code bei euch schon läuft. Falls nicht, führt unsere Installationsanleitung dorthin, und der Überblick Was ist Claude Code? ordnet das Werkzeug insgesamt ein.

Was Plan Mode technisch macht

Im Plan Mode recherchiert Claude eine Änderung und schlägt sie vor, ohne sie vorzunehmen. Es liest Dateien, führt Shell-Befehle zum Erkunden aus und schreibt daraus einen Plan, bearbeitet eure Quelldateien aber nicht. Bearbeitungen bleiben blockiert, bis ihr den Plan genehmigt, und zwar unabhängig davon, wie ihr die übrigen Berechtigungen gesetzt habt.

Für Genehmigungsaufforderungen gilt derselbe Ablauf wie im manuellen Modus, mit einer Ausnahme: Ist der Auto-Modus für euer Konto verfügbar und die Einstellung useAutoModeDuringPlan aktiv, was der Standard ist, dann winkt ein Klassifizierer lesende Befehle wie Suchen und Dateizugriffe ohne Nachfrage durch. Das ist der Punkt, an dem Plan Mode angenehm wird: Die Erkundung läuft ohne Unterbrechung, die Schreibsperre bleibt trotzdem stehen.

Eine ehrliche Einordnung gehört dazu, weil sie erklärt, was ihr gelegentlich beobachten werdet. Eine viel gelesene technische Analyse hat gezeigt, dass Claude im Plan Mode dieselbe Werkzeugliste behält wie sonst und die Beschränkung wesentlich über die Systemanweisung durchgesetzt wird, nicht dadurch, dass die Schreibwerkzeuge verschwinden. Praktisch heißt das: Die von Anthropic dokumentierte Sperre für Bearbeitungen greift, aber der Agent formuliert im Plan Mode manchmal so, als wolle er gleich loslegen. Das ist kein Fehler, sondern die Bauart. Wer weiß, dass der Modus im Kern eine sehr konsequent gesetzte Anweisung ist, schreibt seine eigenen Prompts entsprechend deutlich.

Vier Wege in den Plan Mode

Der schnellste Weg ist die Tastatur. Shift+Tab schaltet in laufender Sitzung durch die Modi, ein weiteres Shift+Tab verlässt den Plan Mode wieder, ohne einen Plan zu genehmigen. In den Erweiterungen für VS Code und JetBrains sowie in der Desktop-App gibt es dafür einen Moduswahlschalter.

Soll nur ein einzelner Prompt geplant werden, stellt ihr ihm /plan voran. Das ist der Weg für den Zwischenfall: Ihr arbeitet normal, stoßt auf eine Stelle, die euch zu groß vorkommt, und wollt für genau diese eine Frage einen Plan sehen.

Wollt ihr eine Sitzung von vornherein im Plan Mode beginnen, startet ihr Claude Code direkt so:

claude --permission-mode plan

Der vierte Weg ist der interessanteste und kommt weiter unten ausführlich: defaultMode in der .claude/settings.json macht den Plan Mode zum Standard für ein ganzes Projekt, für alle, die es auschecken.

Was am Ende eines Plans passiert

Ist der Plan fertig, legt Claude ihn vor und fragt, wie es weitergehen soll. Fünf Wege stehen zur Wahl: genehmigen und im Auto-Modus starten, genehmigen und Bearbeitungen automatisch akzeptieren, genehmigen und jede Bearbeitung einzeln prüfen, mit Feedback weiterplanen oder den Plan mit Ultraplan im Browser verfeinern.

Wichtig an dieser Stelle: Die Genehmigung beendet den Plan Mode und setzt die Sitzung auf genau den Berechtigungsmodus, den die gewählte Option beschreibt. Ihr entscheidet also mit einem Tastendruck nicht nur „ja, so machen wir das", sondern auch, wie eng ihr die Umsetzung begleiten wollt. Wer den Plan gründlich gelesen hat, kann guten Gewissens durchlaufen lassen. Wer ihn nur überflogen hat, sollte die dritte Option nehmen.

Zwei Handgriffe lohnen sich hier besonders. Mit Ctrl+G öffnet ihr den vorgeschlagenen Plan in eurem Standard-Texteditor und bearbeitet ihn direkt, bevor Claude weitermacht. Das ist deutlich schneller, als eine Korrektur in Prosa zu diktieren, und es ist der Weg, mit dem sich ein zu 80 Prozent richtiger Plan in einer Minute retten lässt. Und ist die Einstellung showClearContextOnPlanAccept aktiv, bietet jede Genehmigungsoption zusätzlich an, den Planungskontext vorher zu löschen. Dazu gleich mehr.

Nebenbei benennt Claude die Sitzung beim Akzeptieren automatisch nach dem Planinhalt, sofern ihr nicht schon mit --name oder /rename einen Namen vergeben habt. Klingt nach Kosmetik, ist aber der Unterschied zwischen einer Sitzungsliste, in der man etwas wiederfindet, und einer, in der man es nicht tut.

Plan Mode im Gefüge der sechs Modi

Plan Mode einzeln zu erklären, führt in die Irre. Er ist eine von sechs Stufen zwischen voller Kontrolle und voller Autonomie, und die Genehmigungsoptionen am Ende eines Plans verweisen direkt auf die anderen Stufen. Wer sie nicht kennt, trifft die Entscheidung blind.

Zwei Details, die in fast allen Anleitungen fehlen. Erstens heißt der strengste Modus in der Konfiguration default, in der Oberfläche und in claude --help aber Manual; seit Version 2.1.200 akzeptiert die CLI manual überall als Alias. Zweitens gilt in jedem Modus außer bypassPermissions, dass Schreibvorgänge in geschützte Pfade nie automatisch genehmigt werden. Der Repository-Zustand und die Claude-Konfiguration selbst bleiben also auch dann geschützt, wenn ihr im Auto-Modus arbeitet.

Wann sich Planen lohnt, und wann nicht

Plan Mode kostet Zeit, bevor er welche spart. Für kleine Änderungen ist er schlicht Overhead. Die brauchbarste Faustregel lautet: Wenn ihr die Aufgabe in einem Satz vollständig beschreiben könnt und wisst, welche Datei betroffen ist, plant nicht. Ein Tippfehler in einer Fehlermeldung braucht keinen Plan.

Lohnend wird es in vier Situationen. Erstens bei fremdem Code, in den ihr euch selbst erst einlesen müsstet: Der Plan ist dann nebenbei die Zusammenfassung, die ihr sowieso gebraucht hättet. Zweitens, wenn mehr als eine Handvoll Dateien betroffen ist, weil dort die Entscheidungen stecken, die man später teuer zurückdreht. Drittens bei architektonischen Weichen, etwa der Frage, ob ein neues Modul entsteht oder ein bestehendes wächst. Und viertens immer dann, wenn jemand anderes die Änderung verantworten muss als der, der sie anstößt.

Der vierte Fall ist im Mittelstand der häufigste und wird in den englischsprachigen Anleitungen praktisch nicht behandelt. Dort schreiben Entwickler für Entwickler an der eigenen Codebasis. In einem Unternehmen, das gerade anfängt, mit Coding-Agenten zu arbeiten, sieht es anders aus: Eine Person führt das Werkzeug ein, mehrere andere tragen die Verantwortung für das System, und die können einen Diff über neun Dateien nicht bewerten. Einen Plan in Prosa können sie bewerten. Genau deshalb ist Plan Mode dort weniger eine Produktivitätsfrage als ein Freigabemechanismus.

Kontext löschen oder behalten

Beim Planen liest Claude viel: Dateien, Suchtreffer, Ausgaben von Erkundungsbefehlen. All das steht anschließend noch im Kontext, wenn die Umsetzung beginnt. Ist showClearContextOnPlanAccept aktiv, bietet euch jede Genehmigungsoption an, diesen Planungskontext vorher zu löschen und mit dem Plan als einziger Vorgabe zu starten.

Beides hat seine Berechtigung. Für das Löschen spricht, dass der Plan dann die unstrittige Anweisung ist und keine halbfertige Überlegung aus der Erkundungsphase mehr dagegen steht. Dafür muss der Plan alles enthalten, was für die Umsetzung nötig ist, also auch die Dateipfade und die Randbedingungen. Für das Behalten spricht der Fall, dass die Erkundung Details zutage gefördert hat, die im Plan nur verkürzt stehen, etwa eine seltsame Altlast in einer Hilfsfunktion.

Der pragmatische Umgang: Wenn ihr den Plan mit Ctrl+G ohnehin durchgeht, ergänzt dort die zwei, drei Details, die euch wichtig sind, und löscht dann den Kontext. Was in einer Datei steht, die Claude beim nächsten Zugriff neu liest, muss nicht im Kontext mitgeschleppt werden. Für Vorgaben, die in jedem Lauf gelten sollen, ist ohnehin die CLAUDE.md im Projekt der richtige Ort und nicht der Sitzungskontext.

Planen mit Subagents

Das Erkunden einer großen Codebasis füllt den Kontext mit Dateiinhalten, die im Plan selbst nie auftauchen. Dafür gibt es Subagents: Ihr sagt im Prompt schlicht, dass ein Subagent eine Frage untersuchen soll, dieser liest in seinem eigenen Kontextfenster und meldet nur die Zusammenfassung zurück.

Im Plan Mode ist das die natürliche Arbeitsteilung. Die Vorarbeit, also „wie hängt unsere Auftragsverarbeitung zusammen", geht an einen Subagent. Der Hauptlauf bekommt das Ergebnis und schreibt daraus den Plan. Der Kontext bleibt schlank, und das Löschen beim Genehmigen wird zur Formalität, weil dort ohnehin kaum Ballast liegt. Wer Claude Code darüber hinaus an eigene Systeme anbinden will, findet den Einstieg in Claude Code und MCP.

Plan Mode als Team-Default

Bis hierhin war Plan Mode eine persönliche Arbeitsweise. Der Schritt, der ihn zum Governance-Werkzeug macht, ist eine einzige Einstellung. In der .claude/settings.json eines Projekts:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Weil diese Datei im Repository liegt, gilt die Einstellung für alle, die das Projekt auschecken. Jede Sitzung startet damit im Plan Mode, und wer etwas ändern will, muss vorher einen Plan genehmigen. Das ist kein Verbot, sondern eine Voreinstellung: Shift+Tab kommt weiterhin überall heraus. Genau das ist der Punkt. Eine Voreinstellung wirkt, ohne dass jemand sie durchsetzen muss.

Für Unternehmen, die den Einsatz von KI-Werkzeugen dokumentieren müssen, hat das einen zweiten Nutzen. Ein Plan ist ein Artefakt in natürlicher Sprache: prüfbar, kommentierbar und, wenn ihr ihn mit Ctrl+G in eine Datei zieht, ablegbar. Wer nachweisen muss, dass Änderungen an einem produktiven System nicht unbesehen von einem Agenten eingespielt werden, hat mit dem genehmigten Plan genau diesen Nachweis. Das ersetzt keine Freigabeprozesse, aber es füllt sie mit etwas, das man lesen kann.

Sinnvolle Ergänzung: Legt in dieselbe .claude/settings.json die Berechtigungsregeln für die Werkzeuge, die bei euch ohne Rückfrage laufen dürfen. Dann ist der Plan Mode die Grundstellung und die Freigaben sind explizit statt gewachsen.

Fünf Fehler, die wir immer wieder sehen

Den Plan nur überfliegen und dann durchlaufen lassen. Das ist der teuerste Fehler, weil er den ganzen Modus entwertet. Wenn ihr den Plan nicht lest, spart ihr euch das Planen besser ganz und arbeitet mit engerer Begleitung in acceptEdits.

Zu vage fragen. Ein Plan ist nur so gut wie die Aufgabe. „Mach den Import robuster" liefert einen Plan, der hübsch aussieht und nichts entscheidet. „Der Import bricht bei leeren Pflichtfeldern ab, ich will eine Fehlerzeile pro Datensatz statt eines Abbruchs" liefert einen, über den man streiten kann.

Korrekturen diktieren statt tippen. Ctrl+G ist zwei Tasten weit weg. Drei Sätze im Editor zu ändern, ist schneller und eindeutiger, als sie in einer Rückfrage zu beschreiben.

Alles planen. Plan Mode auf jede Kleinigkeit anzuwenden, erzeugt Planungsmüdigkeit, und Planungsmüdigkeit führt zu Fehler eins. Die Ein-Satz-Regel ist ernst gemeint.

Den Modus persönlich halten. Solange Plan Mode eine Tastenkombination ist, die eine Person kennt, ist er eine Gewohnheit. Erst als defaultMode im Repository wird er zu etwas, worauf man sich verlassen kann.

Fazit

Plan Mode ist die billigste Kontrolle, die Claude Code anbietet. Er kostet ein paar Minuten Lesen und liefert dafür einen Prüfpunkt an der Stelle, an der Korrekturen noch nichts kosten. Für einzelne Entwickler ist er eine gute Gewohnheit bei größeren Aufgaben. Für Unternehmen, die gerade anfangen, Coding-Agenten ernsthaft einzusetzen, ist er mehr: der Mechanismus, mit dem sich Verantwortung und Ausführung sauber trennen lassen.

Der pragmatische Einstieg besteht aus zwei Schritten. Arbeitet eine Woche lang mit Shift+Tab, immer wenn eine Aufgabe mehr als eine Datei betrifft. Wenn sich das bewährt hat, schreibt defaultMode in die .claude/settings.json und committet sie. Ab dann gilt die Arbeitsweise für alle, ohne dass jemand daran erinnern muss.