Claude Code Auto Mode ist jetzt Default – und wann ich ihn machen lasse

Den kompletten Stack hinter t01.li verwalte ich mit Claude Code. Ghost samt CLI, NGINX, die Dienste drumherum, das Theme, die lokale Testversion – das läuft alles über das Terminal, und den Coding-Agent lasse ich die „Handarbeit“ machen. Meistens starte ich damit im Plan Mode, weil ich erst sehen will, was Claude Code vorhat, bevor er irgendwas anfasst. Seit dem 14. August bekomme ich am Ende jedes Plans dieselbe Rückfrage: „Ausführen – im Auto Mode?“

Das ist relativ neu und kein Zufall, denn Anthropic hat den Auto Mode zum Standard erkoren.

Was Auto Mode als Default ändert

Seit Mitte August ist der Auto Mode der eingebaute Start-Modus für neue Sessions auf den Pro-, Max- und Team-Plänen – sofern keine eigene Permission-Konfiguration oder ein nicht unterstütztes Ausführungsszenario dazwischenfunkt. Wer vorher jede Datei-Änderung und jeden Shell-Befehl einzeln abgenickt hat, findet sich jetzt in einem Modus wieder, der deutlich weniger fragt.

Nur heißt „weniger fragen“ nicht „gar nicht prüfen“. Im Auto Mode entscheidet bei potenziell riskanten Aktionen nicht mehr automatisch der Nutzer, sondern ein separates Modell: der Klassifikator. Unkritische Reads, Dateiänderungen im Projekt und Aktionen, die bereits durch Permission-Regeln entschieden wurden, passieren vorher. Alles andere bewertet der Klassifikator und blockiert beispielsweise Aktionen, die über deinen Auftrag hinaus eskalieren, fremde Infrastruktur betreffen oder nach einer Prompt Injection aussehen.

Aus „ich bin der Türsteher“ wird „ein LLM ist der Türsteher“ – das ist der ganze Unterschied.

Wie ich Modes in Claude Code fahre

Bei mir läuft fast alles über den Plan Mode, und das hat einen simplen Grund. Wenn ich mehrere kleinere und vor allem zusammenhängende Aufgaben auf einmal verteile und Claude Code seine Sub-Agents nutzen lasse, will ich den Plan sehen, bevor die loslegen – nicht jeden einzelnen Edit, sondern die Marschrichtung. Man sollte dabei aber immer berücksichtigen, dass mehrere Agents parallel den Token-Verbrauch treiben.

Der Plan Mode ist bei mir nicht nur die Vorstufe zum Abnicken, sondern das Werkzeug für die Fragen, die vor einem Eingriff geklärt sein müssen. Bringt ein Ghost-Update eine Änderung mit, die mir schlimmstenfalls das Theme zerlegt? Sind Elemente inzwischen als deprecated markiert, auf die ich mich noch verlasse? Und dann die Dauerbaustelle, die ich seit zwei Monaten vor mir herschiebe – die Migration auf Tailwind 4. Wie aufwendig wird diese Migration wirklich, und wann ist der richtige Moment, ohne dass die Seite zwei Tage im Umbau steht. Das sind Fälle, in denen ich die Analyse und den vorgeschlagenen Weg sehen will, bevor eine einzige Zeile geändert wird. Genau dafür ist Plan Mode gebaut.

Wenn der Plan steht und passt, nehme ich das Auto-Mode-Angebot von Claude Code an. Nicht aus Bequemlichkeit, sondern weil für diesen Stack die Voraussetzungen stimmen. Ich arbeite seit Monaten mit Claude Code an genau dieser Umgebung, ich kenne alle Ecken und Kanten des Setups, meine CLAUDE.md ist über etliche Sessions gewachsen statt auto-generiert, und darunter liegt ein Netz aus Backups und Server-Snapshots. Wenn im Auto Mode etwas schiefläuft, kostet mich das einen Rollback, keine Nacht vor dem Rechner.

Das ist die eigentliche Bedingung, unter der Auto Mode Sinn ergibt: nicht das Feature, sondern der Reifegrad drumherum. Ein eingefahrener Stack, Guardrails, die du selbst getestet hast, und ein Wiederherstellungspunkt, der greift. Fehlt eins davon, sieht die Rechnung anders aus.

Der eigentliche Hebel ist nicht die CLAUDE.md

Hier lauert ein Fallstrick: Denn man steckt Mühe in die CLAUDE.md und meint, damit die Leine in der Hand zu haben. Das ist aber nur so halb korrekt. Die CLAUDE.md instruiert – sie sagt Claude, was gemeint ist, und der Agent hält sich dran, ähnlich wie er ein „push hier nichts ohne Rückfrage“ befolgt. Ein Riegel ist sie nicht.

