Auto Mode in Claude Code sicher nutzen, in 10 Schritten ohne Selbstmord-Kommandos

Wenn Du Claude Code länger nutzt, kennst Du den Moment: Du sitzt da und drückst nur noch Enter, weil jede Datei-Änderung und jeder Bash-Befehl einzeln bestätigt werden will. Auto Mode nimmt Dir genau das ab. Claude gibt seine Tool-Calls selbst frei, während im Hintergrund ein Sicherheits-Check prüft ob die Aktion zu dem passt was Du eigentlich wolltest. Klingt nach Vollgas ohne Bremse. Ist es aber nicht, wenn Du verstehst was der Modus blockiert und welche zwei Netze Du selbst drunter spannst.

Wichtig vorweg: Auto Mode ist kein Modus, in den Du automatisch reinrutschst. Der Ausgangsmodus jeder Session bleibt Manual, also Nachfragen vor jeder Aktion. Auto Mode schaltest Du bewusst dazu, per Shift+Tab in der Session oder dauerhaft über defaultMode: "auto" in den Settings. Er ist inzwischen breit verfügbar, aber Du behandelst ihn nicht als Set-and-forget für Produktions-Repos. Wir gehen zehn Schritte durch. Erst die Einordnung, dann das Einschalten, dann die Schutzmechanismen, dann Dein eigenes Netz drunter, am Ende die Frage wann Du ihn überhaupt anmachst.

1. Verstehen was Auto Mode wirklich tut

Auto Mode ist einer von mehreren Permission-Modi in Claude Code. Die Beschreibung in der offiziellen Doku ist knapp und genau: er gibt Tool-Calls automatisch frei, mit Sicherheits-Checks im Hintergrund die verifizieren dass die Aktionen zu Deiner Anfrage passen. Das ist der entscheidende Unterschied zu bypassPermissions. Bypass fragt einfach gar nicht mehr. Auto fragt auch nicht, prüft aber jede Aktion gegen das was Du eigentlich beauftragt hast.

Heißt im Alltag: Du sagst "bau mir das Login-Formular", Claude editiert Dateien und führt npm run build aus ohne zu fragen. Wenn Claude aber plötzlich anfängt eine Datenbank zu droppen oder Dein lokales Git-History wegzuwerfen, greift der Hintergrund-Check. Das ist kein Freifahrtschein, das ist eine andere Art von Bremse.

2. Die Modus-Landkarte im Kopf haben

Bevor Du Auto Mode anschaltest, ordne ihn ein. Claude Code kennt mehrere Permission-Modi, gesetzt über defaultMode in der settings.json. default fragt beim ersten Einsatz jedes Tools. acceptEdits akzeptiert Datei-Edits und harmlose Filesystem-Befehle wie mkdir, touch, mv, cp automatisch, aber nur für Pfade in Deinem Arbeitsverzeichnis. plan ist Plan Mode, also nur lesen und read-only Shell, keine Änderungen an Deinem Code. auto ist unser Thema. bypassPermissions überspringt alle Prompts außer erzwungenen ask-Rules, und selbst da bleibt rm -rf / als Notbremse mit Nachfrage. dontAsk dreht es um und verweigert alles was nicht vorher erlaubt wurde.

Die richtige mentale Reihenfolge von vorsichtig nach forsch ist also: plan, default, acceptEdits, auto, bypassPermissions. Auto sitzt weit vorne im roten Bereich, aber eben nicht ganz. Wer nur Datei-Edits ohne Bestätigung will und keine Bash-Vollmacht braucht, ist mit acceptEdits oft besser bedient.

3. Auto Mode bewusst einschalten

Den Modus wechselst Du innerhalb einer Session über den Permission-Mode-Umschalter in der Oberfläche. Dauerhaft setzt Du ihn über defaultMode in Deinen User-Settings, zum Beispiel:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Mein Rat, mit einer wichtigen Feinheit: Dauerhaft aktivieren lässt sich Auto Mode NUR über Deine User-Settings (~/.claude/settings.json). Ein defaultMode: "auto" in einer Projekt- oder Local-Settings-Datei ignoriert Claude Code bewusst, genau damit Dir kein fremdes Repo das Du klonst den Modus unterschiebt. Wer ihn nicht ständig anhaben will, lässt die User-Settings auf Manual und schaltet stattdessen pro Session per Shift+Tab um. Ein global gesetzter Auto Mode beißt Dich genau dann, wenn Du in ein fremdes oder produktives Repo wechselst und es vergessen hast. Für die meisten ist Pro-Session-Umschalten deshalb die sicherere Wahl.

4. Den Hintergrund-Check nicht für Magie halten

Der Sicherheits-Check prüft ob eine Aktion zu Deiner Anfrage passt. Das ist gut, aber es ist eine Heuristik, kein Vertrag. Wenn Deine Anfrage selbst gefährlich formuliert war ("räum das Repo auf, lösch was nicht gebraucht wird"), dann passt ein destruktiver Befehl unter Umständen sehr wohl zu Deinem Auftrag und wird durchgewunken.

Konsequenz für Deinen Prompt-Stil im Auto Mode: formulier eng. "Bau Feature X in Datei Y" ist besser als "mach das Projekt sauber". Je vager Dein Auftrag, desto größer der Spielraum den der Check als legitim durchlässt. Der Modus ist so sicher wie Deine Anweisung präzise ist.

5. Wissen was Auto Mode trotzdem blockiert

Hier wird es konkret, und das sind verifizierte Regeln aus dem Changelog. Auto Mode blockiert destruktive Git-Befehle wenn Du nicht ausdrücklich gesagt hast dass lokale Arbeit weg darf. Konkret betroffen sind git reset --hard, git checkout -- ., git clean -fd und git stash drop. git commit --amend wird blockiert wenn der Commit nicht vom Agenten in dieser Session gemacht wurde, damit Dir niemand fremde History umschreibt. Und terraform destroy, pulumi destroy sowie cdk destroy sind gesperrt solange Du nicht den konkreten Stack genannt hast.

