Rechte und Sandbox

Bevor Claude Code eine Datei ändert, einen Befehl startet oder eine Seite abruft, fällt eine Entscheidung. Treffen kann sie der Mensch an einer Rückfrage oder eine Regel in den Einstellungen. Im Auto-Modus urteilt ein zweites Modell, und bei eingeschalteter Sandbox begrenzt das Betriebssystem einen laufenden Befehl. Die Doku zu den Rechtemodi (externe Seite, code.claude.com) trennt dabei zwei Fragen. Der Modus entscheidet, ob Claude vor einer Aktion fragt. Sandbox und äußere Grenzen entscheiden, was die Aktion erreicht, sobald sie läuft.

Dieses Kapitel zeigt die Reihenfolge, in der diese Stellen prüfen, und wie man sie bedient. Warum die Rückfrage allein wenig schützt und was Messungen über den Klassifikator sagen, steht in Vibe-Coding / Agentic Engineering, Kapitel 08. Was eine Sandbox im Betriebssystem leistet und wo sie nachgibt, erklärt Vibe-Coding / Agentic Engineering, Kapitel 09. Wie man den Modus mit Shift+Tab wechselt, zeigt Kapitel 03.

Der Weg einer Aktion

Jeder Aufruf eines Werkzeugs läuft durch feste Stationen. Die Doku zu den Rechten im Agent SDK (externe Seite, code.claude.com) zählt sie der Reihe nach auf. Die Doku zu Claude Code bestätigt die Folge in Teilen. Ein Hook, der mit dem Rückgabewert 2 endet, hält den Aufruf an, bevor eine Regel geprüft wird. Ein Verbot sperrt in jedem Modus, auch in bypassPermissions.

1. Hook: Ein Hook auf das Ereignis PreToolUse sieht den Aufruf zuerst. Er kann ihn sperren, eine Rückfrage erzwingen oder ihn durchwinken.
2. Verbot: Eine passende deny-Regel sperrt den Aufruf, in jedem Modus.
3. Rückfrageregel: Eine passende ask-Regel erzwingt eine Rückfrage.
4. Modus: bypassPermissions lässt fast alles durch, acceptEdits nimmt Änderungen an Dateien im Arbeits­ver­zeichnis an. Er gibt dort auch gängige Dateibefehle der Shell frei, darunter rm, rmdir und sed. Was diese Befehle an einer Datei ändern, die Claude vorher nicht selbst bearbeitet hat, holt das Zurückspulen nicht zurück.
5. Erlaubnis: Eine passende allow-Regel gibt frei. Lesen im Arbeits­ver­zeichnis und eingebaute, nur lesende Befehle brauchen dafür keine Regel.
6. Der Rest: Was jetzt noch offen ist, legt Claude Code im manuellen Modus dem Menschen vor. Im Auto-Modus urteilt der Klassifikator, in dontAsk lehnt Claude Code ab, sofern kein installierter Mod freigibt.

Die erste Station, die entscheidet, beendet den Weg. Ein Hook, der durchwinkt, überspringt dabei weder Verbote noch Rückfrageregeln (Doku zu den Rechten (externe Seite, code.claude.com)). Unter den drei Regelarten steht die Reihenfolge fest, und wie eng eine Regel gefasst ist, ändert daran nichts.

Mit installierten Mods ändert sich die erste Station. Vor den Hooks der Mods auf tool.call laufen nur die Hooks aus den verwalteten Einstellungen (Doku zu den Ereignissen der Mods (externe Seite, code.claude.com)). Sperrt einer davon den Aufruf, läuft für ihn kein Hook eines Mods auf tool.call. Die übrigen Hooks auf PreToolUse laufen erst, wenn der letzte Mod den Aufruf weiterreicht. Die ganze Folge zeigt Kapitel 18.

Der Klassifikator kommt im Auto-Modus erst nach den Regeln an die Reihe (Doku zum Einstellen des Auto-Modus (externe Seite, code.claude.com)). Verbote und Rückfrageregeln wirken deshalb auch dort, wo er eine Aktion durchlassen würde.

Eine Station liegt außerhalb dieser Reihe. Ist die Sandbox eingeschaltet, begrenzt das Betriebssystem einen Shell-Befehl, während er läuft. Die Grenze hält unabhängig davon, wer den Befehl vorher freigegeben hat (Sandbox-Doku (externe Seite, code.claude.com)).

Eine Anweisung in der CLAUDE.md lenkt, was Claude versucht. Was Claude Code erlaubt, entscheiden die Stationen oben. Im Auto-Modus liest der Klassifikator die CLAUDE.md allerdings mit. Eine Zeile wie „nie force-pushen“ lenkt dort also auch sein Urteil.

Die Rückfrage und was sie sich merkt

Im manuellen Modus legt Claude Code dem Menschen jede Aktion vor, die keine Station vorher entschieden hat. Welche Werkzeuge dabei fragen, listet Kapitel 04. Wie weit die Antwort „Yes, and don’t ask again“ reicht, hängt am Werkzeug (Doku zu den Rechten (externe Seite, code.claude.com)):

Die dauerhaften Zustimmungen schreibt Claude Code als Regel in .claude/settings.local.json. Wo diese Datei liegt, steht in Kapitel 15.

Manchmal fehlt die Antwort für „nicht mehr fragen“. Claude Code bietet sie nur an, wenn die Rückfrage alles zeigen kann, was die gespeicherte Regel später erlauben würde. Dann gibt man die Aktion einmal frei oder schreibt die Regel selbst.

Zu einer einzelnen Freigabe oder Ablehnung kann man Claude eine Notiz mitgeben. Wer in der Rückfrage auf Yes oder No steht und Tab drückt, öffnet ein Feld dafür. Bei Yes bekommt Claude die Notiz nach dem Ergebnis der Aktion, bei No als Grund der Ablehnung, und arbeitet weiter. Ein No ohne Notiz beendet im Hauptgespräch Claudes laufende Antwort. Rückfragen zu WebFetch und zum Browser haben das Feld nicht.

Seit Version 2.1.247 vom 26.08.2026 bietet die Rückfrage zu einem Bash-Befehl eine weitere Antwort, wenn der Auto-Modus verfügbar ist. Sie gibt den Befehl frei und schaltet die Sitzung in den Auto-Modus (Versionsliste (externe Seite, code.claude.com)).

