--- title: "Claude-Code-Modi im Vergleich: Warum der Plan-Modus tot ist und was ihn ersetzt" description: "Alle sechs Berechtigungsmodi von Claude Code im Vergleich — Manual, acceptEdits, plan, auto, dontAsk und bypassPermissions: was jeder Modus dem Agenten erlaubt, warum Auto Mode den Plan-Modus als Standard abgelöst hat, was der Auto-Mode-Klassifikator blockiert und erlaubt, und eine settings.json, die hält." author: Aleksei Aleinikov date: 2026-09-28 lang: de tags: [claude-code, plan-mode, auto-mode, berechtigungsmodi, dangerously-skip-permissions, ki-coding-agenten, agenten-sicherheit] canonical: https://www.alekseialeinikov.com/de/blog/topics/ai/claude-code-modi-im-vergleich-warum-plan-mode-tot-ist source: alekseialeinikov.com --- # 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*](https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/09/24/plan-mode-is-dead.html) auf der Startseite von [Hacker News](https://news.ycombinator.com/item?id=49840054) 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. ![Berechtigungsmodi von Claude Code im Vergleich: Manual, acceptEdits, plan, auto, dontAsk und bypassPermissions, und warum Auto Mode den Plan-Modus als Standard abgelöst hat](https://www.alekseialeinikov.com/blog/claude-code-modes.webp) ## 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](https://code.claude.com/docs/en/permission-modes) und dem [Changelog von Claude Code](https://code.claude.com/docs/en/changelog), Stand v2.1.283. | Modus | Läuft ohne Rückfrage | Wer gibt den Rest frei | Geeignet für | Die Falle | |---|---|---|---|---| | **Manual** (`default`) | Nur Lesezugriffe | Sie, pro Aktion | Sensible Repos, unbekannter Code | Prompt-Müdigkeit — irgendwann klicken Sie blind auf *Yes* | | **`acceptEdits`** | Lesen, Datei-Edits, `mkdir` `touch` `rm` `rmdir` `mv` `cp` `sed` im Arbeitsverzeichnis | Sie, für andere Shell-Befehle | Iterieren an Code, den Sie per `git diff` prüfen | `rm` im Projekt wird automatisch genehmigt | | **`plan`** | Lesen; Shell-Befehle, die der Klassifikator freigibt | Sie, bei der Plan-Freigabe | Erkunden, bevor sich etwas ändert | Blockiert Edits, nicht Aktionen — siehe unten | | **`auto`** | Alles, nach einer Prüfung im Hintergrund | Ein Klassifikator-Modell | Lange Aufgaben in vertrauenswürdigen Repos | Erlaubt Pushes auf jeden Branch des aktuellen Repos | | **`dontAsk`** | Lesen und vorab erlaubte Tools | Niemand — der Rest wird abgelehnt | CI und Skripte | Fehler sind stille Ablehnungen | | **`bypassPermissions`** | Alles, auch `.git` und `.claude` | Niemand | Wegwerf-Container und VMs | Kein Schutz gegen Prompt Injection | 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. ![Matrix der Claude-Code-Berechtigungsmodi: was Manual, acceptEdits, plan, auto, dontAsk und bypassPermissions für Lesen, Edits, Shell-Befehle, Netzwerk, git push und geschützte Pfade erlauben](https://www.alekseialeinikov.com/blog/claude-code-modes-matrix.webp "Lesen Sie die Spalten, nicht die Zeilen: Zwischen den Modi ändert sich nur, wer Ja sagt.") ## 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. | Standardmäßig blockiert (Auswahl) | Standardmäßig erlaubt | |---|---| | `curl \| bash` und anderes Herunterladen-und-Ausführen | Lokale Dateioperationen im Arbeitsverzeichnis | | Sensible Daten an externe Endpunkte senden | Abhängigkeiten aus Ihren Lockfiles installieren | | Produktions-Deployments, Migrationen, `terraform destroy` | `.env` lesen und Zugangsdaten an die passende API senden | | Force-Push, `git reset --hard`, `git clean -fd` | Lesende HTTP-Anfragen | | IAM- oder Repo-Berechtigungen vergeben | **Pushes auf jeden Branch des aktuellen Repos, auch auf den Default-Branch** | | In Secret Manager, DNS oder TLS-Zertifikate schreiben | Einen Pull Request anlegen, der zu Ihrer Anfrage passt | | Einen nicht freigegebenen PR mergen, CI-Checks abschalten | Daten an vertrauenswürdige Domains senden, die Sie in `autoMode.environment` nennen | | Zugangsdaten vom Cloud-Metadaten-Endpunkt abrufen (`169.254.169.254`) | Security-Code im Rahmen Ihrer Aufgabe lesen und schreiben | | Tunnel und Reverse Shells | | 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](https://code.claude.com/docs/en/auto-mode-config). 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: | Deny-Regel | Stoppt | Stoppt nicht | |---|---|---| | `Bash(curl *)` | `curl https://example.com` | `/usr/bin/curl …`, `sh -c 'curl …'` | | `Bash(rm *)` | `rm -rf build/` | `/bin/rm -rf build/`, `bash -c 'rm -rf build/'` | | `Bash(git push *)` | `git push origin main` | `git -C . push …`, `git -c push.default=current push` | 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. ![Schutzschichten in Claude Code: Deny- und Ask-Regeln, PreToolUse-Hooks, der Berechtigungsmodus oder Auto-Mode-Klassifikator, die Sandbox auf Betriebssystemebene und Löschbefehle auf kritische Pfade, die kein Modus automatisch genehmigt](https://www.alekseialeinikov.com/blog/claude-code-modes-layers.webp "Jede Schicht fängt ab, was die darüber durchlässt. Nur der Sandbox ist egal, wie ein Befehl geschrieben ist.") Dasselbe Fehlermuster steckt hinter den [KI-Agenten, die eine Regierungswebsite gehackt haben](https://www.alekseialeinikov.com/de/blog/topics/security/ki-agenten-hackten-regierungswebsite-2026): 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? ![Entscheidungsbaum zur Wahl des Claude-Code-Berechtigungsmodus: Wegwerf-Container, CI-Pipeline, unbekannte oder große Änderung, vertrauenswürdiges Repository oder Produktions-Zugangsdaten](https://www.alekseialeinikov.com/blog/claude-code-modes-decision.webp "Beginnen Sie beim möglichen Schaden, nicht bei der Aufgabe.") 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: ```json { "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: ```bash 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](https://www.alekseialeinikov.com/de/blog/topics/ai/ki-coding-agents-2026-claude-code-vs-codex-vs-opencode). Dasselbe Allow-Listen-Denken gilt für Tools, die Sie per MCP anbinden — siehe [MCP-Server sicher betreiben](https://www.alekseialeinikov.com/de/blog/topics/ai/mcp-server-erklaert-selbst-bauen-und-sicher-betreiben-2026) und [einen praktischen Test für die Abwehr von Prompt Injection](https://www.alekseialeinikov.com/de/blog/topics/security/prompt-injection-abwehr-2026-lethal-trifecta-test). ## 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.