Das ist die eingebaute Liste der Selbstmord-Kommandos die der Modus für Dich abfängt. Praktisch heißt das: Auto Mode darf bauen und testen, aber Dein uncommitteter Stand und Deine Infrastruktur sind gegen die offensichtlichsten Unfälle geschützt. Verlass Dich trotzdem nicht allein darauf, dafür kommt Schritt 6.

6. Deny-Rules als hartes Netz drunter spannen

Die Schutzliste aus Schritt 5 ist fix. Dein eigenes Netz baust Du mit Deny-Rules in den Permissions. Wichtig zu wissen: Rules werden in der Reihenfolge deny, dann ask, dann allow ausgewertet. Der erste Treffer gewinnt. Eine Deny-Rule sticht also immer, auch gegen eine speziellere Allow-Rule. Das macht deny zu Deinem zuverlässigsten Werkzeug.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Read(./.env)",
      "Bash(docker system prune *)"
    ]
  }
}

Ein Detail das viele übersehen: eine Deny-Rule mit reinem Tool-Namen wie Bash entfernt das Tool komplett aus Claudes Kontext, Claude sieht es gar nicht mehr. Eine Deny-Rule mit Pattern wie Bash(rm *) lässt das Tool da und blockt nur die passenden Aufrufe. Für Auto Mode willst Du meistens die Pattern-Variante, damit Claude weiter normale Befehle ausführen kann und nur die gefährlichen anstoßen.

7. Auto Mode in einem Worktree isolieren

Das beste Netz ist räumliche Trennung. Wenn Auto Mode in einem eigenen Git-Worktree läuft, kann eine durchgerutschte Aktion maximal diesen Worktree treffen, nicht Deinen Hauptbranch. Du legst einen Worktree an, startest Claude dort im Auto Mode, und am Ende mergst Du bewusst nur was sauber ist. Geht etwas schief, löschst Du den Worktree und Dein Original war nie berührt.

Wie das Setup im Detail läuft, steht im Playbook Claude Code mit Git Worktrees und in Parallele Claude Sessions mit Worktrees. Die Kombination Auto Mode plus Worktree ist für mich die einzige Konstellation in der ich Auto Mode in einem ernsthaften Repo überhaupt laufen lasse.

8. Die Sandbox als zweite Trennschicht

Worktree trennt das Git-Risiko. Die Bash-Sandbox trennt das System-Risiko. Wenn Claude im Auto Mode Bash-Befehle selbst freigibt, willst Du dass diese Befehle in einer eingeschränkten Umgebung laufen und nicht ungehindert an Dein ganzes System kommen. Das Setup dafür steht Schritt für Schritt im Playbook Claude Code Bash Sandbox einrichten.

Worktree plus Sandbox plus Deny-Rules ist die Dreifach-Absicherung. Jede Schicht fängt eine andere Art von Fehler. Das klingt nach viel, ist aber einmal eingerichtet und dann dauerhaft Deine Standard-Umgebung für unbeaufsichtigtes Arbeiten.

9. Auto Mode für andere komplett verbieten

Wenn Du in einem Team arbeitest oder eine Umgebung absicherst in der niemand Auto Mode nutzen soll, gibt es dafür einen harten Schalter. In den Settings setzt Du permissions.disableAutoMode auf "disable". Analog sperrt permissions.disableBypassPermissionsMode den Bypass-Modus. Am wirksamsten ist das in Managed Settings, weil es dort nicht von einzelnen Entwicklern überschrieben werden kann.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

Das ist die richtige Antwort wenn jemand fragt "wie verhindere ich dass ein Junior aus Versehen die ganze Vorsicht abschaltet". Nicht über Vertrauen regeln, über Managed Settings.

10. Wissen wann Du Auto Mode anmachst und wann nicht

Auto Mode ist stark für Aufgaben mit vielen kleinen wiederholten Schritten in einem Repo dem Du vertraust. Größerer Refactor mit klarem Muster, Test-Suite grün ziehen, eine Migration durch viele Dateien tragen. Da spart er Dir echtes Generve und der Hintergrund-Check plus Deine Deny-Rules fangen die groben Schnitzer.

Finger weg dagegen bei produktivem Code ohne Worktree, bei vagen Aufträgen, bei allem was Infrastruktur oder Datenbanken anfasst, und bei fremden Repos deren Inhalt Du nicht überblickst. Und weil Auto Mode Dir die Freigaben abnimmt: behalte die Sessions am Anfang im Auge statt nebenbei was anderes zu machen. Vertrauen baust Du auf indem Du zuschaust, nicht indem Du wegschaust.

Was als nächstes

Wenn Auto Mode Dir zu forsch ist, ist Plan Mode der ruhige Gegenpol, dort liest Claude nur und schlägt vor bevor irgendwas passiert. Lies dazu Plan Mode richtig nutzen. Wenn Dich das Thema Sicherheit grundsätzlich interessiert, ist Confused Deputy Audit für Claude Code der nächste Schritt. Und wer beim unbeaufsichtigten Arbeiten auf die Kosten schauen will, findet die Routine in Claude Code Cost Controls. Wer noch kein sauberes Git-Setup als Sicherheitsgurt hat, fängt am besten beim Git für KI Quickstart an, denn ohne Commit-Disziplin nützt Dir das beste Permission-System wenig.

Source

• Permission-Modi und Deny-Rule-Reihenfolge: Configure permissions, Claude Code Docs
• Auto-Mode-Schutzregeln für Git, Terraform, Pulumi, CDK: Claude Code Changelog