Regeln für allow, ask und deny

Regeln stehen im Block permissions einer Einstellungsdatei, in drei Listen. Eine Regel nennt ein Werkzeug, bei Bedarf mit einer Angabe in Klammern:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)"
    ]
  }
}

Damit laufen npm-Skripte und Commits ohne Rückfrage, vor jedem Push fragt Claude Code nach, und die Datei .env bleibt für die Dateiwerkzeuge gesperrt. Geprüft wird in fester Reihenfolge: erst Verbot, dann Rückfrage, dann Erlaubnis. Eine enge Erlaubnis schneidet deshalb keine Ausnahme aus einem weiten Verbot. Was in der Klammer bei welchem Werkzeug stehen darf, zeigt die Tabelle in Kapitel 04. Wie Regeln aus mehreren Dateien zusammenkommen, steht in Kapitel 15.

Seit Version 2.1.0 vom 07.01.2026 darf der Stern in einer Bash-Regel an jeder Stelle stehen, etwa in Bash(git * main) (Versionsliste (externe Seite, code.claude.com)). Eine Regel deckt so eine ganze Familie von Befehlen ab. Wo der Stern gefährlich weit greift, zeigt die Vertiefung.

Rückfrageregeln gibt es seit Version 1.0.72 vom 11.08.2025. Mit ihnen setzt man einen festen Haltepunkt, der auch im Auto-Modus hält. Eine Regel wie Bash(git push *) erzwingt dort die Rückfrage, bevor der Klassifikator überhaupt gefragt wird.

Ein Verbot auf den bloßen Werkzeugnamen nimmt das Werkzeug ganz aus der Sitzung. Steht Bash unter deny, sieht Claude das Werkzeug gar nicht mehr. Eine enge Regel wie Bash(rm *) lässt das Werkzeug stehen und sperrt nur die passenden Aufrufe.

Am bequemsten pflegt man Regeln mit /permissions. Der Dialog listet jede Regel mit der Einstellungsdatei, aus der sie stammt. Man kann ihn öffnen, während Claude arbeitet. Seit Version 2.1.234 vom 17.08.2026 gilt eine Änderung dort schon ab dem nächsten Werkzeugaufruf derselben Antwort.

Wer den Auto-Modus hat

Den Auto-Modus bekamen die Tarife nacheinander:

• 24.03.2026: Research Preview im Tarif Team, mit Sonnet 4.6 und Opus 4.6. Enterprise und Konten über die API sollten in den folgenden Tagen folgen (Ankündigung (externe Seite, claude.com)). Der Wochenbericht beschreibt ihn als Mittelweg zwischen der Rückfrage vor jedem Schritt und --dangerously-skip-permissions (Wochenbericht 13 (externe Seite, code.claude.com)).
• 16.04.2026, Version 2.1.111: auch für Max mit Opus 4.7; der Startschalter --enable-auto-mode entfällt.
• 18. bis 22.05.2026: auch im Tarif Pro. Der Wochenbericht nennt dazu Sonnet 4.6 neben Opus (Wochenbericht 21 (externe Seite, code.claude.com)).
• 27.05.2026, Version 2.1.152: Die vorherige Zustimmung zum Auto-Modus entfällt.
• 10.07.2026: allgemein verfügbar für alle Nutzer, laut Nachtrag zur Ankündigung.
• 14.08.2026: Startmodus neuer Sitzungen auf Pro, Max und Team. Eine selbst gesetzte Voreinstellung bleibt, solange man den Wechsel nicht annimmt. Die Prüfungen des Klassifikators zählen dort schon vor diesem Tag nicht mehr zum Nutzungslimit (Wochenbericht 32 (externe Seite, code.claude.com)).
• 28.09.2026, Version 2.1.284: Startmodus interaktiver Sitzungen im Terminal und in VS Code auf jedem Plan und bei jedem Anbieter, solange keine Einstellung einen anderen Modus festlegt.

Heute steht der Auto-Modus laut Doku auf allen Plänen bereit. In Team und Enterprise ist er in der Voreinstellung verfügbar, und Administratoren können ihn für die Organisation abschalten.

Dazu braucht es ein passendes Modell. Über die API von Anthropic sind das Opus 4.6 und neuer, Sonnet 4.6 und neuer, Haiku 5.5 und die Fable-Modelle. Bei Amazon Bedrock, Googles Agent Platform und Microsoft Foundry beginnt die Liste erst bei Sonnet 5 und Opus 4.7. Haiku 5.5 und die Fable-Modelle laufen dort ebenfalls. Ältere Modelle wie Sonnet 4.5 laufen bei keinem Anbieter im Auto-Modus. Fehlt eine Voraussetzung, beginnt eine Sitzung, die im Auto-Modus starten soll, im manuellen Modus.

Was der Klassifikator prüft

