Claude Code Plan Mode: Änderungen vorab durchdenken

Entscheidend ist der Moment vor der Freigabe: Ein übersehener Aufrufer fällt auf, ein bestehender Schnittstellenvertrag bleibt erhalten oder eine unnötige Datenbankänderung entfällt. Ein ausführlicher Plan ist dann nützlich, wenn er eine Entscheidung verändert.

Was leistet Claude Code Plan Mode?

Im Planungsmodus untersucht Claude die Codebasis und schlägt Änderungen vor. Dabei kann Claude Dateien lesen, zur Erkundung Befehle ausführen und den Plan schreiben. Änderungen am Quellcode bleiben normalerweise bis zur Freigabe gesperrt. Das lässt sich mit der Prüfung eines Umbauplans vergleichen, bevor die Handwerker Wände versetzen. Anthropics Planungsablauf.

Die Dokumentation nennt eine wichtige Ausnahme: In einer interaktiven Terminalsitzung, in der Bypass-Berechtigungen verfügbar sind, greifen die Sperren des Planungsmodus nicht. Claude erhält weiterhin die Anweisung zu planen; ein versuchter Schreibzugriff kann jedoch ausgeführt werden. Das gilt auch dann, wenn Bypass mit --allow-dangerously-skip-permissions lediglich verfügbar gemacht, aber nicht als aktiver Modus ausgewählt wurde. Soll der Quellcode bis zur Freigabe unverändert bleiben, muss die Sitzung ohne aktivierte Bypass-Funktion starten. Anthropics Regeln für Berechtigungsmodi.

Planung und Berechtigungssystem greifen ineinander. Der Plan beschreibt, was Claude ändern will. Der Berechtigungsmodus bestimmt, welche Aktionen ohne Rückfrage ausgeführt werden dürfen.

Den Planungsmodus starten und verlassen

Eine Terminalsitzung lässt sich direkt im Planungsmodus starten:

claude --permission-mode plan

In einer laufenden Sitzung stehen die folgenden Möglichkeiten zur Verfügung. Maßgeblich ist die Modusanzeige, nicht eine feste Anzahl von Tastendrücken.

Ausgehend von auto führt die Reihenfolge über default (Manual) und acceptEdits zu plan. Danach folgen verfügbare optionale Modi: zuerst Bypass-Berechtigungen, zuletzt Auto. Für Windows nennt Anthropic Alt+M als Alternative, falls die Node- oder Bun-Laufzeit den VT-Eingabemodus nicht aktiviert. Moduswechsel, Tastenkürzel, Befehlsreferenz.

Sobald Claude einen Plan vorlegt, bietet der Freigabedialog diese Möglichkeiten:

• No, keep planning: Weiterplanen und konkrete Korrekturen vorgeben.
• Yes, manually approve edits: Den Lösungsweg freigeben und Änderungen weiterhin einzeln prüfen.
• Yes, and use auto mode: Den Plan freigeben und im Auto-Modus fortfahren, sofern dieser verfügbar ist.

Ist der Auto-Modus nicht verfügbar, erlaubt die automatische Option stattdessen Dateiänderungen automatisch. Wurde die Sitzung mit aktivierter Bypass-Funktion gestartet, wechselt diese Option zu Bypass-Berechtigungen. Deshalb vor der Auswahl den angebotenen Modus lesen. Die Freigabe beendet den Planungsmodus und startet die Umsetzung mit den gewählten Berechtigungen. Auch Shift+Tab beendet die Planung, gibt den vorgeschlagenen Plan aber nicht frei. Verhalten bei der Planfreigabe.

Planung über eine grafische Oberfläche: In VS Code lässt sich unter dem Eingabefeld die Modusanzeige anklicken und Plan auswählen. Im Code-Tab der Desktop-App sitzt die Modusauswahl neben Send. In JetBrains gelten die CLI-Tastenkürzel im integrierten Terminal. Laut Änderungsprotokoll unterstützt VS Code die Eingabe von /plan ab v2.1.280. Bedienelemente der Oberflächen, offizielles Änderungsprotokoll.

Welche Claude-Code-Einstellungen sind für die Planung wichtig?

Damit Terminalsitzungen eines Projekts im Planungsmodus starten, diesen Eintrag in die vorhandene .claude/settings.json integrieren:

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