Wer im Auto Mode eine harte Grenze will, zieht sie in der settings.json. Da liegen drei Listen: allow, deny, ask. Und deny schlägt alles – den Klassifikator, sogar den Bypass-Modus. Ein deny auf Bash(rm -rf:*) oder auf Read(.env*) steht, egal in welchem Modus die Session läuft. Genau das macht Auto Mode auf einem Produktions-Stack erst verantwortbar. Der Klassifikator ist die zweite Verteidigungslinie, die erste sind ein paar Zeilen, die ich selbst geschrieben habe. Das Modell darf großzügig durchwinken, weil die Deny-Liste die echten Katastrophen schon vorher aussortiert hat.

Die Arbeitsteilung in einem Satz: settings.json setzt durch, CLAUDE.md redet gut zu. Das sollte man nicht verwechseln, denn dann verlässt man sich an der falschen Stelle auf gutes Zureden.

Der Türsteher ist auch nur ein Modell

Bleibt der Reality-Check, und Anthropic liefert ihn selbst mit: So steht im Warnkasten der Doku, „Auto Mode“ senke die Prompts, aber „does not guarantee safety“ und sei kein Ersatz für Review bei sensiblen Operationen. Der Anbieter schreibt die Grenze selbst hin, statt sie wegzulächeln. Denn hinter der letzten Entscheidung steckt trotz fest definierter Regeln ein Modell. Die Policy gibt den Rahmen vor, die konkrete Einordnung bleibt probabilistisch – und damit nicht unfehlbar. Bei mir schlägt dieser Schnitt in die vorsichtige Richtung aus: Der Klassifikator blockiert gefühlt lieber einmal zu oft als zu selten, und selbst für bekanntes Terrain ist das die angenehme Fehlerrichtung. Lieber ein Block zu viel als eine Aktion, die durchrutscht.

Auf unbekanntem Terrain kippt die Rechnung. Da verschiebe ich ein Risiko, das ich vorher mit eigenen Augen gesehen hätte, auf eine Instanz, die im Schnitt richtig liegt. „Im Schnitt richtig“ ist bei einem Produktionsserver eine andere Aussage als bei einem Playground oder einem Testprojekt.

Das eingebaute Checkpoint-System erfasst Dateiänderungen über Claudes Editing-Tools und lässt sie per /rewind zurückdrehen – ein gutes Sicherheitsnetz, aber kein vollständiger Rollback. Änderungen durch Bash-Kommandos werden nicht erfasst, und auch Edits normaler Sub-Agents lassen sich darüber in der Regel nicht wiederherstellen. Genau deshalb bleiben meine eigenen Server-Snapshots und Git die Ebene, auf die ich mich im Zweifel verlasse.

Wann Auto Mode das Falsche ist

Setze ich einen Stack neu auf, ist Auto Mode meistens die falsche Wahl. Dann kenne ich die Umgebung nicht gut genug, um zu merken, wenn der Agent in die falsche Richtung rennt – und genau dieses „Bemerken“ ist der Wert der Einzel-Freigabe, der eigentliche Sinn von Human-in-the-loop. In dem Fall greife ich zu „Accept edits“ oder gehe ganz auf „Manual“ zurück.

Ein Detail dazu, das in der Arbeit mit dem Stack schnell auffällt: auch „Accept edits“ winkt nicht alles durch. Der Modus lässt Datei-Änderungen und gängige Filesystem-Befehle im Arbeitsverzeichnis ohne Rückfrage laufen: mkdir, touch, rm, rmdir, mv, cp und sed. Andere Bash-Befehle außerhalb des eingebauten Read-only-Sets prompten weiterhin, sofern sie nicht über eigene Permission-Regeln freigegeben sind. Damit ist „Accept edits“ beim Neuaufsetzen die gezieltere Wahl als „Auto“. Die reine Schreibarbeit läuft flüssig, aber alles, was in die Systemebene greift, landet wieder bei mir. Man macht sich nicht zum Klick-Sklaven und gibt trotzdem nicht die Kontrolle ab, wo sie wichtig ist.

„Manual“ ist der Fall, wenn ich jeden Schritt sehen will – erstmalige Migrationen, alles was an Auth oder an die NGINX-Config geht, Sachen, bei denen ein falscher Move teuer werden könnte.

Das Netz muss vorher hängen

„Auto Mode“ als Default ist die richtige Entscheidung für den Durchschnittsfall – wer an vertrauten Projekten arbeitet, will nicht bei jedem Edit klicken. Für meinen t01.li-Stack passt es, weil das Sicherheitsnetz vorher gespannt war und nicht danach: eine Deny-Liste, die die scharfen Kanten abräumt, und Snapshots, die einen Fehler zum Rollback machen statt zur Nachtschicht. Die Frage ist nie „ist Auto Mode sicher“, sondern ob mein Setup an dem Punkt ist, an dem ich einem LLM den Türsteher überlassen kann. Bei mir und in diesem Fall: ja. Beim nächsten frischen Server: erst mal nicht.