Der Klassifikator vertraut in der Voreinstellung dem Arbeits­ver­zeichnis und den Remotes, die beim Start der Sitzung eingetragen waren (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Alles andere gilt als extern. Gesperrt sind ab Werk unter anderem:

• Code herunterladen und ausführen, etwa mit curl | bash,
• sensible Daten an fremde Adressen schicken,
• Deploys und Migrationen in Produktion,
• ein Force Push und Befehle wie git reset --hard, die ungesicherte Arbeit verwerfen,
• Zugangsdaten ins Gespräch oder in eine Datei schreiben.

Ohne Rückfrage laufen dagegen Dateiarbeit im Arbeits­ver­zeichnis, die Installation der Abhängigkeiten aus Lockfile oder Manifest und ein Push auf einen Branch des eigenen Repositorys. Ausgenommen sind Branches, deren Name ein Ziel für Deploy oder Veröffentlichung nennt, etwa production. Die vollständigen Listen gibt claude auto-mode defaults als JSON aus.

Wo das Firmennetz beginnt, weiß der Klassifikator nicht von selbst. Ein Push in ein anderes Repository der eigenen Organisation oder ein Schreibzugriff auf einen Speicher des Teams bleiben gesperrt, bis man sie in autoMode.environment einträgt. Wie das geht, zeigt die Vertiefung.

Läuft die Prüfung auf dem Server, als Teil der Anfragen an das Modell, die ohnehin unterwegs sind, kostet sie nichts extra (Doku zu den Kosten des Klassifikators (externe Seite, code.claude.com)). Wann eine Sitzung doch eigene, berechnete Anfragen stellt, steht ebenfalls in der Vertiefung.

Die Sandbox für Bash

Seit Version 2.0.24 vom 20.10.2025 hat Claude Code eine Sandbox für Bash, zuerst unter Linux und macOS (Versionsliste (externe Seite, code.claude.com)). Anthropic zählte damals im eigenen Gebrauch 84 Prozent weniger Rückfragen (Engineering-Beitrag zur Sandbox (externe Seite, anthropic.com)). Die Zahl stammt vom Hersteller und aus seiner eigenen Arbeit.

Heute läuft die Sandbox unter macOS, Linux und WSL2. In der Voreinstellung ist sie aus. Eingeschaltet wird sie mit /sandbox in einer Sitzung oder mit sandbox.enabled in einer Einstellungsdatei.

Der Befehl öffnet ein Fenster mit drei Reitern. Unter Mode wählt man, ob Befehle in der Sandbox ohne Rückfrage laufen. Unter Overrides legt man fest, ob ein Befehl nach einem Fehlschlag außerhalb wiederholt werden darf, und unter Config steht, was gerade gilt. Fehlt unter Linux ein nötiges Paket, zeigt das Fenster nur einen Reiter Dependencies.

Die Sandbox umschließt Shell-Befehle und die Prozesse, die sie starten. Die Dateiwerkzeuge von Claude, MCP-Server und Hooks laufen außerhalb. Ob sie greift, prüft man mit einem Befehl, der scheitern muss, etwa touch ~/sandbox-probe außerhalb des Arbeits­ver­zeich­nisses. Claude soll ihn ausführen. Ein Befehl, den man selbst nach ! tippt, läuft meist ohne Sandbox.

Lesen darf ein Befehl in der Sandbox ab Werk fast den ganzen Rechner, auch ~/.ssh. Seit Version 2.1.187 vom 23.06.2026 sperrt sandbox.credentials einzelne Dateien mit Zugangsdaten und geheime Umge­bungs­va­ria­blen. Was die Sandbox nicht abdeckt, etwa einen Befehl, der nach einem Fehlschlag außerhalb läuft, zeigt Vibe-Coding / Agentic Engineering, Kapitel 09. Wo die Sandbox bei Wartungsarbeit an Rechner und Netz im Weg steht, zeigt Kapitel 12.

Welche Einstellung wofür passt

Die Doku nennt für typische Ziele einen Startpunkt (Doku zu den Rechtemodi (externe Seite, code.claude.com)):

• Jede Aktion selbst prüfen, etwa bei fremdem Code: manueller Modus mit claude --permission-mode default.
• Weniger Rückfragen ohne Klassifikator: manueller Modus plus Sandbox, in der Befehle ohne Rückfrage laufen. Verbote und Rückfrageregeln für einzelne Befehle gelten weiter.
• Längere Arbeit ohne Unterbrechung: Auto-Modus. Eine Sandbox oder ein Container ist dann eine zweite Schicht.
• Ein Lauf in CI mit genauer Liste: dontAsk mit --allowedTools, mehr dazu in Kapitel 29.
• Unbeaufsichtigt in einem Container: claude -p mit --dangerously-skip-permissions, nur in einem Container, einer virtuellen Maschine oder der Sandbox-Runtime und unter Linux und macOS ohne Root-Rechte.

Die Vertiefung zeigt, wie Muster in Bash-Regeln greifen und wie man den Klassifikator auf die eigene Umgebung einstellt. Dazu kommen seine Kosten, der Schutz von Zugangsdaten in der Sandbox und der Restricted Mode.

Der Überblick hat die Stationen sortiert, an denen eine Aktion vorbeimuss. Im Alltag hakt es an den Einzelheiten. Ein Stern erlaubt mehr als gedacht, der Klassifikator hält die eigene Firma für fremd, oder vor einer Aktion steht plötzlich ein Hinweis auf Kosten. Diese Ebene geht die Stationen der Reihe nach durch. Die Lücken, die eine Pfadregel lässt, und die Pfade, die keine Erlaubnis öffnet, stehen schon in Vibe-Coding / Agentic Engineering, Kapitel 08.

Muster in Bash-Regeln

Ein Stern in einer Bash-Regel steht für beliebigen Text, auch für Leerzeichen (Doku zu den Rechten (externe Seite, code.claude.com)). Alles vor dem ersten Stern vergleicht Claude Code wörtlich. Diese Wörter begrenzen also, was die Regel erlaubt. Der Stern gehört deshalb hinter den Unterbefehl: Bash(git log *) erlaubt nur git log, Bash(git *) jeden Befehl von git.

Steht der Stern vor dem Unterbefehl, wie in Bash(git * main), passt die Regel auf jeden Unterbefehl und jede Option davor. Dazu gehört git -c, mit dem git ein beliebiges Programm startet. Seit Version 2.1.246 vom 25.08.2026 warnt Claude Code beim Start vor einer solchen Erlaubnis (Versionsliste (externe Seite, code.claude.com)).

Auch das Leerzeichen vor dem Stern zählt mit. Bash(ls *) passt auf ls und ls -la. Erst Bash(ls*) ohne Leerzeichen trifft auch lsof. Die Schreibweise Bash(ls:*) bedeutet dasselbe wie Bash(ls *), aber nur am Ende eines Musters.

Zusammengesetzte Befehle zerlegt Claude Code an &&, ||, ;, |, |&, & und Zeilenumbrüchen. Eine Erlaubnis muss jeden Teil für sich abdecken. Verbote und Rückfrageregeln greifen schon, wenn ein einziger Teil passt, auch in einer Subshell oder im Rumpf einer Schleife. Wer git status && npm test dauerhaft freigibt, bekommt eine Regel je Teilbefehl, der eine Freigabe braucht, höchstens fünf.

Vor dem Vergleich streicht Claude Code einige Vorsätze, die nur den eigentlichen Befehl ausführen: timeout, time, nice, nohup, stdbuf und einige Builtins der Shell. Bash(npm test *) trifft so auch timeout 30 npm test. Die Liste ist fest eingebaut.

Werkzeuge wie npx, docker exec oder devbox run stehen nicht darauf. Sie führen ihre Argumente als Befehl aus, und Bash(devbox run *) erlaubt deshalb alles hinter run, auch ein rm -rf. Für solche Werkzeuge schreibt man je inneren Befehl eine eigene Regel, etwa Bash(devbox run npm test).

Eine Bash-Regel vergleicht den Text, den Claude schreibt. Ein Verbot auf Bash(curl *) hält curl https://example.com an. Derselbe Aufruf über /usr/bin/curl oder in sh -c läuft an der Regel vorbei, und über ihn entscheiden die übrigen Regeln und der Modus. Was unabhängig vom Wortlaut gelten muss, gehört in die Sandbox.

Parameter, MCP-Server und Gruppen von Werkzeugen

Seit Version 2.1.178 vom 15.06.2026 kann eine Regel einen Parameter des Werkzeugs treffen, in der Form Werkzeug(parameter:wert) (Versionsliste (externe Seite, code.claude.com)). Das geht nur bei Verboten und Rückfrageregeln, und nur für eingebaute Werkzeuge. Der Grund: Ein bestimmter Wert eines Parameters sagt nichts darüber, ob der übrige Aufruf harmlos ist.

• Agent(model:opus) trifft Subagents, die das Modell Opus anfordern.
• Agent(isolation:worktree) trifft Subagents in einem eigenen Worktree.
• Bash(run_in_background:true) trifft Befehle, die im Hintergrund laufen.

Eine Regel nennt genau einen Parameter, und der Stern steht für beliebigen Text im Wert. Lässt Claude einen Parameter weg, trifft die Regel nie. Verglichen wird der Wert, wie Claude ihn schickt. Agent(model:opus) trifft deshalb nur den Kurznamen opus. Welche Namen und Werte ein Aufruf enthält, zeigt ein Start mit --verbose.

Ausgenommen ist das Hauptfeld eines Werkzeugs, bei Bash etwa der Befehl selbst. Eine Regel wie Bash(command:rm *) ließe sich mit einem zusammengesetzten Befehl umgehen, Claude Code übergeht sie deshalb mit einer Warnung.

Für MCP-Server nennt eine Regel den Server so, wie er eingerichtet ist. mcp__github trifft jedes Werkzeug des Servers github, mcp__github__get_issue ein einzelnes. Die Form mit Stern, mcp__github__*, gibt es seit Version 2.0.70 vom 15.12.2025. Einen Parameter an einem MCP-Werkzeug trifft nur ein Verbot, das man beim Start mit --disallowedTools übergibt. In einer Einstellungsdatei übergeht Claude Code solche Regeln.

Verbote und Rückfrageregeln nehmen auch Muster im Namen des Werkzeugs an. "*" trifft jedes Werkzeug, "mcp__*" jedes Werkzeug aus jedem MCP-Server. Eine Erlaubnis darf ein solches Muster erst hinter einem festen Servernamen verwenden, etwa mcp__github__get_*. Eine Erlaubnis auf "*" oder "mcp__*" übergeht Claude Code mit einer Warnung. Hat die Organisation ein Werkzeug eines Connectors auf Rückfrage gesetzt, wirken eigene Erlaubnisse dafür ebenfalls nicht.

Ein Tippfehler im Namen fällt bei Verboten und Rückfrageregeln auf. Trifft ein Name kein bekanntes Werkzeug, warnt Claude Code beim Start. Gemeint ist der kanonische Name aus der Werkzeugreferenz. Das Etikett in der Oberfläche weicht davon manchmal ab, etwa „Stop Task“ für TaskStop.

Regeln beim Start übergeben

Für eine einzelne Sitzung nimmt Claude Code Regeln auch auf der Kommandozeile an. --allowedTools fügt Erlaubnisse hinzu, --disallowedTools Verbote (Kommandozeilen-Referenz (externe Seite, code.claude.com)). Ein bloßer Werkzeugname in --disallowedTools nimmt das Werkzeug ganz aus der Sitzung. Welche Werkzeuge es in der Sitzung überhaupt gibt, legt --tools fest.

Die Regeln vom Start reihen sich in dieselbe Rangfolge ein wie die aus den Dateien. Ein Verbot gilt, auf welcher Ebene es auch steht. Ein Verbot der Organisation hebt also auch --allowedTools nicht auf. Wie man Rechte für einen Lauf ohne Dialog setzt, steht in Kapitel 29.

Der Dialog /permissions

/permissions öffnet einen Dialog. Er zeigt die Regeln nach Geltungsbereich, nimmt neue auf und löscht alte, verwaltet die Arbeits­ver­zeich­nisse und listet die letzten Ablehnungen im Auto-Modus (Befehlsübersicht (externe Seite, code.claude.com)). Der alte Name /allowed-tools funktioniert weiter.

Im Reiter „Recently denied“ steht jede Aktion, die der Klassifikator abgelehnt hat. Seit Version 2.1.89 vom 01.04.2026 lässt sie sich dort erneut anstoßen. Ein Druck auf r markiert die Aktion. Beim Schließen sagt Claude Code dem Modell, dass es den Aufruf wiederholen darf (Doku zum Einstellen des Auto-Modus (externe Seite, code.claude.com)).

Seit Version 2.1.246 vom 25.08.2026 gibt es einen Reiter „Auto mode“. Er zeigt die Regeln des Klassifikators und die Einträge zur eigenen Umgebung, nur wenn der Auto-Modus für die Sitzung verfügbar ist. Einträge aus verwalteten Einstellungen und aus --settings sind dort schreibgeschützt. Jede Änderung speichert der Reiter in ~/.claude/settings.json.

Den Klassifikator einstellen

Was der Klassifikator für vertrauenswürdig hält und was er sperrt, steht im Block autoMode einer Einstellungsdatei. Er wirkt aus den Nut­zer­ein­stel­lungen, aus verwalteten Einstellungen und aus --settings beim Start. Aus den Dateien eines Projekts liest der Klassifikator ihn nicht. Der Grund: Ein fremdes Repository oder ein Schritt im Build könnte sonst eigene Erlaubnisse einschleusen. Für .claude/settings.local.json gilt das seit Version 2.1.207 vom 11.07.2026.

Meist reicht der Eintrag environment. Er beschreibt in ganzen Sätzen, welche Repositories, Speicher, Domains und Dienste zur eigenen Umgebung gehören. Der Klassifikator liest die Einträge als Regeln in natürlicher Sprache.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted internal domains: *.corp.example.com"
    ]
  }
}

