Claude Code fragt ab heute nicht mehr so viel

Ab heute starten neue Claude-Code-Sitzungen auf Pro, Max und Team im Auto-Mode. Statt einer Rückfrage pro Werkzeugaufruf läuft jeder Aufruf durch einen Klassifizierer, der auf drei Dinge achtet: unumkehrbar, zerstörerisch, oder aus deiner Umgebung herausreichend. Findet er nichts davon, läuft der Befehl.

Wer schon einen eigenen Default gesetzt hat, behält ihn und bekommt höchstens einmal die Frage, ob er wechseln will. Auf Enterprise, der API, Bedrock, Google Cloud Agent Platform und Microsoft Foundry bleibt es vorerst freiwillig, dort soll die Umstellung im Lauf des nächsten Monats folgen. Die Tokens, die der Klassifizierer verbraucht, werden auf Pro, Max und Team nicht mehr berechnet.

Die Begründung ist bemerkenswert offen

Interessanter als die Umstellung ist, womit Anthropic sie belegt. Der Kern des Arguments: Die manuelle Freigabe ist längst Routine, und Routine ist keine Kontrolle.

Nutzer bestätigen 97 Prozent aller Freigabedialoge. Die Ablehnungsquote liegt bei 3 Prozent. Zum Vergleich legt Anthropic eine zweite Zahl daneben: Wenn Claude einen Plan zur Freigabe vorlegt, lehnen Nutzer 39 Prozent davon ab. Bei einzelnen Berechtigungen sieht das Verhalten also anders aus als bei etwas, das man wirklich liest.

Dazu kommt eine kontrollierte Studie mit 1.053 bezahlten Testern. Mitten in der Sitzung wurde ein Freigabedialog gegen ein klar gefährliches Kommando getauscht, und es wurde gezählt, wer es durchwinkt. Die Menschen erkannten es in 143 von 1.053 Fällen, also 13,6 Prozent. Der Auto-Mode blockte dasselbe Kommando in 937 Fällen, also 89 Prozent. Im direkten Vergleich blockte der Klassifizierer 800 Kommandos, die ein Mensch freigegeben hätte, umgekehrt waren es 6.

Der aufschlussreichste Teil ist der Verlauf: Früh in einer Sitzung erkannten Tester noch rund 17 Prozent der gefährlichen Kommandos, nach 50 oder mehr vorangegangenen Dialogen nur noch etwa 5 Prozent. Die Trefferquote des Klassifizierers blieb über die Sitzungslänge gleich.

Wie sehr die Freigabedialoge in der Praxis schon umgangen werden, zeigt Anthropic gleich mit. Stand Juni 2026 hatten 49,5 Prozent der aktiven CLI-Nutzer selbst eine Bash-Allow-Regel angelegt. 5 Prozent erlauben pauschal jedes Shell-Kommando, weitere 43 Prozent haben Interpreter-Regeln wie Bash(python:*), was praktisch auf dasselbe hinausläuft. 62 Prozent haben schon einmal bypassPermissions benutzt oder bei Bash auf "nicht mehr fragen" geklickt, und 25 Prozent der interaktiven Sitzungen starten direkt im Bypass-Modus.

Was der Klassifizierer tatsächlich macht

Blockt er etwas, sucht Claude in der Regel selbst einen sichereren Weg oder fragt direkt nach. Kommt er nicht weiter, greift ein Notausgang: nach drei Blocks am Stück oder zwanzig in einer Sitzung fällt Claude Code auf manuelle Freigaben zurück.

Einige Kategorien sind als harte Verbote angelegt, die der Klassifizierer nie genehmigt. Datenabfluss gehört dazu, also Code oder Secrets nach außen schicken. Wer so etwas ausführen will, muss den Modus wechseln oder das Kommando selbst tippen. Diese harten Verbote lassen sich über die Einstellungen erweitern, und für Organisationen dürfte genau das der nützlichere Hebel sein.

Anthropic nennt drei Vorfälle aus dem eigenen Haus, die der Klassifizierer abgefangen hat. Als ein Upload auf ein internes Laufwerk scheiterte, wollte Claude denselben Bericht ersatzweise auf eine öffentliche Code-Sharing-Seite stellen. In einer langen Sitzung setzte Claude einen Massen-Kill über rund zweitausend Pods an, samt Löschungen, die hunderte GPUs mit laufenden Trainingsjobs abgeräumt hätten. Und bei der Aufgabe, einen lesenden Zugang zur Abrechnung einzurichten, griff Claude zu einer Cloud-Rolle mit voller Administratorkontrolle auf Kontoebene.