Für einen benutzerweiten Standard im Terminal gehört der Eintrag stattdessen in ~/.claude/settings.json. Die Startoption hat Vorrang vor den Einstellungen; Projektvorgaben oder zentral verwaltete Einstellungen können den benutzerweiten Standard überschreiben. VS Code hat eine eigene Starteinstellung: In den VS-Code-Benutzereinstellungen muss "claudeCode.initialPermissionMode": "plan" stehen. Für den anfänglichen Berechtigungsmodus liest die Erweiterung keine Projekteinstellungen. Konfiguration des Startmodus.

Die folgenden zusätzlichen Schlüssel stehen auf der obersten Ebene der Claude-Code-Einstellungen, außerhalb von permissions:

Diese Einstellungen beantworten unterschiedliche Fragen: Wo wird der Plan gespeichert, wie werden Befehle während der Planung geprüft und soll eine Freigabeoption den Gesprächskontext löschen? Einstellungsreferenz, Speicherung von Plänen, Option zum Löschen des Kontexts.

Wer den Kontext löscht, muss Randbedingungen, offene Entscheidungen und Abnahmekriterien im Plan selbst festhalten. Andernfalls beruht die Umsetzung auf Absprachen, auf die sie keinen Zugriff mehr hat.

Wie arbeiten Plan Mode und Claude Code Auto Mode zusammen?

Im Planungsmodus bleibt die Entscheidung über die Umsetzung zur Prüfung offen. Der Auto-Modus reduziert routinemäßige Berechtigungsabfragen, indem ein separates Klassifikatormodell Aktionen bewertet. Dieser Klassifikator prüft eine Aktion unter Berechtigungsgesichtspunkten. Die Planprüfung klärt dagegen, ob der vorgeschlagene Entwurf das richtige Problem löst.

Ist der Auto-Modus verfügbar und useAutoModeDuringPlan aktiviert, prüft dieser Klassifikator auch Shell-Befehle während der Planung. Genehmigte Befehle werden ausgeführt, abgelehnte blockiert. Ist Auto nicht verfügbar oder die Einstellung deaktiviert, lösen Befehle außerhalb des eingebauten Satzes rein lesender Befehle stattdessen eine Rückfrage aus. Löschvorgänge an kritischen Pfaden werden gesondert behandelt; die Bypass-Ausnahme für interaktive Terminalsitzungen hat Vorrang. Planung bedeutet nicht, dass jeder Shell-Befehl ausschließlich lesend arbeitet. Befehle während der Planung.

Bei der Umsetzung steht default für die manuelle Prüfung. acceptEdits erlaubt Änderungen im vorgesehenen Umfang und gängige Dateisystembefehle automatisch, wobei dokumentierte Ausnahmen gelten. auto ergänzt eine Aktionsprüfung im Hintergrund. Keiner dieser Modi beurteilt, ob die Architektur sinnvoll ist. Unser Leitfaden zu Claude Code Auto Mode erläutert diese Berechtigungsentscheidung genauer.

Laut aktueller Dokumentation ist Auto ab v2.1.283 der eingebaute Startmodus für interaktive Terminal- und VS-Code-Sitzungen, abhängig von Konfiguration, Organisationsvorgaben und Verfügbarkeit. Eine explizite Einstellung für den Start im Planungsmodus bleibt deshalb relevant. Aktuelle Regeln für den Startmodus.

Ältere Anleitungen können wesentliche Änderungen übergehen. Anthropics Änderungsprotokoll nennt das Beschreibungsargument für /plan ab v2.1.72, das standardmäßige Ausblenden der Option zum Löschen des Kontexts ab v2.1.81 und ab v2.1.218 die Klassifikatorprüfung von Bash-Befehlen, deren rein lesender Charakter unklar ist, während der Planung mit Auto. Offizielles Änderungsprotokoll.

Praxisbeispiel: Preislogik zusammenführen, berechnete Beträge erhalten

Ein konkretes Refactoring: Eine Anwendung berechnet Checkout-Preise in ihrer API und Verlängerungspreise in einem Hintergrund-Worker. Ziel sind gemeinsame Preisregeln, wobei Rundung und Rabattbehandlung der jeweiligen Aufrufer erhalten bleiben sollen. Der folgende Plan dient der Veranschaulichung. Er ist weder das Ergebnis eines getesteten Repositorys noch eine garantierte Claude-Ausgabe.