"$defaults" setzt die eingebauten Einträge an dieser Stelle ein, die eigenen kommen davor oder dahinter. Das geht seit Version 2.1.118 vom 23.04.2026.

Einen Entwurf schreibt /auto-mode-setup. Der Befehl liest die CLAUDE.md, die README, Kon­fi­gu­ra­ti­ons­da­teien und Remotes des Projekts. Dazu kommen Hosts und Befehlsnamen aus den letzten Sitzungen dort. Die eigenen Nachrichten liest er dabei nie. Nimmt man den Entwurf an, landet er in ~/.claude/settings.json. Er läuft mit Pro, Max, Team und Enterprise sowie mit einem API-Schlüssel der Claude Console. Mit Pro, Max oder Team braucht er mindestens Version 2.1.228, mit Enterprise oder dem API-Schlüssel 2.1.283. In einer Cloud-Sitzung läuft er nicht.

Drei weitere Listen ersetzen oder ergänzen die Regeln selbst. Innerhalb des Klassifikators gilt eine Rangfolge in vier Stufen:

1. hard_deny sperrt ohne Ausnahme. Weder eine Absicht des Nutzers noch eine Ausnahme hebt es auf.
2. soft_deny sperrt als Nächstes, für zerstörerische Aktionen.
3. allow nimmt einzelne Fälle aus soft_deny heraus.
4. Eine ausdrückliche Absicht hebt die übrigen Sperren aus soft_deny auf. Sie muss genau die Aktion beschreiben, die Claude ausführen will, etwa „mach einen Force Push auf diesen Branch“. Eine allgemeine Bitte wie „räum das Repository auf“ reicht dafür nicht.

