Claude Code Auto-Modus
Ein zweites Sonnet-Modell prüft jeden Claude Code-Tool-Aufruf, bevor er ausgeführt wird. Was der Auto-Modus blockiert, was er erlaubt, und die Erlaubnisregeln, die er in deine Einstellungen schreibt.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Problem: Jeder Claude Code-Nutzer brennt irgendwann an Berechtigungsabfragen aus. Du bist mitten in einem Refactoring über drei Dateien, Claude braucht npm test, und ein Modal springt dir vor die Arbeit. Bestätigen. Datei lesen. Bestätigen. Migration schreiben. Bestätigen. Nach dreißig Abfragen liest du sie nicht mehr. Du klickst einfach.
Die andere Option war --dangerously-skip-permissions. Dieses Flag zieht alle Sicherheitsvorkehrungen raus. Gut in einem Container. Auf deinem Laptop, mit SSH-Schlüsseln, .env-Dateien und Git-Credentials genau dort? Keine Option, die ein vernünftiger Mensch wählen sollte.
Der Auto-Modus ist der mittlere Weg. Er wurde am 24. März 2026 veröffentlicht, und er funktioniert, indem er eine zweite KI im Hintergrund laufen lässt. Jeder Tool-Aufruf, den Claude machen möchte, wird zuerst geprüft. Riskante Aufrufe werden blockiert, und Claude erfährt warum. Sichere laufen ganz ohne Abfrage durch. Der Prüfer sitzt zwischen Claude und deinem Dateisystem und trifft die Entscheidung, die du selbst getroffen hättest, nur schneller als du klicken könntest.
Was der Auto-Modus wirklich ist
Der Auto-Modus ist ein neuer Berechtigungsmodus. Er liegt zwischen default (du prüfst alles) und bypassPermissions (nichts wird geprüft). Schalte ihn ein, und Claude hört auf, Abfragen zu zeigen. Bevor jeder Tool-Aufruf tatsächlich ausgeführt wird, schaut ein separates Klassifikator-Modell auf das bisherige Gespräch und die ausstehende Aktion, dann entscheidet es: Durchlassen oder Blockieren.
Drei Risikokategorien treiben die Entscheidung:
- Scope-Eskalation: Geht die Aktion über das hinaus, was du wirklich gefragt hast?
- Nicht vertrauenswürdige Infrastruktur: Ist das Ziel etwas, dem der Klassifikator keinen Grund hat zu vertrauen?
- Prompt Injection: Sieht die Aktion so aus, als käme sie von feindlichem Inhalt, den Claude in einer Datei oder Webseite gelesen hat?
Durchlassen, und die Aktion wird ausgeführt. Blockieren, und Claude bekommt den Grund zurück, damit es einen anderen Ansatz versuchen kann. Deine Hände bleiben auf der Tastatur. Der Prüfer bleibt auf Wacht.
Wie der Klassifikator funktioniert
Jeder Klassifikator-Aufruf läuft auf Claude Sonnet 4.6, egal welches Modell deine Session nutzt. Die Eingabe sind deine Nutzer-Nachrichten plus die ausstehenden Tool-Aufrufe. Claudes eigene Prosa und frühere Tool-Ergebnisse werden absichtlich herausgefiltert. Da Tool-Output nie in den Kontext des Klassifikators gelangt, kann nichts Böswilliges in einer Datei oder Seite hineinkommen und die Entscheidung beeinflussen.
Deine CLAUDE.md wird durchgereicht. Projektregeln fließen in das ein, was der Klassifikator akzeptiert und ablehnt. Statische Erlaubnis- und Sperrlisten matchen Tool-Namen und Argumente wie ein grep-Durchlauf. Der Klassifikator liest Prosa und denkt über Absicht nach, also behandelt er Fälle, die Pattern-Matching nicht kann.
Auswertungsreihenfolge
Jeder Tool-Aufruf läuft eine feste Leiter runter. Erste Übereinstimmung gewinnt:
| Schritt | Prüfung | Ergebnis |
|---|---|---|
| 1 | Passt zu deinen Erlaubnis- oder Sperrregeln | Wird sofort aufgelöst |
| 2 | Nur-Lese-Aktion oder Dateibearbeitung im Arbeitsverzeichnis | Automatisch genehmigt |
| 3 | Alles andere | Geht zum Klassifikator |
| 4 | Klassifikator blockiert | Claude versucht alternativen Ansatz |
Deine settings.json-Regeln laufen immer noch zuerst. Bash(npm test) in der Erlaubnisliste läuft durch, ohne dass der Klassifikator aufgewacht ist. Bash(rm -rf *) in der Sperrliste wird beendet, bevor der Klassifikator es sieht.
Breite Erlaubnisregeln werden entfernt
Hier ist der Haken, den die meisten Leute übersehen: In dem Moment, in dem du in den Auto-Modus wechselst, entfernt Claude Code deine breiten Erlaubnisregeln, die beliebige Ausführung erlauben. Alles wie Bash(*), Bash(python*), Bash(node*) und jede Agent-Erlaubnisregel wird für die Dauer herausgezogen.
Der Grund ist klar. Würde Bash(*) aktiv bleiben, würden genau die Befehle, die dich am meisten verletzen könnten, automatisch genehmigt, bevor der Klassifikator überhaupt einen Blick werfen könnte. Das ganze Feature wäre ausgehöhlt.
Enge Regeln bleiben bestehen. Bash(git status) und Bash(npm test) kommen problemlos durch. Entfernte Regeln kommen zurück, wenn du den Auto-Modus verlässt.
Was blockiert wird vs. was erlaubt ist
Eine Vertrauensgrenze zieht sich durch die Sicht des Klassifikators auf dein System. Dein lokales Arbeitsverzeichnis ist vertrauenswürdig. Wenn du in einem Git-Repo bist, sind die konfigurierten Remotes dieses Repos vertrauenswürdig. Alles außerhalb dieses Bereichs gilt als extern, bis ein Admin es anders festlegt.
Standardmäßig blockiert
| Kategorie | Beispiele |
|---|---|
| Remote-Code-Ausführung | `curl |
| Datenexfiltration | Sensible Daten an externe Endpunkte senden |
| Produktionsoperationen | Deploys, Migrationen, Datenbankoperationen |
| Massenzerstörung | Massenlöschung in Cloud-Speicher, rm -rf auf vorhandenen Dateien |
| Berechtigungseskalation | IAM- oder Repo-Berechtigungen vergeben |
| Infrastrukturveränderungen | Gemeinsame Infrastruktur ändern |
| Destruktive Git-Operationen | Force push, direkt auf main pushen |
Standardmäßig erlaubt
| Kategorie | Beispiele |
|---|---|
| Lokale Dateioperationen | Dateien im Arbeitsverzeichnis lesen, schreiben, bearbeiten |
| Deklarierte Abhängigkeiten | Pakete installieren, die bereits in deinen Lock-Files oder Manifests stehen |
| Credential-Nutzung | .env lesen und Credentials an ihre passende API senden |
| Nur-Lese-Netzwerk | HTTP-GET-Anfragen, Dokumentation abrufen |
| Branch-Operationen | Auf deinen aktuellen Branch oder einen von Claude erstellten pushen |
Ruf den vollständigen Standard-Regelsatz ab, so wie der Klassifikator ihn liest:
claude auto-mode defaults
Routinemäßige Teamarbeit bringt den Klassifikator manchmal zum Stolpern. Auf das Repo deiner Organisation pushen, in einen Firmenbucket schreiben. Der Klassifikator hat keine Ahnung, dass das deine sind. Admins beheben das, indem sie vertrauenswürdige Infrastruktur unter der autoMode.environment-Einstellung konfigurieren.
Auto-Modus aktivieren
Voraussetzungen
Drei Dinge müssen erfüllt sein:
- Claude Code Team-Plan (Enterprise und API-Unterstützung läuft gerade aus)
- Claude Sonnet 4.6 oder Claude Opus 4.6 (nicht verfügbar auf Haiku, claude-3-Modellen oder Drittanbieter-Providern wie Bedrock oder Vertex)
- Admin-Freischaltung: Ein Admin muss den Auto-Modus in den Claude Code-Admin-Einstellungen aktivieren, bevor Nutzer ihn einschalten können
CLI
Starte eine Session, die in den Auto-Modus wechseln kann:
claude --enable-auto-mode
Shift+Tab wechselt durch die Modi: default -> acceptEdits -> plan -> auto. Dein aktueller Modus wird in der Statusleiste angezeigt.
Oder spring direkt beim Start rein:
claude --permission-mode auto
VS Code
- Öffne die Claude Code-Erweiterungseinstellungen
- Aktiviere Allow dangerously skip permissions (das schaltet den Auto-Modus in der UI frei)
- Klicke auf den Modus-Indikator am unteren Rand des Prompt-Felds
- Wähle Auto aus dem Dropdown
Desktop-App
- Aktiviere den Auto-Modus in den Desktop-Einstellungen
- Nutze den Modus-Selektor neben dem Senden-Button
- Wähle Auto aus dem Dropdown
Desktop wird mit deaktiviertem Auto-Modus ausgeliefert. Du aktivierst ihn in den Einstellungen, bevor er überhaupt als Option erscheint.
Nicht-interaktiver Modus
Skriptbasierte Läufe funktionieren gut mit dem -p-Flag:
claude -p "refactor the auth module" --permission-mode auto
Ein Haken. Wenn der Fallback greift (weiter unten), beendet sich die nicht-interaktive Session. Es ist niemand an der Tastatur, um eine Abfrage zu beantworten.
Unteragenten im Auto-Modus
Teams, die Agentenschleifen und Multi-Agenten-Setups betreiben, müssen wissen, wie das auf Unteragenten durchschlägt. Drei Checkpoints:
Beim Starten: Bevor der Unteragent beginnt, liest der Klassifikator seine delegierte Aufgabenbeschreibung. „Lösche alle Remote-Branches, die diesem Muster entsprechen" wird gleich an der Tür abgewiesen. Der Unteragent läuft nie.
Während der Ausführung: Innerhalb der Kind-Session gelten im Auto-Modus dieselben Erlaubnis- und Blockierregeln wie beim Parent. Jeder permissionMode, den der Unteragent in seinem eigenen Frontmatter gesetzt hat, wird ignoriert. Jeder Tool-Aufruf geht einzeln durch den Klassifikator.
Bei der Rückkehr: Sobald der Unteragent fertig ist, liest der Klassifikator sein vollständiges Aktionsprotokoll. Ein Kind, das beim Start harmlos aussah, könnte mitten im Lauf von etwas entführt worden sein, das es gelesen hat. Wenn der Rückgabe-Durchlauf ein Problem markiert, wird eine Sicherheitswarnung vorne an die Ausgabe des Unteragenten geheftet, damit der Parent reagieren kann.
Drei Checkpoints bedeuten, dass Unteragenten dein blindes Vertrauen nicht brauchen. Der Klassifikator behandelt sie genauso wie die Hauptsession.
Auto-Modus neben den anderen Modi
Hier ist die vollständige Übersicht über alle Berechtigungsmodi, die Claude Code liefert:
default | acceptEdits | plan | auto | dontAsk | bypassPermissions | |
|---|---|---|---|---|---|---|
| Berechtigungsabfragen | Dateibearbeitungen und Befehle | Nur Befehle | Wie default | Keine (außer Fallback) | Keine (blockiert außer vorher genehmigt) | Keine |
| Sicherheitsprüfungen | Du prüfst jede Aktion | Du prüfst Befehle | Du prüfst Befehle | Klassifikator prüft Befehle | Nur deine vorab genehmigten Regeln | Keine |
| Token-Nutzung | Standard | Standard | Standard | Höher (Klassifikator-Aufrufe) | Standard | Standard |
| Am besten für | Sensible Arbeit | Code-Iteration | Codebase-Erkundung | Lang laufende Aufgaben | CI/CD-Pipelines | Nur isolierte Container |
| Risikoniveau | Niedrigsten | Niedrig | Niedrig | Mittel | Hängt von Regeln ab | Höchste |
Der Tausch ist einfach. Du zahlst mehr Tokens und wartest etwas länger pro geprüfter Aktion. Du verlierst den Strom von Abfragen, die jede lange Session zu einer Klick-Übung machen.
Wann du ihn nutzen solltest
Gut geeignet wenn:
- Lange Aufgaben, bei denen ständige Genehmigungen die Konzentration brechen
- Du der Gesamtrichtung vertraust, aber ein Netz unter den rauen Kanten möchtest
- Agentenschleifen ohne jemanden in der Nähe, der jeden Schritt bestätigt
- Du eine sicherere Wahl als
bypassPermissionsaußerhalb eines Containers willst
Schlecht geeignet wenn:
- Produktions-Infrastruktur im Scope ist (dieser Modus blockiert diese Aktionen sowieso, mit gutem Grund)
- Unbekannter Code, bei dem du jeden Schritt im Blick haben willst
- Deterministisch-prüfbare Kontrolle wichtig ist (greife nach
dontAskmit expliziten Erlaubnisregeln) - Die Kosten knapp sind (Klassifikator-Aufrufe kosten Tokens)
Der Fallback
Falsch-Positive sollten deine Session nicht versenken, also fängt der Fallback sie. Wenn der Klassifikator 3 in Folge oder 20 insgesamt in einer Session blockiert, pausiert der Auto-Modus und Claude Code fängt an, wieder manuell um Genehmigung zu bitten.
Keiner der Schwellenwerte kann angepasst werden.
Wenn er greift:
- CLI: Ein Hinweis erscheint im Statusbereich. Genehmige die nächste manuelle Abfrage und die Block-Zähler werden zurückgesetzt, damit du danach im Auto-Modus bleiben kannst.
- Nicht-interaktiver Modus (
-p-Flag): Die Session beendet sich. Niemand ist da, um zu antworten.
Wiederholte Blöcke kommen aus einem von zwei Orten. Die Aufgabe möchte wirklich etwas, das der Klassifikator stoppen soll, oder dem Klassifikator fehlt Kontext über Infrastruktur, die dir tatsächlich gehört. Nutze /feedback, wenn es sich wie ein Falsch-Positiv anfühlt. Wenn er immer wieder verpasst, dass deine Repos und Services vertrauenswürdig sind, lass einen Admin die vertrauenswürdige Infrastruktur in den verwalteten Einstellungen konfigurieren.
Defense in Depth
Eine Ebene ist nie die ganze Geschichte. Der Auto-Modus gibt dir mehr Schutz als bypassPermissions und weniger als jeden Aufruf manuell zu prüfen. Das stärkste Setup stapelt:
Ebene 1: Berechtigungsregeln. Erlaubnis- und Sperrlisten in settings.json werden vor dem Klassifikator aufgelöst. Nutze sie für harte, deterministische Kontrolle.
Ebene 2: Auto-Modus-Klassifikator. Fängt alles, was die Regeln nicht schaffen. Denkt über Kontext nach, nicht nur über Textmuster.
Ebene 3: Hooks. PreToolUse-Hooks führen eigene Logik vor dem Berechtigungssystem aus. Der Permission-Hook liefert einen KI-gestützten Auto-Genehmiger mit einem dreistufigen Ablauf (schnelle Genehmigung, schnelle Ablehnung, LLM-Analyse). Hooks und Auto-Modus koexistieren: Hooks laufen zuerst und können genehmigen, ablehnen oder eskalieren, bevor der Klassifikator den Aufruf sieht.
Ebene 4: Sandboxing. OS-Level-Sandboxing mauert Dateisystem- und Netzwerkzugang auf Kernel-Ebene ab. Selbst wenn der Klassifikator etwas übersieht, hält die Sandbox Shell-Befehle in der Box, die du gezeichnet hast. Das ist wichtig, weil der Klassifikator Absicht liest, während die Sandbox harte Grenzen durchsetzt.
Ebene 5: Selbst-validierende Agenten und Stop-Hooks. Diese halten Agenten auf Kurs und im Scope, fügen eine weitere Überprüfungsebene über der Berechtigungsgeschichte hinzu.
Jede Ebene füllt die Lücke, die die anderen lassen. Das ist Defense in Depth.
Bekannte Einschränkungen
Das wurde als Research Preview veröffentlicht. Sei ehrlich darüber, was das Wort bedeutet:
- Keine Sicherheitsgarantie. Mehrdeutige Nutzerabsicht oder fehlender Umgebungskontext kann dazu führen, dass der Klassifikator eine riskante Aktion übersieht. Das Gegenteil passiert auch (Falsch-Positive bei harmlosen Aktionen).
- Es kostet mehr. Klassifikator-Aufrufe zählen zu deinem Token-Verbrauch. Jede geprüfte Aktion schickt einen Ausschnitt des Transkripts plus den ausstehenden Aufruf. Die meisten Mehrkosten entstehen durch Shell-Befehle und Netzwerkoperationen, weil Nur-Lese-Aktionen und lokale Dateibearbeitungen den Klassifikator komplett überspringen.
- Latenz ist real. Jede Prüfung fügt einen Hin- und Rückweg hinzu, bevor die Aktion ausgeführt wird. Sequenzen schneller Shell-Befehle fühlen sich langsamer an.
- Eingeschränkte Verfügbarkeit. Momentan nur im Team-Plan (Research Preview). Enterprise und API-Unterstützung läuft gerade aus. Sonnet 4.6 oder Opus 4.6 erforderlich. Kein Haiku, kein claude-3, keine Drittanbieter-Provider.
- Kein Ersatz für Review bei sensiblen Operationen. Vertrau ihm bei Arbeit, bei der die Richtung klar ist. Für alles, was Produktion, Credentials oder gemeinsame Infrastruktur betrifft, ist menschliche Prüfung immer noch die richtige Wahl.
Die Kalibrierung verbessert sich mit Daten. /feedback ist der Weg, wie Falsch-Positive und verpasste Blöcke gemeldet werden. Jeder dieser Reports tuned das System.
Was als Nächstes kommt
Team-Plan-Nutzer bekommen daraus einen neuen täglichen Workflow. Der alte Tausch zwischen Sicherheit und Geschwindigkeit hat jetzt eine dritte Option.
Für eine vollständige Sicherheitshaltung rund um den Auto-Modus:
- Schreib Berechtigungsregeln für deterministische Kontrolle bei bestimmten Tools
- Konfiguriere Hooks für eigene Berechtigungslogik, die über das hinausgeht, was der Klassifikator behandelt
- Schalte Sandboxing für OS-Level-Durchsetzung als harten Rückhalt ein
- Lies die Einstellungsreferenz für jede berechtigungsbezogene Option
- Erkunde autonome Agentenschleifen, um das Beste aus reduziertem Prompting bei langen Läufen herauszuholen
Die Berechtigungsabfrage ist nicht mehr der Engpass. Der Klassifikator hat es im Griff. Zurück zum Bauen.
Hören Sie auf zu konfigurieren. Fangen Sie an zu bauen.
SaaS-Builder-Vorlagen mit KI-Orchestrierung.
Claude Code Berechtigungen
Fünf Berechtigungsmodi, ein Tastendruck zum Wechseln und ein klarer Weg, den Modus zur Aufgabe zu passen. Hier ist die vollständige Regelsyntax und wann du welchen Modus einsetzt.
Feedback-Loops
Gib Claude Code einen einzigen Prompt, der Code schreibt, deinen Test- oder Dev-Befehl ausführt, die Ausgabe liest, alles Kaputte behebt und schleift, bis die Suite grün ist.