Im Planungsmodus wird zunächst die tatsächliche Randbedingung formuliert:

Angenommen, die relevanten Projektdateien sehen so aus:

Ein plausibler erster Entwurf könnte eine gemeinsame Berechnungsfunktion extrahieren, beide Aufrufer umstellen, die alten Hilfsfunktionen löschen und die Tests anpassen. Das klingt aufgeräumt. Es ist aber unvollständig: Was passiert, wenn der Checkout an einer anderen Stelle rundet als die Verlängerung?

Den Plan vor der Freigabe bearbeiten. Bei der Prüfung lässt sich mit Ctrl+G der frühe Löschschritt durch diese Korrektur ersetzen:

Danach den Plan speichern und zurückkehren. Braucht der Vorschlag weitere Arbeit, über die Option zum Weiterplanen Claude auffordern, den gesamten Plan mit der Korrektur in Einklang zu bringen. Der widersprüchliche Löschschritt muss entfallen; ein zusätzlicher Warnhinweis darunter genügt nicht. Das direkte Bearbeiten und die anschließende weitere Planung sind dokumentierte Bestandteile des Ablaufs. Anthropics Empfehlungen zu Erkundung, Planung und Umsetzung.

Der überarbeitete Plan sollte nun eine umsetzbare Abfolge enthalten:

1. Das bisherige Verhalten absichern. Testfälle für die aktuellen Checkout- und Verlängerungsbeträge ergänzen, einschließlich Rundungsgrenzen, Rabatten und ungültigen Eingaben. Unklare erwartete Ergebnisse vor dem nächsten Schritt klären.
2. Die gemeinsame Preislogik hinter Adaptern einführen. Eingaben, Ausgaben und Fehlerverhalten jeder bestehenden Funktion beibehalten. Unterschiede zwischen den Aufrufern ausdrücklich abbilden.
3. Die Aufrufer einzeln umstellen. Zuerst den Checkout anpassen und prüfen, danach die Verlängerung. Unabhängige Aufräumarbeiten aus diesen Änderungen heraushalten.
4. Das Ergebnis prüfen. Die tatsächlichen Preis-, API- und Worker-Prüfungen des Projekts ausführen, danach die üblichen Typ- und Integrationsprüfungen. Im Diff auf veränderte öffentliche Antworten oder eine geänderte Bedeutung der Abrechnungsbeträge achten.
5. Einen Rückfallweg erhalten. Die Kompatibilitätsschicht bis zum erfolgreichen Abschluss der Prüfungen beibehalten. Überholten Code in einem eigenen, separat prüfbaren Schritt entfernen.

Für dieses Beispiel anschließend den Plan mit manueller Prüfung der Änderungen freigeben. Nach der Umsetzung werden die tatsächlichen Änderungen und Testergebnisse mit dem Plan abgeglichen. Ein Plan, der Tests erwähnt, bleibt ein Vorschlag, solange diese Prüfungen nicht gelaufen sind.

Der wirtschaftliche Nutzen ist hier konkret: Eine Verhaltensänderung wird erkannt, bevor beide Aufrufer und ihre Tests umgeschrieben sind. Dafür braucht es keine spekulative Prozentangabe zur Token-Ersparnis.

Bei welchen Aufgaben lohnt sich die Planung besonders?

Vorrang haben Aufgaben, bei denen sich ein früher Entwurfsfehler weit ausbreiten kann. Nach dem voraussichtlichen Nutzen geordnet würde ich vor allem diese Situationen zuerst planen:

Das sind vorgeschlagene Arbeitsabläufe, keine gemessenen Ergebnisse. Sie folgen Anthropics Empfehlung, bei unklarem Lösungsweg, Änderungen über mehrere Dateien oder unbekanntem Code zuerst zu planen. Bei einem Tippfehler, einer bereits feststehenden Log-Anweisung oder einer klar abgegrenzten Umbenennung genügt der direkte Änderungsauftrag. Wann Anthropic zur Planung rät.

Für die Kostenabwägung hilft ein Vergleich beider Abläufe. Bei der direkten Umsetzung fallen Implementierungs- und Prüfaufwand an, bevor ein falscher Ansatz auffällt. Planung zieht Aufwand für Untersuchung und Planprüfung vor, kann dafür aber diese Nacharbeit vermeiden.