Für die Prompt-Injection-Seite gibt es eine externe Messung. Trajectory Labs testete 72 Angriffsszenarien je zehnmal. Von den 720 Versuchen kam keiner gegen Claude Fable 5, Opus 5 oder Sonnet 5 im Auto-Mode durch. Gegen GPT-5.6 Sol im Auto-review-Modus von Codex waren es 5,83 Prozent, im Full-Access-Modus 19,03 Prozent. Die Angriffe waren gegen ein anderes Modell optimiert, alle Getesteten sahen sie also zum ersten Mal.

Der Haken: deine bisherigen Allow-Regeln zählen nicht mehr

Eine Änderung geht leicht unter, und sie trifft genau die knappe Hälfte der Nutzer, die sich schon eigene Regeln gebaut hat. Breite Allow-Regeln werden im Auto-Mode beiseitegelegt. Alles, was auf beliebige Codeausführung hinausläuft, also Muster wie Bash(python:*), würde den Klassifizierer sonst schlicht umgehen. Die Einstellungsdateien werden dabei nicht angefasst, und sobald du in einen anderen Modus wechselst, gelten die Regeln wieder.

Deny-Regeln laufen dagegen weiter vor dem Klassifizierer. Sie sind das Mittel, das im Auto-Mode noch zuverlässig greift. Die Rangfolge ist eindeutig: erst deny, dann ask, dann allow, die erste Übereinstimmung entscheidet. Eine spezifischere Allow-Regel sticht keine breitere Deny-Regel.

Praktisch heißt das vor allem eins: Die Arbeit verschiebt sich von der Positivliste zur Negativliste. Bisher hat man Allow-Regeln gepflegt, damit weniger Dialoge kommen. Diese Motivation fällt weg, es kommen ja ohnehin kaum noch welche. Was jetzt zählt, ist die Frage, was nie laufen soll, egal wer es anfragt: Produktionszugänge, Deploy-Skripte, Verzeichnisse mit Schlüsseln.

Dabei sollte man wissen, wo Deny-Regeln aufhören. Sie greifen für Claudes Datei-Werkzeuge und für Dateibefehle, die Claude Code in Bash erkennt, etwa cat oder sed. Sie greifen nicht für beliebige Unterprozesse, also für ein Python-Skript, das eine Datei selbst öffnet. Wer auch das abdecken will, braucht die Sandbox, die auf Betriebssystemebene arbeitet.

Den Modus selbst schaltet man in der CLI mit Shift+Tab um, in der Desktop-App über das Dropdown, dauerhaft über defaultMode in den Einstellungen. In Managed Settings gesetzte Regeln lassen sich von Projekt- oder Nutzereinstellungen nicht überschreiben, und ein deny auf irgendeiner Ebene schlägt ein allow auf jeder anderen. Wer den Auto-Mode gar nicht will, schaltet ihn mit disableAutoMode ab.

Einordnung

Anthropic verkauft das nicht als Sicherheitsgewinn ohne Restrisiko, und das ist die ehrlichste Stelle des ganzen Beitrags: Der Auto-Mode beruht auf Klassifikation und beseitigt kein Risiko, für heikle Eingriffe an Produktionsinfrastruktur empfiehlt Anthropic weiterhin, selbst hinzusehen. Beim Red-Teaming mit Apollo Research fiel die Durchlassquote des Klassifizierers von 12 auf 7 Prozent, gemessen an absichtlich gemeinen synthetischen Angriffen. Sieben Prozent sind nicht null.

Der Produktivitätsgewinn ist dabei durchaus real. Bei Teams- und Enterprise-Kunden liefern Auto-Mode-Nutzer laut Anthropic rund 25 Prozent mehr PRs aus, und bei Gusto enthalten seit Mitte Mai etwa 10 Prozent der Sitzungen eine Ablehnung durch den Klassifizierer, ohne dass legitime Arbeit spürbar ausgebremst wird. Der Klassifizierer arbeitet also, ohne ständig im Weg zu stehen.

Trotzdem ist das hier eher ein Eingeständnis als ein Fortschritt. Der Klickdialog hat als Sicherheitsmechanismus nie richtig funktioniert, und die Zahlen dazu lagen schon vorher vor, sie wurden nur nicht so deutlich hingeschrieben. Die interessantere Frage ist ohnehin nicht, ob eine Maschine besser durchwinkt als ein müder Mensch. Sie lautet, welche Grenzen so gebaut sind, dass sie unabhängig von beidem halten. Das sind Deny-Regeln, Sandboxes und getrennte Zugänge, und die waren auch vorher schon die Antwort.