Claude-Code-Modi im Vergleich: Warum der Plan-Modus tot ist und was ihn ersetzt

Letzte Woche landete ein Beitrag mit dem Titel Plan mode is dead auf der Startseite von Hacker News und sammelte 576 Punkte und fast 500 Kommentare. Das Timing war kein Zufall. Wenige Tage später machte Claude Code v2.1.283 den Auto Mode zum eingebauten Startmodus für interaktive Terminal- und VS-Code-Sitzungen, in jedem Plan und bei jedem Anbieter. Das Ritual, mit dem viele Entwickler ihre Arbeit beginnen — Shift+Tab drücken, bis unten plan mode on steht — ist nicht mehr der Punkt, an dem eine Sitzung startet.

Vorweg, damit kein Missverständnis entsteht: Der Plan-Modus wurde weder entfernt noch als veraltet markiert. Shift+Tab, das Präfix /plan und --permission-mode plan funktionieren weiterhin. Gestorben ist nur seine Rolle als selbstverständlicher erster Schritt.

Die Debatte dreht sich vor allem um Geschmacksfragen im Workflow. Spannender ist, was darunter liegt: Der Plan-Modus war nie eine Sicherheitsgrenze, und die Entscheidung, was Ihr Agent tun darf, liegt nicht mehr bei Ihnen, sondern bei einem Klassifikator-Modell, einem Regelwerk und einer Sandbox des Betriebssystems. Dieser Leitfaden vergleicht alle sechs Modi danach, was sie wirklich erlauben, zeigt die drei Fakten, die den Plan-Modus als Standard beendet haben, und endet mit der Konfiguration, die ich selbst einsetzen würde.

Die sechs Modi auf einen Blick

Ein Berechtigungsmodus beantwortet genau eine Frage: Wer gibt jede Aktion frei? Alles andere folgt daraus. Die Übersicht basiert auf der offiziellen Dokumentation der Berechtigungsmodi und dem Changelog von Claude Code, Stand v2.1.283.

Fünf Details, die nicht in die Tabelle passen:

• Manual heißt jetzt so. Seit v2.1.200 zeigt die CLI den Modus default als Manual an und akzeptiert manual als Alias, --permission-mode manual und "defaultMode": "manual" funktionieren also beide.
• acceptEdits hat einen Stolperdraht. Seit v2.1.160 fragt der Modus trotzdem nach, bevor er Build-Konfigurationen schreibt, die Code ausführen können — .npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, .devcontainer/.
• Geschützte Pfade werden nie automatisch genehmigt, außer im Bypass: .git, .claude, .vscode, .idea, .husky, Shell-rc-Dateien, .npmrc, .mcp.json und weitere. Im Auto Mode gehen diese Schreibzugriffe an den Klassifikator, in dontAsk werden sie abgelehnt.
• Deny-Regeln schlagen jeden Modus, auch Bypass. Allow-Regeln bewirken im Bypass nichts.
• Löschbefehle auf kritische Pfade — rm -rf ~, rm -rf /, ein Glob unter einer leeren Variable wie rm -rf "$DIR"/* — genehmigt kein Modus, keine Allow-Regel und kein Hook automatisch.

Modi wechseln — und wo welche Einstellung ignoriert wird

Im Terminal wechselt Shift+Tab zwischen Manual → acceptEdits → plan → zurück zu Manual. Optionale Modi reihen sich nach plan ein: zuerst bypassPermissions (nur wenn Sie mit aktiviertem Bypass gestartet haben), dann auto (sofern verfügbar). Aus Auto führt der erste Tastendruck zurück zu Manual. dontAsk taucht nie im Zyklus auf, Sie setzen ihn mit --permission-mode dontAsk.

Weitere Einstiege, die man kennen sollte:

• claude --permission-mode plan startet direkt in einem Modus; /plan fix the auth race aktiviert den Plan-Modus für einen einzelnen Prompt.
• Ctrl+G öffnet den vorgeschlagenen Plan im Editor, damit Sie ihn vor der Freigabe ändern können.
• In Manual und acceptEdits kann eine Bash-Rückfrage Yes, and switch to auto mode anbieten (ab v2.1.247).

Wo defaultMode steht, ist wichtiger, als viele denken. Ein Repository kann Sie nicht in die Autonomie schalten: "auto" und "bypassPermissions" in .claude/settings.json oder .claude/settings.local.json werden ignoriert, ein Bypass-Wert dort startet die Sitzung in Manual. Setzen Sie die Werte in ~/.claude/settings.json, in Managed Settings oder per Flag. Dasselbe gilt für Auto-Mode-Regeln: Der Klassifikator liest autoMode nie aus Projekteinstellungen, ein eingechecktes Repo kann sich also keine eigene Allow-Liste schreiben.

Warum der Plan-Modus „gestorben” ist: drei Fakten

Der Essay Plan mode is dead von Ayman Nadeem argumentiert, dass Planen nicht dasselbe ist wie ein Plan-Dokument, dass Agenten inzwischen gut genug selbst erkunden und dass der lineare Ablauf planen → freigeben → ausführen durch eine Schleife ersetzt wurde: verstehen, handeln, prüfen, nachfragen, anpassen. Dem kann man zustimmen oder nicht. Diese drei Fakten wiegen schwerer.

1. Der Plan-Modus ist ein Prompt plus Edit-Sperre — keine Sandbox

Im Hacker-News-Thread beschrieb ein Kommentator, der nach eigener Aussage an Claude Code arbeitet, den Plan-Modus im Kern als Erinnerung, die jeder Nachricht angehängt wird: noch keinen Code schreiben. Die Dokumentation ist präziser: Der Plan-Modus lässt Claude lesen, erkunden und einen Plan schreiben und blockiert Edits am Quellcode, bis Sie freigeben. Bei Shell-Befehlen sieht es anders aus:

• Ist Auto Mode verfügbar und useAutoModeDuringPlan aktiv — der Standard —, prüft der Klassifikator die Shell-Befehle während der Planung statt Ihnen. Seit v2.1.218 beurteilt er sogar Befehle, die die statische Analyse nicht als reine Lesebefehle belegen kann.
• In einer interaktiven Terminal-Sitzung mit verfügbarem Bypass werden die Sperren des Plan-Modus gar nicht durchgesetzt. Claude wird weiterhin angewiesen zu planen, aber ein Edit oder Befehl, den es versucht, läuft ohne Rückfrage.
• Der Changelog zeigt, wie dünn die Wand früher war. v2.1.136 behob, dass der Plan-Modus Schreibzugriffe nicht blockierte, wenn eine passende Edit(...)-Allow-Regel existierte. v2.1.212 behob, dass der Plan-Modus dateiverändernde Bash-Befehle wie touch und rm ohne Rückfrage ausführte. v2.1.47 behob, dass der Plan-Modus nach einer Kontextkomprimierung verloren ging.

Wer den Plan-Modus als „sicheren Modus” behandelt hat, hat einer Anweisung vertraut, nicht einer Durchsetzungsebene.

2. Auto Mode wurde zur Eingangstür

Seit v2.1.283 startet eine neue interaktive Sitzung ohne konfigurierten Modus in auto. Nach einem Plan lautet die erste Freigabeoption Yes, and use auto mode. Der Plan-Modus ist jetzt ein Umweg, den Sie bewusst nehmen, und Auto ist das Ziel danach. Die separate Funktion ultraplan hat Anthropic in v2.1.221 entfernt.

3. Der teure Teil des Planens ist zur Modellwahl gewandert

Was der Plan-Modus weiterhin gut kann: Er verschafft Ihnen einen Denkdurchgang vor der Ausführung — und dieser Durchgang hat einen Preis, den Sie steuern können. Der Modell-Alias opusplan nutzt im Plan-Modus Opus und wechselt für die Ausführung zu Sonnet. Über die Anthropic API heißt das: Opus 5.5 für 4/20 US-Dollar pro Million Input-/Output-Tokens für das Denken und Sonnet 5 für 2/10 US-Dollar für das Tippen. Das ist der bessere Hebel als ein Moduswechsel: Geld für Urteilsvermögen ausgeben, bei den Tastenanschlägen sparen.

Wann der Plan-Modus trotzdem gewinnt

„Tot” ist eine Schlagzeile. In vier Fällen würde ich weiterhin bewusst zum Plan-Modus greifen:

1. Große Änderungen über viele Dateien. Planen, mit der Option freigeben, die den Planungskontext leert (dafür showClearContextOnPlanAccept aktivieren), dann aus einem sauberen Fenster ausführen. So vermeiden Sie den Drift, der entsteht, wenn eine lange Aufgabe mittendrin komprimiert wird.
2. Eine Codebasis, die Sie noch nicht kennen. Ein erzwungener Erkundungsdurchgang vor dem ersten Edit fängt falsche Annahmen ab, solange sie noch billig sind.
3. Parallele Recherche. Agenten ohne Schreibzugriff können mehrere Ansätze nebeneinander untersuchen, ohne sich gegenseitig die Dateien zu überschreiben.
4. Kostenkontrolle. /model opusplan liefert in einer Sitzung einen starken Planer und einen günstigen Ausführer.

Auto Mode mit den Augen eines Security Engineers

Auto Mode verdient die Aufmerksamkeit, die früher der Plan-Modus bekam. So funktioniert er.

Ein zweites Modell prüft jede Aktion. Der Klassifikator läuft standardmäßig auf Claude Sonnet 5, nicht auf Ihrer /model-Wahl. Er sieht Ihre Nachrichten, Claudes Tool-Aufrufe und Ihre CLAUDE.md, aber Tool-Ergebnisse werden aus seinen Anfragen entfernt. Eine bösartige README oder Webseite kann nicht direkt auf den Klassifikator einwirken. Zusätzlich scannt eine serverseitige Prüfung eingehende Tool-Ergebnisse auf verdächtige Inhalte.

Nicht alles landet bei ihm. Zuerst greifen die Regeln, Lesezugriffe und Edits im Arbeitsverzeichnis werden ohne Prüfung genehmigt, und alles andere — Shell, Netzwerk, geschützte Pfade, das Starten von Subagenten — geht an den Klassifikator. Beim Wechsel in Auto Mode verwirft Claude Code breite Allow-Regeln, die beliebige Codeausführung erlauben: Bash(*), Interpreter mit Wildcard wie Bash(python*), Run-Befehle von Paketmanagern und Agent-Allow-Regeln. Enge Regeln wie Bash(npm test) bleiben. Die verworfenen Regeln kehren zurück, sobald Sie Auto verlassen.

Im Zweifel fällt er auf Sie zurück. Nach 3 Blockaden in Folge oder 20 in einer Sitzung pausiert Auto Mode, und Claude Code fragt wieder nach. In einem -p-Lauf ohne Prompt-Tool wird die blockierte Aktion einfach nicht ausgeführt.

Drei Punkte dieser Liste überraschen viele:

• Ein Push auf main ist erlaubt. Wenn Sie einen menschlichen Kontrollpunkt wollen, bevor Code Ihren Rechner verlässt, müssen Sie ihn selbst einbauen (nächster Abschnitt).
• „Nicht pushen” im Chat ist weich. Der Klassifikator respektiert Grenzen, die Sie im Gespräch setzen, liest sie aber bei jeder Prüfung neu aus dem Transkript. Eine Kontextkomprimierung kann sie entfernen. Die dauerhafte Variante ist eine Deny- oder Ask-Regel.
• $defaults trägt Last. Sie können den Klassifikator mit Regeln in Prosa in autoMode.environment, allow, soft_deny und hard_deny erweitern. Fehlt "$defaults" in einem dieser Arrays, ersetzen Sie die komplette eingebaute Liste dieses Abschnitts — samt dem Schutz vor Force-Push und curl | bash. claude auto-mode config zeigt, was der Klassifikator tatsächlich verwendet, claude auto-mode critique lässt Ihre eigenen Regeln prüfen. Die vollständige Referenz steht unter Configure auto mode.

Ab Werk vertraut der Klassifikator nur Ihrem Arbeitsverzeichnis und den konfigurierten Remotes des Repos. Ein Remote, das Sie während der Sitzung hinzufügen, gilt nicht als vertrauenswürdig, und Pushes in andere Repos Ihres Unternehmens oder Schreibzugriffe auf einen Team-Bucket bleiben blockiert, bis Sie sie in autoMode.environment beschreiben — oder /auto-mode-setup diese Einträge für Sie entwerfen lassen.

Berechtigungsregeln sind keine Sicherheitsgrenze

Regeln werden in der Reihenfolge deny → ask → allow ausgewertet, der erste Treffer gewinnt, und Spezifität ändert die Reihenfolge nicht: Ein breites Bash(aws *) in deny blockiert auch aws s3 ls, selbst wenn Sie genau diesen Befehl erlauben. Regeln werden von Claude Code durchgesetzt, nicht vom Modell — CLAUDE.md ist ein Ratschlag, eine Deny-Regel ist Richtlinie.

Eine Bash-Regel prüft allerdings den Befehlstext, den Claude schreibt. Die Dokumentation sagt offen, was das bedeutet:

Auch beim Dateischutz leisten Regeln weniger, als es scheint. Read- und Edit-Deny-Regeln decken Claudes Datei-Tools ab, Dateibefehle, die Claude Code in Bash erkennt, etwa cat und sed, sowie Ziele von Umleitungen. Ein Python-Skript, das die Datei selbst öffnet, decken sie nicht ab. Dafür brauchen Sie die Sandbox: Durchsetzung auf Betriebssystemebene (Seatbelt unter macOS, bubblewrap unter Linux und WSL2), die für jeden Kindprozess gilt, egal was das Modell entschieden hat.

Zwei Einschränkungen der Sandbox, die man leicht übersieht:

• Sie gilt für Bash-, PowerShell- und Monitor-Befehle. Die eingebauten Tools Read und Edit laufen stattdessen über die Berechtigungen.
• Standardmäßig erlaubt die Sandbox Lesezugriffe auf den gesamten Rechner, auch auf ~/.aws/credentials und ~/.ssh. Blockieren Sie das mit Einträgen in sandbox.credentials oder nutzen Sie mask, damit ein Platzhalter den echten Token ersetzt, den erst der Proxy beim Verlassen der Sandbox einsetzt.

Dasselbe Fehlermuster steckt hinter den KI-Agenten, die eine Regierungswebsite gehackt haben: Ein blockierter Weg wird mit einem Werkzeug umgangen, das niemand für gefährlich hielt. Eine Regel auf den Befehlstext stoppt das nicht. Eine Grenze, die das Betriebssystem durchsetzt, schon.

--dangerously-skip-permissions: nur in einer Kiste, die Sie wegwerfen können

--dangerously-skip-permissions ist dasselbe wie --permission-mode bypassPermissions. Was es 2026 tatsächlich tut:

• Keine Rückfragen und keine Prüfung geschützter Pfade — seit v2.1.126 schreibt es ohne Nachfrage in .git/, .claude/, .vscode/ und Shell-Konfigurationsdateien.
• Hält trotzdem an bei expliziten Ask-Regeln, Deny-Regeln und Löschbefehlen auf kritische Pfade. Seit v2.1.281 zeigt diese Rückfrage einen Zwei-Minuten-Countdown, lehnt danach ab und sagt Claude, wie der Befehl umgeschrieben werden muss. Nach drei unbeantworteten Rückfragen in einer Sitzung lehnt es solche Befehle sofort ab.
• Verweigert root. Unter Linux und macOS startet es nicht als root oder per sudo, außer es erkennt eine bekannte Sandbox. Der vorgesehene Weg ist die Dev-Container-Konfiguration, die Claude Code als normalen Nutzer ausführt.
• Lässt sich nicht über ein Repo einschmuggeln, wie oben beschrieben, und Organisationen können es mit permissions.disableBypassPermissionsMode: "disable" entfernen.

Wenn Sie einen unbeaufsichtigten Lauf auf dem eigenen Laptop wollen, brauchen Sie keinen Bypass. dontAsk mit einer exakten Allow-Liste oder Auto Mode mit Sandbox liefert Ihnen den Großteil der Autonomie, ohne die Bremsen abzubauen. Außerdem gibt es --restricted (ab v2.1.248): Es entfernt die Tools, die Code ausführen, hält Datei-Tools im Arbeitsverzeichnis und verweigert Bypass komplett.

Plan Mode vs. Auto Mode: Welchen Modus sollten Sie nutzen?

Die Kurzfassung:

• Wegwerf-Container oder VM, komplett unbeaufsichtigt → bypassPermissions, ohne root, ohne Produktions-Zugangsdaten darin.
• CI oder ein zeitgesteuertes Skript → dontAsk mit einer expliziten --allowedTools-Liste.
• Produktions-Zugangsdaten oder regulierte Daten in Reichweite → Manual. Manche Arbeit darf einen Klick kosten.
• Neue Codebasis oder großes Refactoring → plan, mit opusplan, dann in Auto freigeben.
• Alltag in einem Repo, dem Sie vertrauen → auto plus die Regeln und die Sandbox unten.

Das Setup, das ich tatsächlich nutzen würde

Legen Sie das in ~/.claude/settings.json ab — im Nutzer-Scope, weil eine Projektdatei weder Auto Mode noch autoMode-Regeln aktivieren kann:

{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Bash(terraform apply *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/your-org and all repos under it"
    ]
  }
}

Was jeder Block Ihnen bringt:

• deny hält Geheimnisse von Claudes Datei-Tools fern. Read(.env) trifft eine .env in jeder Tiefe unterhalb des aktuellen Verzeichnisses.
• ask stellt den menschlichen Kontrollpunkt wieder her, den Auto Mode standardmäßig entfernt. Die Regel prüft den Befehl so, wie er geschrieben ist, kombinieren Sie sie also mit der Sandbox, statt sich allein auf sie zu verlassen.
• sandbox ist die echte Grenze. allowUnsandboxedCommands: false entfernt den Notausgang, über den Claude einen fehlgeschlagenen Befehl außerhalb der Sandbox wiederholt; wirklich inkompatible Tools wie docker * tragen Sie stattdessen in excludedCommands ein.
• autoMode.environment mit "$defaults" bringt dem Klassifikator Ihre Organisation bei, ohne seine eingebauten Regeln zu löschen.

In CI lassen Sie Auto ganz weg:

claude -p "run the test suite and fix lint errors" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Edit" "Bash(npm run lint *)" "Bash(npm test *)"

Alles, was nicht auf der Liste steht, wird abgelehnt statt nachgefragt, der Job hängt also nie und wartet auf einen Menschen. Die Agenten-Schleife selbst erklärt der Artikel wie KI-Coding-Agenten wie Claude Code, Codex und opencode funktionieren. Dasselbe Allow-Listen-Denken gilt für Tools, die Sie per MCP anbinden — siehe MCP-Server sicher betreiben und einen praktischen Test für die Abwehr von Prompt Injection.

Fazit

Der Plan-Modus ist nicht gestorben, weil Planen unwichtig geworden wäre. Er ist als Standard gestorben, weil die Sicherheit nie in ihm lag. Er war eine höfliche Anweisung mit angehängter Edit-Sperre, und das Produkt hat die echten Entscheidungen woanders hin verlegt: zu einem Klassifikator, der jede Aktion prüft, ohne Tool-Ausgaben zu lesen, zu Deny- und Ask-Regeln, die Claude Code durchsetzt, und zu einer Sandbox, die das Betriebssystem durchsetzt.

Fragen Sie also nicht mehr, welcher Modus der sicherste ist, sondern welche Schicht das abfängt, wovor Sie Angst haben. Nutzen Sie den Plan-Modus, wenn Sie einen besseren ersten Entwurf der Arbeit wollen. Nutzen Sie Auto Mode, wenn Sie Tempo wollen. Und legen Sie Ihre echten Garantien in Regeln und Sandbox ab, wo weder Kontextkomprimierung noch geschickte Prompts sie erreichen.