hard_deny gibt es seit Version 2.1.136 vom 08.05.2026. Jede dieser Listen ohne "$defaults" ersetzt die eingebaute vollständig. Wer soft_deny so setzt, verliert die Sperren für Force Push, curl | bash und Deploys in Produktion.

Die Einträge aus allen Ebenen kommen zusammen. Ein Entwickler kann deshalb mit einem eigenen allow eine Sperre der Organisation aus soft_deny aufheben. Was nie laufen darf, gehört als permissions.deny in verwaltete Einstellungen. Dort greift es vor dem Klassifikator.

Enge Bash-Regeln wie Bash(npm test) gelten im Auto-Modus weiter und entscheiden vor dem Klassifikator. Ein Skriptpfad oder eine Option, die der Anfang der Regel nicht vorhersah, kommt so ungeprüft durch. Seit Version 2.1.193 vom 25.06.2026 schickt autoMode.classifyAllShell jeden Shell-Befehl an den Klassifikator. Jeder Befehl wartet dann auf ein Urteil.

Was gerade gilt, zeigt die Shell:

• claude auto-mode defaults gibt die eingebauten Regeln als JSON aus, mit --label nur die Regeln eines Namens.
• claude auto-mode config zeigt die wirksame Fassung mit den eigenen Einträgen.
• claude auto-mode critique lässt die eigenen Regeln von einem Modell gegenlesen und meldet mehrdeutige, doppelte und solche, die Fehlalarme erwarten lassen.
• claude auto-mode reset entfernt seit Version 2.1.212 den Block aus den Nut­zer­ein­stel­lungen.

Wenn der Klassifikator sperrt

Eine Sperre zeigt Claude Code am Aufruf selbst, als Hinweis über der Eingabezeile und im Reiter „Recently denied“. Seit Version 2.1.193 nennt die Meldung einen Grund. Der Text in eckigen Klammern, etwa [Data Exfiltration], ist der Name der Regel, die gegriffen hat. Ihren vollen Wortlaut gibt claude auto-mode defaults --label aus. Ist der Aufruf in einer Zusammenfassung verborgen, öffnet Ctrl+O das ganze Transkript.

Die Doku nennt drei Auswege, je nachdem, worum es geht:

• Ein Ziel, das die Aufgabe dauernd braucht, etwa eine Paketquelle oder ein interner Dienst: ein Eintrag in autoMode.environment.
• Ein Befehl, der künftig ohne Prüfung laufen soll: eine allow-Regel.
• Eine einzelne Aktion, die man wirklich wollte: die Absicht in der nächsten Nachricht sagen und Claude einen neuen Versuch machen lassen.

Steht unter dem Aufruf „Not run“ oder ein Hinweis, dass der Auto-Modus die Aktion nicht bewerten konnte, hat der Klassifikator gar nicht geurteilt. Dann hilft keiner der drei Auswege, die Ursache liegt bei der Prüfung selbst. Wer jede Ablehnung mit dem genauen Aufruf festhalten will, hängt einen Hook an das Ereignis PermissionDenied. Ab wie vielen Sperren der Auto-Modus wieder fragt, steht in Vibe-Coding / Agentic Engineering, Kapitel 08.

Was der Klassifikator kostet

Der Klassifikator prüft auf einem von zwei Wegen. Auf dem ersten bittet Claude Code den Server um das Urteil, als Teil der Anfragen an das Modell, die ohnehin unterwegs sind. Auf dem zweiten schickt es eigene Anfragen an den Klassifikator. Ab welcher Version welche Sitzung den ersten Weg nimmt, steht in Vibe-Coding / Agentic Engineering, Kapitel 08. Für die Kosten zählt, welcher Weg gilt.

Der erste Weg kostet nichts extra. Seit Version 2.1.278 vom 19.09.2026 ist er auch für Konten über die API, für Enterprise und bei Cloud-Anbietern die Voreinstellung (Versionsliste (externe Seite, code.claude.com)). Erreicht die Prüfung auf dem Server eine Sitzung nicht, fällt Claude Code auf eigene Anfragen zurück. Auf manchen Konten zählen die dann zum Verbrauch an Token, und Claude Code hält vor der ersten geprüften Aktion mit einem Hinweis an (Doku zu den Kosten des Klassifikators (externe Seite, code.claude.com)).