Planung lohnt sich, wenn Arbeitsaufwand und zusätzliche Modellnutzung weniger kosten als die erwartete Nacharbeit, die sie verhindert. Das ist eine Entscheidungsregel, kein Einsparungsbenchmark von Anthropic. Maßgeblich sind die eigenen Entwicklungskosten und die tatsächliche Nutzung. Würde der Plan lediglich eine bereits präzise formulierbare Änderung wiederholen, lässt er sich überspringen.

Welche Produkte lassen sich darauf aufbauen?

Das größte Potenzial sehe ich in einem Prüfpaket für Team-Refactorings: Aus einer vorgeschlagenen Änderung entstehen eine Dateizuordnung, festgehaltene Schnittstellenverträge, Abnahmeprüfungen und Hinweise zum Rückfallweg, mit denen Reviewer direkt arbeiten können. Eine technische Leitung könnte für einheitliche Qualität über mehrere Entwickler hinweg bezahlen, besonders bei gemeinsamer Geschäftslogik.

Die am 12. Oktober 2026 abgerufenen US-Keyword-Schätzungen von DataForSEO beziffern „code refactoring tools“ auf 170 Suchanfragen pro Monat. Das ist ein bescheidenes Signal für Interesse an der Aufgabe, kein Beleg für Kaufbereitschaft bei einem Produkt zur Planprüfung. Die kleinste sinnvolle Version könnte einen exportierten Plan und eine Dateiübersicht des Repositorys entgegennehmen, nach fehlenden Aufrufern oder unbelegten Annahmen suchen und eine Vorlage für den Pull Request erstellen. Die Hürde: Allgemeine Pläne erzeugt Claude Code bereits selbst. Das Produkt muss teamspezifische Prüfungen und eine nützliche Prüfunterlage liefern, um seinen Einsatz zu rechtfertigen.

Eine engere Möglichkeit ist ein Vorbereitungspaket für Migrationen in Agenturen: Vor der Kalkulation eines Upgrades entstehen ein Verzeichnis betroffener Komponenten, eine Checkliste für den schrittweisen Rollout und eine Liste offener Entscheidungen. Dieselbe DataForSEO-Abfrage schätzt 20 monatliche US-Suchanfragen für „code migration tools“. Bei einer so kleinen kommerziellen Suchnachfrage sollte die Idee mit bestehenden Kunden validiert werden, bevor daraus ein breites Produkt entsteht.

Die kleinste Version könnte sich auf eine Migrationsfamilie beschränken und zu jeder Änderung Links auf die maßgebliche Herstellerdokumentation verlangen. Die Schwierigkeit liegt in der Pflege: Versionsspezifische Migrationsregeln veralten schnell. Plan Mode kann die Untersuchung unterstützen, liefert aber kein geprüftes Regelwerk für Migrationen. Diese Produktideen sind durch Suchnachfrage gestützte Hypothesen, keine Umsatzprognosen.

Ultraplan ist nicht mehr verfügbar

Anthropic hat die experimentelle Ultraplan-Vorschau entfernt, einschließlich /ultraplan, des auslösenden Schlüsselworts und der Option, einen Plan bei der Freigabe mit Ultraplan im Web verfeinern zu lassen. Auf der zugehörigen Seite steht, dass solche Vorschauen experimentell sind und abhängig vom Feedback geändert oder entfernt werden können. Für Planungsabläufe verweist sie auf den lokalen Planungsmodus und Claude-Code-Cloud-Sitzungen. Anthropics aktuelle Ultraplan-Seite.

Häufige Fragen vor der nächsten Sitzung

Am Montag bietet sich das nächste Refactoring mit mehreren Aufrufern als Einstieg an: den Planungsmodus starten und nach dem zu erhaltenden Verhalten, den betroffenen Dateien, den Prüfungen und dem Rückfallweg fragen. Vor der Freigabe die schwächste Annahme überarbeiten. Ergänzend helfen die allgemeinen Prüfgewohnheiten aus Claude Code Best Practices.

Braucht das Team einen wiederholbaren Planungs- und Prüfablauf, können wir ihn in den Entwicklungsprozess integrieren.