Das Permission-Modell von Claude Code beschreibt nicht mehr die Voreinstellung
Im Buch steht
Richtig ist
Seit dem 14. August 2026 ist der Auto-Modus die Standard-Berechtigungsstufe für neue Sessions auf den Plänen Pro, Max und Team. Er ersetzt die Rückfrage nicht durch blindes Vertrauen, sondern durch eine Prüfung: Ein separater Klassifikator bewertet jeden Shell-Befehl und jede Aktion. Claude fährt fort, solange die Aktion nicht als irreversibel, destruktiv oder außerhalb der Arbeitsumgebung eingestuft wird — dann fragt es weiterhin.
Der Auto-Modus existierte bereits zum Redaktionsschluss: als Research Preview seit März 2026, auf dem Pro-Plan seit Mai, auf Amazon Bedrock, Google Cloud und Microsoft Foundry seit Juni. Zum Standard wurde er erst im August — eingebaut ab v2.1.228 auf macOS, Linux und WSL bzw. ab v2.1.233 auf Windows; ältere Versionen starten weiterhin in der Stufe, die das Buch beschreibt.
Diese Stufe heißt inzwischen Manual, in der CLI, in den IDE-Erweiterungen und in der Desktop-App. Der Konfigurationswert bleibt default; manual wird als Alias akzeptiert (ab v2.1.200). Wer im Buch „Standardmodus“ liest, muss also unterscheiden: Manual ist der Modus, den das Kapitel beschreibt. Die Voreinstellung ist er nicht mehr. Und die Rückfrage bei Shell-Befehlen hat eine vierte Antwort bekommen, „Yes, and switch to auto mode“ (ab v2.1.247); sie ist damit zugleich der Ausstieg aus dem Modus, der sie auslöst.
Warum umgestellt wurde — und warum das Kapitel 8 stützt
In einem kontrollierten Test mit 1.053 Personen erkannte der Auto-Modus 89 % der gefährlichen Befehle. Die manuelle Freigabe durch Menschen erkannte 13,6 %. Der Grund ist unbequem: Nutzerinnen und Nutzer bestätigen rund 97 % aller Berechtigungsabfragen.
Damit bestätigt die Umstellung genau das, was Kapitel 10 aus dem SaaStr-Vorfall ableitet: Guardrails müssen technisch sein, nicht sprachlich. Eine Rückfrage, die reflexhaft weggeklickt wird, ist kein Guardrail — sie ist eine Quittung. Die praktische Konsequenz des Buchs bleibt gültig und wird wichtiger: Verlassen Sie sich nicht auf die Abfrage, sondern auf explizite deny-Regeln. Das Buch zeigt sie im selben Abschnitt; dieser Teil ist unverändert richtig.
Was Sie konkret tun sollten
- /permissions zeigt in einer laufenden Session den aktiven Modus. Er lässt sich jederzeit umschalten; eine selbst gesetzte Voreinstellung wird durch die Umstellung nicht überschrieben.
- Destruktive Operationen gehören in deny-Regeln, nicht in die Hoffnung auf eine Rückfrage — insbesondere git push --force, Löschbefehle und Produktionszugriffe.
- Auf Enterprise-Plänen und bei API-Konten blieb der Auto-Modus in der ersten Ausrollphase optional. Prüfen Sie, was in Ihrer Organisation gilt.
- Netzwerkbefehle wie curl gehen im Auto-Modus durch den Klassifikator, der curl | bash standardmäßig blockt. Für Skripte, die nie fragen sollen, gibt es seit v2.1.260 --permission-prompts none: Was eine Rückfrage auslösen würde, wird abgelehnt, der aktive Modus entscheidet weiter.
Kapitel 3 bringt es auf eine Formel, die durch diese Umstellung nicht falsch, sondern nur eine Stufe wichtiger geworden ist: „Vertrauen ist gut, ein explizites allow ist besser.“ Seit dem 14. August gilt die Umkehrung genauso — Vertrauen ist gut, ein explizites deny ist besser.
Vorschlag für den Nachdruck · Kapitel 3
„Claude Code kennt mehrere Berechtigungsstufen. In der strengsten fragt der Agent vor jeder potenziell destruktiven Aktion nach. Voreingestellt ist auf den Abo-Plänen inzwischen der Auto-Modus: Ein separater Klassifikator prüft jede Aktion und lässt sie durchlaufen, solange sie nicht irreversibel, destruktiv oder außerhalb Ihres Arbeitsverzeichnisses ist — sonst fragt er weiterhin. Der Hintergrund dieser Umstellung ist aufschlussreich: In Anthropics eigenen Messungen erkannten Menschen bei manueller Freigabe nur einen Bruchteil der gefährlichen Befehle, weil sie fast jede Abfrage bestätigen. Was Sie wirklich schützt, sind deshalb nicht die Rückfragen, sondern die Regeln, die Sie vorher aufschreiben.“