Pro, Max und Team sehen diesen Hinweis nie. Die häufigste Ursache ist ein Gateway oder Proxy zwischen Claude Code und der API, der Felder der Anfrage oder der Antwort verwirft. Enter setzt die Sitzung mit berechneten Prüfungen fort, Esc bricht die Aktion ab. Ob eine Sitzung gerade auf dem Server geprüft wird, zeigt /status in der Zeile „Auto mode server“. Wer weiß, dass das eigene Gateway die Prüfung nie durchlässt, setzt CLAUDE_CODE_AUTO_MODE_SERVER=0. Die Doku führt die Variable als vorläufig.

Der Klassifikator läuft in der Voreinstellung auf Sonnet 5, gleich welches Modell man mit /model gewählt hat. Läuft die Sitzung auf Sonnet 4.6, prüft ihr eigenes Modell. Jede Prüfung ist ein zusätzlicher Modellaufruf, auf den die Aktion wartet. Lesen und Änderungen im Arbeits­ver­zeichnis überspringen den Klassifikator, die Last kommt also vor allem von Shell-Befehlen und Zugriffen aufs Netz. So beschreibt es der Abschnitt zu Kosten und Wartezeit in der Doku zu den Rechtemodi (externe Seite, code.claude.com).

Zugangsdaten in der Sandbox

Ein Befehl in der Sandbox darf ab Werk fast den ganzen Rechner lesen und erbt die Umge­bungs­va­ria­blen von Claude Code, Geheimnisse eingeschlossen. Die Einstellung sandbox.credentials nennt Dateien und Variablen, die er nicht sehen soll (Sandbox-Doku (externe Seite, code.claude.com)). Jeder Eintrag hat einen Modus, deny oder mask.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        {
          "path": "~/.aws/credentials",
          "mode": "deny"
        }
      ],
      "envVars": [
        {
          "name": "GITHUB_TOKEN",
          "mode": "deny"
        }
      ]
    }
  }
}

Mit deny ist die Datei in der Sandbox nicht lesbar, und die Variable fehlt in jedem Befehl. Eine eingebaute Liste gibt es nicht. Geschützt ist nur, was man einträgt.

Einträge aus allen Ebenen kommen zusammen. Jede Ebene kann Einträge ergänzen, entfernen lassen sie sich nur dort, wo sie stehen. Die Einstellung wirkt nur auf Befehle in der Sandbox. Für alle Prozesse, die Claude Code startet, gibt es CLAUDE_CODE_SUBPROCESS_ENV_SCRUB.

Mit mask sieht der Befehl einen Platzhalter, den die Doku Sentinel nennt. Erst der Proxy der Sandbox setzt den echten Wert ein, auf dem Weg zu einem erlaubten Host. Ein Werkzeug wie gh meldet sich so an, ohne dass der Schlüssel je in der Sandbox steht. Drei Bedingungen gehören dazu:

• network.tlsTerminate: Der Proxy muss den Inhalt der Anfrage sehen. Fehlt die Einstellung, erreicht der Platzhalter den Server unverändert, und die Anmeldung scheitert.
• Ein erlaubtes Ziel: Jeder Host in injectHosts muss auch in network.allowedDomains stehen.
• Eine vertrauenswürdige Datei: mask wirkt nur aus Nutzer- und verwalteten Einstellungen und aus --settings.

Dateien maskiert Claude Code seit Version 2.1.221 vom 04.08.2026, und das nur unter Linux und WSL2. Unter macOS sperrt es die Datei stattdessen ganz. Was die Sandbox sonst begrenzt und wo sie nachgibt, steht in Vibe-Coding / Agentic Engineering, Kapitel 09.

Startdateien der Shell

Ein Satz von Pfaden ist vor dem Schreiben geschützt. Claude Code gibt dort keine Änderung von selbst frei. Ausgenommen sind der Modus bypassPermissions und der Planmodus einer Sitzung im Terminal, in der dieser Modus freigeschaltet ist (Doku zu den Rechtemodi (externe Seite, code.claude.com)). Welche das sind und warum keine Erlaubnis sie öffnet, steht in Vibe-Coding / Agentic Engineering, Kapitel 08. Was der Plan-Modus sonst sperrt, zeigt Kapitel 23.

Dazu gehören die Startdateien der Shell wie .bashrc, .zshrc und .zshenv. Was dort steht, läuft beim nächsten Start einer Shell, auch außerhalb von Claude Code. Seit Version 2.1.160 vom 02.06.2026 fragt Claude Code auch vor dem Schreiben in .zshenv, .zlogin, .bash_login und ~/.config/git/ (Versionsliste (externe Seite, code.claude.com)). Die Versionsliste nennt den Grund: Solche Dateien könnten sonst Befehle ausführen, die niemand beabsichtigt hat.

Für den Ordner .claude des Projekts und für ~/.claude bietet die Rückfrage eine Antwort, die das Schreiben dort für den Rest der Sitzung erlaubt.

Restricted Mode

Seit Version 2.1.248 vom 27.08.2026 startet claude --restricted eine Sitzung mit wenigen Werkzeugen. Dasselbe bewirkt CLAUDE_CODE_RESTRICTED=1 in der Umgebung beim Start. Gedacht ist der Modus für eine Testumgebung, die Claude Code auf einem geteilten Rechner fährt (Kommandozeilen-Referenz (externe Seite, code.claude.com)). Der Modus ändert Folgendes:

• Die eingebauten Werkzeuge, die Befehle oder Code ausführen, und WebFetch fehlen, solange man sie nicht einzeln in --tools nennt.
• Die Dateiwerkzeuge bleiben in den Arbeits­ver­zeich­nissen.
• Claude Code liest nur verwaltete Einstellungen und --settings.
• bypassPermissions lehnt Claude Code ab.
• Cloud-Sitzungen lassen sich aus der Sitzung nicht anlegen.

Dazu kommt eine Grenze für den Auto-Modus. Ein Schreibzugriff auf einen geschützten Pfad geht dort sonst an den Klassifikator. In einer Sitzung mit --restricted kann er ihn nicht freigeben.

