Claude Code Plan Mode: erst planen, dann editieren

Du kennst das Muster: Claude bekommt eine halbwegs klare Aufgabe, legt sofort los, und nach zehn Minuten liegen Änderungen in sechs Dateien, die auf einer falschen Annahme aufbauen. Zurückrollen geht, aber der Kontext ist dann voll mit einem gescheiterten Versuch. Plan Mode und ein Spec-first-Ablauf setzen genau davor an: erst klären, was gebaut wird, dann editieren. Stand ist die Claude-Code-Doku zu Permission Modes und den Best Practices im November 2026.

Was Plan Mode technisch macht

Plan Mode ist einer der Permission Modes, mit dem Config-Wert plan. Claude liest Dateien, führt Shell-Befehle zum Erkunden aus und schreibt einen Plan, ändert aber deinen Source nicht. Edits bleiben gesperrt, bis du den Plan freigibst.

Rein kommst du auf drei Wegen:

# beim Start
claude --permission-mode plan

# in der Session: Shift+Tab, bis die Statusleiste "⏸ plan mode on" zeigt
# oder nur für einen Prompt: /plan als Präfix

Ein weiteres Shift+Tab verlässt den Modus, ohne einen Plan freizugeben. Der Zyklus läuft dabei default → acceptEdits → plan, optionale Modi hängen sich hinten an.

Was mit Shell-Befehlen während der Planung passiert, hängt von der Session ab. Ist auto mode verfügbar und die Einstellung useAutoModeDuringPlan an (Default), prüft der Classifier die Befehle statt dich zu fragen, abgelehnte werden geblockt. Ohne auto mode oder mit useAutoModeDuringPlan aus fragt Claude Code bei jedem Befehl außerhalb des eingebauten Read-only-Sets nach, auch mit aktivem Sandbox-Auto-Allow. Wie sich das mit deinen eigenen Regeln verträgt, steht im Artikel zu settings.json Permissions.

Die Lücke: Plan Mode mit bypassPermissions

Der wichtigste Trade-off steht etwas versteckt in der Doku. In interaktiven Terminal-Sessions, in denen bypassPermissions verfügbar ist, setzt Claude Code die Sperren des Plan Mode nicht durch. Claude wird weiterhin angewiesen, nur zu planen. Versucht es trotzdem einen Edit oder einen Befehl, läuft der ohne Rückfrage. Nur explizite ask-Regeln und erkannte Critical-Path-Removals mit rm und rmdir fragen noch nach. Auch Schreibzugriffe auf geschützte Pfade wie .git oder .claude werden dort automatisch freigegeben.

Ohne interaktives Terminal bleiben die Sperren aktiv: in claude -p, in Agent-SDK-Sessions und im Chat-Panel der VS-Code-Extension. Wenn du Plan Mode als Guardrail verstehst, startest du interaktive Sessions also nicht so, dass Bypass im Modus-Zyklus landet. Für harte Regeln, die unabhängig vom Modus gelten, sind Deny-Regeln oder Claude Code Hooks das richtige Werkzeug.

Plan freigeben, nachschärfen, Kontext leeren

Ist der Plan fertig, legt Claude ihn vor und fragt nach dem nächsten Schritt:

• Yes, and use auto mode: freigeben und im auto mode weiterarbeiten. Ohne verfügbaren auto mode heißt die Option Yes, auto-accept edits.
• Yes, manually approve edits: freigeben, jeden Edit einzeln bestätigen.
• No, keep planning: im Plan Mode bleiben und Änderungen am Plan diktieren.

Mit Ctrl+G öffnest du den Plan in deinem Standard-Editor und änderst ihn direkt, bevor Claude loslegt. Das ist oft schneller als drei Runden Korrektur im Chat. Mit showClearContextOnPlanAccept bekommt die Liste eine zusätzliche erste Option, die den Plan freigibt und den Planungskontext leert. Das lohnt sich, wenn die Erkundung viel Output erzeugt hat, den die Umsetzung nicht braucht. Mehr zur Kontext-Hygiene im Artikel zu Autocompact, /compact und /clear.

Plan-Dateien landen in ~/.claude/plans/ oder im Verzeichnis aus plansDirectory.

Plan Mode als Projekt-Default

Für Repos, in denen du nie ohne Plan editieren willst, setzt du den Startmodus im Projekt:

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "plan"
  }
}

Ein Projektwert schlägt ~/.claude/settings.json. Zwei Ausnahmen: Die VS-Code-Extension liest für den Startmodus keine Projekt-Settings, dort setzt du claudeCode.initialPermissionMode auf plan in deinen User-Settings. In der Desktop-App gilt Plan aus dem Mode-Selector nur für die aktuelle Session.

Spec-first: wenn du selbst noch nicht weißt, was du willst

Plan Mode setzt voraus, dass die Aufgabe klar genug ist, um sie zu planen. Ist sie das nicht, empfiehlt die Doku einen Schritt davor: Lass Claude dich interviewen. Es stellt Multiple-Choice-Fragen zu den offenen Punkten, im Doku-Beispiel eines Rate Limiters etwa Limits pro User oder pro Key, was mit Requests über dem Limit passiert und was außerhalb des Scopes liegt. Das geht so lange, bis die Antworten eine Spec ergeben.

Dann kommt der entscheidende Teil: SPEC.md speichern und eine frische Session starten, die daraus baut. Die Umsetzung beginnt so mit sauberem Kontext und einer schriftlichen Definition of Done. Dieselbe Datei ist später die Referenz fürs Review. Die Doku zeigt dafür einen Reviewer in .claude/agents/, der nur tools: Read, Grep, Glob bekommt und das Ergebnis gegen SPEC.md vergleicht. Dass er nichts editieren kann, erzwingt Claude Code, nicht der Prompt.

Umgekehrt gilt: Wenn du nur explorierst, ist ein vager Prompt völlig in Ordnung. Dann korrigierst du unterwegs etwas mehr, das ist der Trade-off.

Was das für deinen Workflow bedeutet

Bevor du einen Task unbeaufsichtigt laufen lässt, nennt die Doku als erste Frage, ob der Agent weiß, wie “fertig” aussieht: ein Zielzustand, ein Spec-File oder ein fehlschlagender Test, der grün werden muss. Plan Mode und Spec-first sind die zwei Wege dorthin:

1. Unklare Anforderung: Interview, SPEC.md, frische Session.
2. Klare Anforderung, nicht-trivialer Change: /plan, Plan mit Ctrl+G nachschärfen, dann freigeben.
3. Riskantes Repo: defaultMode: "plan" im Projekt, Bypass nicht in den interaktiven Zyklus holen.
4. Nach der Umsetzung: Read-only-Reviewer gegen die Spec, mit Belegen statt “alle Tests grün”. Mehr dazu im Artikel zu Agentic Verification.

Du willst wissen, ob dein Repo Plan Mode wirklich als Sperre nutzt oder ob Bypass, Default-Modus und Hooks sich gegenseitig aushebeln? Das Agent-Setup-Review prüft settings.json, Agents und Hooks zusammen und liefert priorisierte Änderungsvorschläge. Setup-Review anfragen.