Rechte in Claude Code begannen als drei Stufen in einer Tabelle. Heute entscheiden Regeln mit Mustern, ein zweites Modell und das Betriebssystem. Diese Ebene zeichnet nach, wie es dazu kam, und zeigt, was der Klassifikator laut Hersteller übersieht. Danach geht es um die Stellen, an denen Hooks und Mods vor ihm entscheiden, und um die Frage, wie Codex dieselbe Aufgabe aufteilt.

Wie Rechte und Sandbox gewachsen sind

Versionen und Daten stammen aus der Versionsliste (externe Seite, code.claude.com). Die frühen Fassungen führt sie unter Sammeldaten: 0.2.21 bis 0.2.61 unter dem 02.04.2025, 0.2.63 bis 0.2.70 unter dem 17.04.2025. Eine Fassung 0.2.26 gibt es bei npm nicht.

Den Ausgangspunkt zeigt die Doku vom Februar 2025 (externe Seite, docs.anthropic.com) im Archivabbild. Sie nennt drei Stufen: Lesen ohne Rückfrage, Shell-Befehle mit einer Zustimmung, die je Projektordner und Befehl dauerhaft gilt, und Änderungen an Dateien bis zum Ende der Sitzung.

Dazu kam eine eingebaute Sperrliste für Befehle wie curl und wget. --dangerously-skip-permissions war nur für Docker-Container ohne Internet gedacht. Die Stufen gelten bis heute fast unverändert. Eine dauerhafte Zustimmung zu einem Befehl gilt inzwischen im ganzen Repository (Doku zu den Rechten (externe Seite, code.claude.com)).

Drei Linien laufen seither durch die Tabelle. Die Regeln wurden feiner, von ganzen Werkzeugen über Muster bis zu einzelnen Parametern. Die Sandbox kam im Oktober 2025 als Schalter, der bis heute ab Werk aus steht. Der Auto-Modus brauchte vom Research Preview bis zum Startmodus auf allen Plänen gut sechs Monate. In derselben Zeit wuchs seine Einstellung von einem Startschalter zu vier Listen und einem eigenen Reiter in /permissions.

Freigaben aus dem eigenen Verlauf

Mit Version 2.1.111 kam ein Skill, der Rückfragen sparen soll. Er durchsucht die Transkripte nach häufigen, nur lesenden Aufrufen von Bash und MCP-Werkzeugen und schlägt dafür Freigaben vor (Versionsliste (externe Seite, code.claude.com)). Die Versionsliste nennt ihn /less-permission-prompts. Der Wochenbericht derselben Woche und die heutige Befehlsübersicht (externe Seite, code.claude.com) nennen ihn /fewer-permission-prompts.

Die Freigaben landen in der Projektdatei .claude/settings.json. Liegt sie im Repository, gilt sie für jeden, der es klont. Wer die Freigaben nur für sich will, verschiebt sie danach in die lokale Datei. Enge Regeln dieser Art behält der Auto-Modus. Sie entscheiden dort vor dem Klassifikator.

Was der Klassifikator übersieht

Wie der Klassifikator gebaut ist, beschreibt der Engineering-Beitrag zum Auto-Modus (externe Seite, anthropic.com) vom 25.03.2026. Damals lief der Klassifikator auf Sonnet 4.6. Laut dem Beitrag bejahen Nutzer in der Praxis 93 Prozent der Rückfragen. Die Ankündigung vom 07.08.2026 (externe Seite, claude.com) nennt 97 Prozent, mehr dazu in Vibe-Coding / Agentic Engineering, Kapitel 08.

Er prüft in zwei Stufen. Die erste Stufe antwortet mit einem einzigen Token und ist darauf getrimmt, im Zweifel zu sperren. Nur was sie anhält, prüft die zweite Stufe noch einmal mit ausführlicher Begründung. Die eigenen Nachrichten von Claude und die Ergebnisse der Werkzeuge bekommt er nicht zu sehen. Claude soll ihn nicht mit Begründungen überreden können.

Gemessen hat Anthropic an drei Datensätzen. Der erste sind 10.000 Aufrufe von Claude Code durch Angestellte von Anthropic. Davon sperrte die volle Prüfung 0,4 Prozent der harmlosen Aktionen, die erste Stufe allein 8,5 Prozent.

Der zweite sind 52 Fälle, in denen ein Agent über den Auftrag hinaus Gefährliches tun wollte. Anthropic hat sie aus Sitzungen der Angestellten gesammelt, in denen jemand die Aktion abgelehnt oder sie nachträglich markiert hatte. Von diesen Fällen ließ die volle Prüfung 17 Prozent durch. Der Beitrag nennt diese Zahl selbst die maßgebliche. Der dritte sind 1.000 erzeugte Versuche, Daten auszuleiten, und dort waren es 5,7 Prozent.

Die meisten übersehenen Fälle hat der Klassifikator als gefährlich erkannt. Falsch lag er bei der Frage, ob eine Zustimmung im Gespräch genau diese Aktion abdeckt.

Ob 17 Prozent genug sind, hängt am Vergleich. Gegenüber --dangerously-skip-permissions sieht der Beitrag eine deutliche Verbesserung, gegenüber sorgfältig geprüften Rückfragen eher einen Rückschritt. Für Infrastruktur mit hohem Einsatz ersetzt der Auto-Modus laut Beitrag die sorgfältige Prüfung durch Menschen nicht. Alle drei Datensätze stammen vom Hersteller, und 52 Fälle sind eine kleine Stichprobe. Was andere Messungen ergeben haben, steht in Vibe-Coding / Agentic Engineering, Kapitel 08.

Wo Beitrag und Doku auseinandergehen

Der Beitrag vom März beschreibt einen früheren Stand, und an zwei Stellen hat die Doku ihn überholt. Für einen Lauf mit claude -p schreibt er, nach zu vielen Sperren beende der Auto-Modus den Prozess. Die Doku zu den Rechtemodi (externe Seite, code.claude.com) sagt heute das Gegenteil: Die Aktion unterbleibt, und Claude arbeitet weiter. Was das für einen Automaten bedeutet, steht in Vibe-Coding / Agentic Engineering, Kapitel 08.

Die zweite Stelle betrifft den Push. Der Beitrag nennt als Ausnahme nur den Push auf den Branch der Sitzung. Seit Version 2.1.211 erlaubt der Klassifikator in der Voreinstellung einen Push auf jeden Branch des Repositorys, außer auf Branches für Deploy oder Veröffentlichung. Wer vor jedem Push gefragt werden will, setzt eine Rückfrageregel, wie im Überblick beschrieben.

Hooks und Mods vor dem Klassifikator

Im Auto-Modus ist der Klassifikator die letzte Station. Davor stehen zwei Stellen, an denen eigener Code entscheidet. Ein Hook auf PreToolUse läuft vor den Regeln. Endet er mit dem Rückgabewert 2, hält er den Aufruf an, bevor eine Regel geprüft wird (Doku zu den Rechten (externe Seite, code.claude.com)). Im manuellen Modus lässt sich so ein weites Bash in der Erlaubnisliste mit einem Hook verbinden, der einzelne Befehle am vollen Wortlaut abweist.

Ein Mod, der das Ereignis tool.check behandelt, antwortet dagegen erst, wenn die Hooks auf PreToolUse gelaufen sind. Im Plan-Modus gibt er nur einen Aufruf frei, der bloß liest. Eine Dateiänderung oder einen anderen schreibenden Aufruf kann er dort nur abweisen. Im Auto-Modus läuft ein Aufruf, den ein Mod freigibt, ohne den Klassifikator. Ausgenommen ist eine Sitzung mit --permission-prompt-tool oder einem Rückruf canUseTool, an dem der Mod nicht vorbeikommt. Dort prüft der Klassifikator zuerst.

Zwei Einrichtungen halten gegen einen Mod: verwaltete Einstellungen auf dem Rechner und eine Anmeldung mit Team oder Enterprise über /login. Dann bleibt in der Voreinstellung stehen, was Verbote, Rückfrageregeln, Hooks und ein solcher Rückruf ergeben. Eine Sitzung mit API-Schlüssel oder CLAUDE_CODE_OAUTH_TOKEN zählt nicht als diese Anmeldung. Ohne beides kann ein Mod auch einen Aufruf freigeben, den ein Verbot ablehnt oder ein Hook abgewiesen hat. In dontAsk kann er in jeder Einrichtung einen Aufruf freigeben, den nur der Modus ablehnen würde. Wer einen Mod installiert, gibt ihm also ein Stück der Rechteprüfung in die Hand. In welcher Folge die Hooks der Mods und die aus den Einstellungen laufen, zeigt Kapitel 18 auf der dritten Ebene.

Im Agent SDK steht an der letzten Station statt des Menschen ein eigener Rückruf, canUseTool (Doku zu den Rechten im Agent SDK (externe Seite, code.claude.com)). Was eine Station davor freigibt, erreicht ihn nie. Eine Prüfung, die jeden Aufruf sehen muss, gehört deshalb in einen Hook auf PreToolUse. In dontAsk überspringt das SDK den Rückruf und lehnt ab. Einen Teil dieser Aufrufe kann ein installierter Mod trotzdem freigeben.

Was Codex anders löst

Codex von OpenAI trennt dieselbe Aufgabe in zwei Regler (Doku zu den Rechten in Codex (externe Seite, learn.chatgpt.com)). Die Sandbox legt fest, welche Dateien und Netzressourcen der Agent erreicht. Die Freigaben legen fest, wann er vor einer Aktion anhält. Wer die Freigaben an ein Modell abgibt, erweitert damit die Sandbox nicht. Dass Codex die Sandbox ab Werk einschaltet, steht in Kapitel 01.

Das Gegenstück zum Auto-Modus heißt bei Codex Auto-review, in der Desktop-App der Modus „Approve for me“. Ein eigener Prüfagent ersetzt die Rückfrage an der Grenze der Sandbox (Doku zu Auto-review (externe Seite, learn.chatgpt.com)). Was innerhalb der Sandbox ohnehin laufen darf, sieht er nicht. Bei Claude Code ist die Sandbox ab Werk aus, und der Klassifikator prüft jede Aktion, über die keine Station davor entschieden hat. Läuft die Sandbox im Modus auto-allow, gehen Befehle darin ohne ihn durch, außer wenn der Server prüft.

Drei weitere Unterschiede:

• Was der Prüfer sieht: Der Prüfagent von Codex liest einen verdichteten Verlauf samt Ergebnissen der Werkzeuge. In den Anfragen, die Claude Code selbst an seinen Klassifikator schickt, fehlen diese Ergebnisse mit Absicht, wie Vibe-Coding / Agentic Engineering, Kapitel 08 zeigt.
• Wann er aufgibt: In der quelloffenen Fassung bricht Codex die laufende Antwort nach drei Ablehnungen in Folge ab oder nach zehn unter den letzten 50 Prüfungen derselben Antwort. Claude Code fällt nach drei Sperren in Folge oder zwanzig insgesamt auf Rückfragen zurück und arbeitet weiter.
• Wo die Regeln stehen: Codex legt die Richtlinie des Prüfers im quelloffenen Repository ab. Claude Code gibt seine Regeln mit claude auto-mode defaults aus.

Der Aufbau von Codex hat einen klaren Vorteil. Weil die Sandbox ab Werk läuft, landet beim Prüfer nur, was die Grenze überschreiten will. Die vielen alltäglichen Befehle innerhalb kosten keine Prüfung, und was ein Prüfer nicht erweitern kann, ist an der Sandbox ablesbar. Claude Code prüft dafür auch dort, wo keine Sandbox läuft, etwa unter Windows ohne WSL2.

Was offen bleibt

Die Doku nennt Version 2.1.271 als Mindestfassung, ab der Sitzungen im Terminal auf Pro, Max und Team ihre Prüfung auf dem Server holen. Die Versionsliste führt diesen Schritt bei keiner Fassung. Sie nennt erst 2.1.278 für Konten über die API, Enterprise und Cloud-Anbieter.

Den Startmodus auf allen Plänen führt die Doku ab Version 2.1.283. Die Versionsliste nennt unter 2.1.283 nur Drittanbieter und Sitzungen ohne Telemetrie, alle Pläne erst unter 2.1.284.

Welches Modell auf dem Server prüft, nennt die Doku nicht. Sie nennt Sonnet 5 als Voreinstellung des Klassifikators. Eine Auswahl, die Anthropic auf dem Server trifft, hat laut Doku Vorrang davor.