SpyBara
Go Premium

permission-modes.md 2026-09-18 23:58 UTC to 2026-09-19 23:57 UTC

This page contains 78 additions and 74 deletions.

2026
Wed 9 22:58 Sat 12 03:02 Sun 13 21:00 Fri 18 23:58 Sat 19 23:57 Tue 22 23:59 Fri 25 23:58

Wählen Sie einen Berechtigungsmodus

Steuern Sie, ob Claude vor dem Bearbeiten von Dateien oder dem Ausführen von Befehlen fragt. Wechseln Sie Modi mit Shift+Tab in der CLI, dem Modusindikator in VS Code oder dem Moduswahlschalter in Desktop.

Ein Berechtigungsmodus legt fest, welche Aktionen Claude in einer Sitzung ausführen kann, ohne Sie vorher zu fragen. Im Manual-Modus hält Claude Code inne und fragt Sie, bevor die meisten Aktionen ausgeführt werden, die Dateien bearbeiten, Shell-Befehle ausführen oder das Netzwerk erreichen. Im Auto-Modus überprüft ein zweites Modell, der Klassifizierer, Aktionen statt Ihnen; wie der Klassifizierer Aktionen bewertet listet auf, welche Aktionen er überprüft und welche er überspringt.

Bei Pro-, Max- und Team-Plänen ist der integrierte Standard-Berechtigungsmodus Auto-Modus. Welcher Modus eine Sitzung startet behandelt die Oberflächen und Einstellungen, die den Standard-Berechtigungsmodus ändern. Sie können auch den Berechtigungsmodus einer laufenden Sitzung jederzeit ändern.

Verfügbare Modi

Jeder Modus stellt einen anderen Kompromiss zwischen Benutzerfreundlichkeit und Überwachung dar. Die folgende Tabelle zeigt, was Claude in jedem Modus ohne Berechtigungsaufforderung tun kann. Der Manual-Modus wird unter seinem Konfigurationswert default angezeigt.

Modus Was ohne Nachfrage ausgeführt wird Am besten geeignet für
default Nur Lesevorgänge Überprüfung jeder Aktion selbst, sensible Arbeiten
acceptEdits Lesevorgänge, Dateibearbeitungen und häufige Dateisystembefehle (mkdir, touch, mv, cp usw.) Iteration bei Code-Überprüfung
plan Lesevorgänge, plus vom Klassifizierer genehmigte Befehle, wenn Auto-Modus verfügbar ist Erkundung einer Codebasis vor Änderungen
auto Alles, mit Sicherheitsprüfungen im Hintergrund Lange Aufgaben, Reduzierung von Aufforderungsmüdigkeit
dontAsk Lesevorgänge und vorab genehmigte Tools; alles, das eine Aufforderung auslösen würde, wird abgelehnt Gesperrte CI und Skripte
bypassPermissions Alles Nur isolierte Container und VMs

Der Modus, der jede Aktion überprüft, wird in der CLI, in claude --help, in den VS Code- und JetBrains-Erweiterungen und in der Desktop-App als Manual bezeichnet. Sein Konfigurationswert ist default, was Hooks und SDK-Integrationen verwenden. Die CLI akzeptiert manual als Alias überall dort, wo Sie den Wert eingeben, zum Beispiel claude --permission-mode manual oder "defaultMode": "manual". Das Manual-Label und der manual-Alias erfordern Claude Code v2.1.200 oder später. Das Label der Desktop-App hängt nicht von Ihrer CLI-Version ab.

Schreibvorgänge in geschützte Pfade werden niemals automatisch genehmigt, außer im bypassPermissions-Modus und in Plan-Mode-Sitzungen, in denen Bypass-Berechtigungen verfügbar sind, was bedeutet, dass Sitzungen auf eine Weise gestartet wurden, die bypassPermissions in den Moduszyklus aufnimmt.

Modi legen die Grundlage fest. Überlagern Sie Berechtigungsregeln darauf, um bestimmte Tools vorab zu genehmigen oder zu blockieren. Deny-Regeln blockieren in jedem Modus, einschließlich bypassPermissions. Deny- und Ask-Regeln gelten nicht für EndConversation, solange Claude noch mindestens ein anderes Tool aufrufen kann. Allow-Regeln haben keine Auswirkung in bypassPermissions.

Aktionen, die kein Modus automatisch genehmigt

Claude Code genehmigt die folgenden in keinem Modus automatisch, einschließlich bypassPermissions. Jeder Punkt verlinkt auf den Abschnitt, der sagt, was stattdessen in jedem Modus passiert:

  • Tools, die einer expliziten Ask-Regel entsprechen

  • Connector-Tools, die Ihre Organisation auf ask gesetzt hat, in Sitzungen, in denen diese Einstellung Claude Code erreicht

  • Tools, die Benutzerinteraktion erfordern: das integrierte AskUserQuestion-Tool und MCP-Tools, die mit requiresUserInteraction gekennzeichnet sind

  • rm und rmdir Löschungen, die auf einen kritischen Pfad abzielen, den keine Allow-Regel oder PreToolUse Hook "allow" genehmigt

  • Die Cross-Session-Messaging-Schutzmaßnahmen

  • Lesevorgänge außerhalb der Arbeitsverzeichnisse, während permissions.blockReadsOutsideWorkingDirectories aktiviert ist: erkannte Datei-lesende Bash-Befehle und jeder unsandboxed Retry, der Genehmigung benötigt, um außerhalb der Sandbox zu laufen, fordern auch im Auto-Modus und bypassPermissions-Modus auf. Erfordert Claude Code v2.1.257 oder später.

    Ein Befehl, den der Shell-Parser nicht verfolgen kann, wie einer, der das Verzeichnis mehr als einmal wechselt oder eine Subshell ausführt, fordert auf die gleiche Weise auf, auch wenn er keinen außerhalb liegenden Pfad benennt. Diese Aufforderung gilt nicht, wenn der Befehl in der Sandbox ausgeführt wird und die Sandbox die Blockierung erzwingt.

Häufige Setups

Berechtigungsmodi entscheiden, ob Claude vor einer Aktion fragt, und die Bash-Sandbox und äußere Isolationsgrenzen entscheiden, was eine Aktion erreichen kann, sobald sie läuft. Jede Zeile unten paart ein Ziel mit den Flags oder Einstellungen, die Sie dorthin bringen, und der Isolation, die es benötigt, als Ausgangspunkt. Verfügbare Modi listet auf, was in jedem Modus ohne Aufforderung läuft.

Sie möchten Starten Sie mit Isolation erforderlich Notizen
Jede Aktion selbst überprüfen Manual-Modus: claude --permission-mode default Keine Sensible Arbeiten, unbekannter Code
Lokal mit weniger Aufforderungen iterieren, ohne einen Klassifizierer Manual-Modus plus die Bash-Sandbox im Auto-Allow-Modus: claude --permission-mode default, dann /sandbox ausführen und Auto-Allow auswählen Die integrierte Bash-Sandbox, auf macOS, Linux und WSL2 Deny-Regeln gelten weiterhin, und Ask-Regeln, die einen Befehl benennen, wie Bash(git push *), fordern weiterhin auf. Um die Sandbox stattdessen aus einer Einstellungsdatei zu aktivieren, setzen Sie sandbox.enabled auf true
Erkunden Sie, bevor Sie etwas ändern claude --permission-mode plan Keine Claude Code blockiert Bearbeitungen, bis Sie einen Plan genehmigen
Arbeiten Sie freihändig im Auto-Modus claude --permission-mode auto, der integrierte Standard-Berechtigungsmodus bei Pro, Max und Team Keine; eine Sandbox oder ein Container fügt Verteidigungstiefe hinzu Erfordert ein unterstütztes Modell, und Ihre Organisation kann Auto-Modus ausschalten
Führen Sie in CI mit einer genauen Allowlist aus claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" Keine über das hinaus, was Ihr CI-Runner bietet Cloud-Sitzungen ignorieren dontAsk aus Einstellungsdateien
Führen Sie vollständig unbeaufsichtigt in einem Container aus claude -p "<prompt>" --dangerously-skip-permissions Erforderlich: ein Container, VM oder die Sandbox-Laufzeit; auf Linux und macOS, führen Sie es als Nicht-Root-Benutzer aus Cloud-Sitzungen ignorieren diesen Modus aus Einstellungsdateien. In diesem -p Lauf werden die wenigen Aufrufe, die weiterhin auffordern würden stattdessen verweigert

Die Bash-Sandbox und der Auto-Modus funktionieren unabhängig und kombinieren sich, mit den Ausnahmen, die unter Sandbox-Modi aufgelistet sind. Für die vollständige Interaktion siehe Wie Sandboxing sich auf Berechtigungen und Berechtigungsmodi bezieht und Wie Isolation sich auf Berechtigungsmodi bezieht.

Welcher Modus eine Sitzung startet

Wenn Sie eine neue Sitzung in einem Terminal starten, nimmt Claude Code den Berechtigungsmodus aus dem ersten dieser Punkte, der zutrifft:

  1. Das --permission-mode Flag oder --dangerously-skip-permissions

  2. permissions.defaultMode in einer Einstellungsdatei

    Wenn Sie "auto" in .claude/settings.json oder .claude/settings.local.json setzen, wird der Wert nicht wirksam, und Claude Code verwendet dann stattdessen den integrierten Standard, anstatt einen defaultMode aus ~/.claude/settings.json zu verwenden. Wenn Sie "bypassPermissions" in diesen beiden Dateien setzen, wird es auch nicht wirksam, und die Sitzung startet im Manual-Modus. Die anderen Werte gelten aus jeder Einstellungsdatei.

  3. Der integrierte Standard

Konversationen, die die VS Code-Erweiterung startet, folgen der eigenen Liste der Erweiterung in Berechtigungsmodi wechseln. Für den Berechtigungsmodus, in dem Claude Code eine fortgesetzte Sitzung startet, siehe Berechtigungsmodus beim Fortsetzen.

Der integrierte auto Standard erfordert Claude Code v2.1.228 oder später auf macOS, Linux und WSL, und v2.1.233 oder später auf nativem Windows. Bei früheren Versionen ist der integrierte Standard Manual.

Der integrierte Standard hängt davon ab, wie Sie Claude Code ausführen, von Ihrem Plan und davon, ob Claude Code seine Feature-Flags abrufen konnte. Die erste Zeile, die Ihrer Sitzung entspricht, gilt. Die Tabelle behandelt Sitzungen, die Sie in einem Terminal oder über die VS Code-Erweiterung starten; für die Desktop-App und claude.ai siehe die Desktop- und Web-Registerkarten in Berechtigungsmodi wechseln.

Wie Sie Claude Code ausführen Integrierter Standard-Berechtigungsmodus
Eine Einstellungsdatei setzt disableAutoMode auf "disable" default
Feature-Flag-Abruf ist aus default
Ihre erste Sitzung nach der Installation von Claude Code oder dem Upgrade auf eine Version, die diesen Standard hinzufügt, es sei denn, nach einer Neuinstallation ruft Claude Code die Flags rechtzeitig ab default
claude -p oder das Agent SDK default
Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, Claude Platform on AWS oder eine angemeldete Claude Apps Gateway Sitzung default
Ein Pro-, Max- oder Team-Plan, in einem Terminal oder über die VS Code-Erweiterung auto
Ein Enterprise-Plan oder ein Claude Console API-Schlüssel default

Wenn Feature-Flag-Abruf aus ist oder in einer ersten Sitzung nach einer Installation oder einem Upgrade, in der die Flags noch nicht angekommen sind, ignoriert die VS Code-Erweiterung jede Einstellungsdatei bei der Wahl des Standard-Berechtigungsmodus.

Wenn das Flag, eine Einstellungsdatei oder der integrierte Standard auto auswählt, aber Auto-Modus nicht für die Sitzung verfügbar ist, startet Claude Code die Sitzung stattdessen im Manual-Modus. Auto-Modus ist nicht verfügbar, wenn die Sitzung die Verfügbarkeitsanforderungen nicht erfüllt, wie eine Einstellungsdatei, die ihn ausschaltet, oder ein Modell, das ihn nicht unterstützt, oder wenn Anthropic ihn vorübergehend serverseitig ausgeschaltet hat.

Das erste Mal, wenn der integrierte Standard eine Ihrer Sitzungen im Auto-Modus startet, zeigt Claude Code einen Hinweis, der auf diese Seite verlinkt:

  • In einem Terminal, einmal, oben in der Sitzung
  • In der VS Code-Erweiterung, als Karte auf dem Bildschirm für neue Konversationen, die bleibt, bis Sie sie schließen

Bei Pro-, Max- und Team-Plänen, wenn Ihre ~/.claude/settings.json einen defaultMode setzt, der nicht auto ist, und keine andere Einstellungsdatei setzt einen, starten Ihre Sitzungen weiterhin in diesem Modus. Claude Code fragt einmal, im Terminal oder in der VS Code-Erweiterung, ob die Einstellung auf Auto-Modus geändert werden soll. Wenn Sie ablehnen, bleibt Ihre Einstellung wie sie ist.

Starten Sie in einem anderen Berechtigungsmodus

Sie können den Standard-Berechtigungsmodus für eine Sitzung oder als Standard für jede Sitzung auf einem Computer, in einem Projekt oder in einer Organisation festlegen. Wenn mehr als eine Einstellungsdatei permissions.defaultMode setzt, entscheidet Einstellungspriorität, sodass ein Projekt- oder verwalteter Wert ~/.claude/settings.json übertrumpft. Um den Berechtigungsmodus einer bereits laufenden Sitzung zu ändern, siehe Berechtigungsmodi wechseln.

Um den Standard-Berechtigungsmodus festzulegen für Tun Sie dies
Eine Sitzung, die Sie gerade starten Übergeben Sie den Berechtigungsmodus als Flag, zum Beispiel claude --permission-mode default
Jede Terminal-Sitzung, die Sie auf diesem Computer starten Setzen Sie permissions.defaultMode in ~/.claude/settings.json. Für das, was die VS Code-Erweiterung liest, siehe Berechtigungsmodi wechseln
Jede Terminal-Sitzung, die Sie in einem Projekt starten Setzen Sie permissions.defaultMode in .claude/settings.json des Projekts. Sitzungen, die Sie in einem Terminal starten, respektieren jeden Wert außer auto und bypassPermissions; Sitzungen, die die VS Code-Erweiterung startet, lesen keine Projekteinstellungen für den Standard-Berechtigungsmodus
Jede Terminal-Sitzung in Ihrer Organisation Setzen Sie permissions.defaultMode in verwalteten Einstellungen. Terminal-Sitzungen starten in diesem Modus und Personen können weiterhin zum Auto-Modus wechseln; für das, was die VS Code-Erweiterung liest, siehe Berechtigungsmodi wechseln. Um Auto-Modus zu entfernen, damit niemand ihn auswählen kann, setzen Sie stattdessen permissions.disableAutoMode auf "disable"

Dieses Beispiel macht jede Terminal-Sitzung auf Ihrem Computer im Manual-Modus starten, dessen Konfigurationswert default ist. Speichern Sie es in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

Die nächste Sitzung, die Sie starten, zeigt ⏸ manual mode on in der Statusleiste.

Berechtigungsmodi wechseln

Jede Schnittstelle hat ihre eigene Kontrolle zum Wechseln von Berechtigungsmodi während einer Sitzung und ihre eigene Weise, den Berechtigungsmodus zu wählen, den neue Sitzungen starten. Wählen Sie Ihre Schnittstelle aus, um ihre Kontrollen zu sehen.

Während einer Sitzung: Drücken Sie Shift+Tab, um Berechtigungsmodi zu durchlaufen. Von auto wechselt der erste Druck zu default, und der Zyklus läuft dann default → acceptEdits → plan → zurück zu default. Optionale Modi, die unten beschrieben werden, werden nach plan eingefügt. Die Statusleiste zeigt den aktiven Modus als graues ⏸ manual mode on für default oder als ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on oder ⏵⏵ bypass permissions on.

Nicht jeder Modus ist im Standard-Zyklus enthalten:

  • auto: wird angezeigt, wenn Auto-Modus verfügbar ist; das Wechseln zu ihm schaltet Berechtigungsmodi ohne Bestätigungsaufforderung um
  • bypassPermissions: wird angezeigt, nachdem Sie mit --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions oder permissions.defaultMode: "bypassPermissions" in Benutzer-, --settings- oder verwalteten Einstellungen starten. Die --allow- Variante fügt den Berechtigungsmodus zum Zyklus hinzu, ohne ihn zu aktivieren
  • dontAsk: wird nie im Zyklus angezeigt; setzen Sie ihn mit --permission-mode dontAsk

Aktivierte optionale Modi werden nach plan eingefügt, mit bypassPermissions zuerst und auto zuletzt. Wenn Sie beide aktiviert haben, wechseln Sie durch bypassPermissions auf dem Weg zu auto.

Von einer Bash-Berechtigungsaufforderung: im Manual- und acceptEdits-Berechtigungsmodus, wenn Auto-Modus verfügbar ist, fügt Claude Code Ja, und zum Auto-Modus wechseln zu einer Bash-Befehlsberechtigungsaufforderung hinzu. Wählen Sie es aus, um den Befehl zu genehmigen und die Sitzung zum Auto-Modus zu wechseln. PowerShell-Tool Aufforderungen bieten die Option nicht an. Erfordert Claude Code v2.1.247 oder später.

Claude Code fügt die Option nicht zu Aufforderungen hinzu, die von einer Ihrer ask Regeln oder von einem Hook erzwungen werden, da Auto-Modus diese Aufforderungen immer noch zeigt, sodass das Wechseln sie nicht entfernen würde.

Beim Start: Übergeben Sie den Berechtigungsmodus als Flag.

claude --permission-mode plan

Als Standard: Setzen Sie permissions.defaultMode im Bereich, den Sie möchten, wie in Starten Sie in einem anderen Berechtigungsmodus beschrieben.

Das gleiche --permission-mode Flag funktioniert mit -p für nicht-interaktive Ausführungen.

Dateibearbeitungen mit acceptEdits-Modus automatisch genehmigen

Der acceptEdits-Modus ermöglicht es Claude, Dateien in Ihrem Arbeitsverzeichnis zu erstellen und zu bearbeiten, ohne Sie zu fragen. Die Statusleiste zeigt ⏵⏵ accept edits on an, während dieser Modus aktiv ist.

Zusätzlich zu Dateibearbeitungen genehmigt der acceptEdits-Modus automatisch häufige Bash-Befehle im Dateisystem: mkdir, touch, rm, rmdir, mv, cp und sed. Diese Befehle werden auch automatisch genehmigt, wenn sie mit sicheren Umgebungsvariablen wie LANG=C oder NO_COLOR=1 oder Prozess-Wrappern wie timeout, nice oder nohup vorangestellt sind. Wie bei Dateibearbeitungen gilt die automatische Genehmigung nur für Pfade in Ihrem Arbeitsverzeichnis oder additionalDirectories. Pfade außerhalb dieses Bereichs, Schreibvorgänge in geschützte Pfade, rm und rmdir Löschungen, die auf einen kritischen Pfad abzielen, und alle anderen Bash-Befehle außer dem integrierten schreibgeschützten Satz erfordern weiterhin eine Genehmigung.

Wenn das PowerShell-Tool aktiviert ist, genehmigt der acceptEdits-Modus auch automatisch Set-Content, Add-Content, Clear-Content und Remove-Item auf Pfaden im Gültigkeitsbereich, zusammen mit ihren häufigen Aliasen. Die gleichen Bereichs- und Schutzpfad-Regeln gelten, und Remove-Item erhält seine eigene Prüfung. Ein Positionsargument, das ein Anführungszeichen enthält, wie das Apostroph in Set-Content .\notes.txt "It's done", fordert weiterhin auf, auch auf Pfaden im Gültigkeitsbereich, da Claude Code ein Argument, dessen zitierte und unzitierte Lesarten unterschiedlich sind, nicht statisch validieren kann. Übergeben Sie den Inhalt durch einen benannten Parameter wie -Value, um die Aufforderung zu vermeiden.

Verwenden Sie acceptEdits, wenn Sie Änderungen in Ihrem Editor oder über git diff im Nachhinein überprüfen möchten, anstatt jede Bearbeitung inline zu genehmigen.

Drücken Sie Shift+Tab einmal vom Manual-Modus aus, um ihn zu aktivieren, oder starten Sie direkt damit:

claude --permission-mode acceptEdits

Analysieren Sie vor dem Bearbeiten mit dem Plan-Modus

Der Plan-Modus weist Claude an, Änderungen zu recherchieren und vorzuschlagen, ohne sie vorzunehmen. Claude liest Dateien, führt Shell-Befehle aus, um zu erkunden, und schreibt einen Plan, bearbeitet aber nicht Ihre Quelle. Außer in interaktiven Terminal-Sitzungen mit verfügbaren Bypass-Berechtigungen bleiben Bearbeitungen blockiert, bis Sie den Plan genehmigen.

Wenn Auto-Modus verfügbar ist und die useAutoModeDuringPlan Einstellung aktiviert ist, was die Standardeinstellung ist, überprüft der Klassifizierer Shell-Befehle während der Planung statt Sie zu fragen. Genehmigte Befehle laufen, und abgelehnte werden blockiert. Andernfalls fordern Befehle außerhalb des integrierten schreibgeschützten Satzes zur Genehmigung auf, auch wenn der Sandbox-Auto-Allow-Modus aktiviert ist. In interaktiven Terminal-Sitzungen mit verfügbaren Bypass-Berechtigungen gelten weder der Klassifizierer noch eine Aufforderung für Planungsbefehle; Alle Überprüfungen mit bypassPermissions-Modus überspringen behandelt die wenigen Dinge, die dort weiterhin auffordern. In v2.1.212 bis v2.1.217 forderten Sitzungen ohne verfügbare Bypass-Berechtigungen für jeden Befehl außerhalb des schreibgeschützten Satzes auf, unabhängig davon, ob Auto-Modus verfügbar war.

Geben Sie den Plan-Modus ein, indem Sie Shift+Tab drücken oder einem einzelnen Prompt /plan voranstellen. Sie können auch vom CLI aus im Plan-Modus starten:

claude --permission-mode plan

Drücken Sie Shift+Tab erneut, um den Plan-Modus zu verlassen, ohne einen Plan zu genehmigen.

Überprüfen und genehmigen Sie einen Plan

Wenn der Plan fertig ist, präsentiert Claude ihn und fragt, wie Sie vorgehen möchten. Von dieser Aufforderung aus können Sie wählen:

  • Ja, und Auto-Modus verwenden: Genehmigen und im Auto-Modus starten. Wenn Auto-Modus nicht verfügbar ist, liest diese Option Ja, Auto-Bearbeitungen akzeptieren. Wenn Sie die Sitzung mit aktivierten Bypass-Berechtigungen gestartet haben, liest die Option Ja, und zum BYPASS PERMISSIONS (keine weiteren Aufforderungen) für diese Sitzung wechseln statt.
  • Ja, Bearbeitungen manuell genehmigen: Genehmigen und jede Bearbeitung einzeln überprüfen.
  • Nein, weiter planen: Bleiben Sie im Plan-Modus und sagen Sie Claude, was zu ändern ist.

Das Genehmigen eines Plans beendet den Plan-Modus und wechselt die Sitzung zum Berechtigungsmodus, den jede Genehmigungsoption beschreibt, sodass Claude mit der Bearbeitung beginnt. Um erneut zu planen, wechseln Sie mit Shift+Tab zurück zum Plan-Modus, oder stellen Sie Ihrem nächsten Prompt /plan voran.

Drücken Sie Ctrl+G, um den vorgeschlagenen Plan in Ihrem Standard-Texteditor zu öffnen und ihn direkt zu bearbeiten, bevor Claude fortfährt. Wenn showClearContextOnPlanAccept aktiviert ist, erhält die Liste eine erste Option, die den Plan genehmigt und den Planungskontext löscht.

Das Akzeptieren eines Plans gibt der Sitzung auch einen generierten Titel basierend auf dem Plan, es sei denn, Sie haben die Sitzung bereits benannt.

Legen Sie den Plan-Modus als Standard fest

Um den Plan-Modus als Standard für die Terminal-Sitzungen eines Projekts festzulegen, setzen Sie defaultMode auf plan in .claude/settings.json, wie das Beispiel unter Starten Sie in einem anderen Berechtigungsmodus zeigt. Konversationen, die die VS Code-Erweiterung startet, lesen keine Projekteinstellungen für den Standard-Berechtigungsmodus. Dort setzen Sie stattdessen claudeCode.initialPermissionMode auf plan in Ihren VS Code-Benutzereinstellungen.

Eliminieren Sie Genehmigungseingabeaufforderungen mit dem Auto-Modus

Der Auto-Modus ermöglicht es Claude, ohne routinemäßige Genehmigungseingabeaufforderungen auszuführen. Ein separates Klassifizierungsmodell überprüft Aktionen vor ihrer Ausführung und blockiert alles, das über Ihre Anfrage hinausgeht, auf nicht erkannte Infrastruktur abzielt oder von feindseligem Inhalt angetrieben zu sein scheint, den Claude gelesen hat. Explizite Anfrageregelungen erzwingen weiterhin eine Eingabeaufforderung.

In Pro-, Max- und Team-Plänen ist der Auto-Modus der integrierte Standard-Genehmigungsmodus.

Der Klassifizierer überprüft auch jede Nachricht, die Claude mit SendMessage an einen anderen Agent sendet, ob als Klartext oder als strukturierte Agent-Team-Nachricht, bevor Claude Code sie liefert, sowohl im Auto-Modus als auch im Plan-Modus, während der Klassifizierer Befehle überprüft; die Sendungsüberprüfung erfordert Claude Code v2.1.222 oder später.

Der Klassifizierer überprüft auch und genehmigt oder blockiert rm- und rmdir-Löschungen, die auf einen kritischen Pfad abzielen, wie rm -rf / und rm -rf ~, auch wenn die Löschung in einer Befehl- oder Prozessersetzung stattfindet.

Der Auto-Modus ermutigt Claude auch, weiter zu arbeiten, ohne bei Klarstellungsfragen zu stoppen, obwohl Claude immer noch fragt, wenn Ihre Eingabeaufforderung oder eine Fähigkeit explizit darauf angewiesen ist. Für stärkeres autonomes Verhalten in einem Modus, der Sie immer noch auffordert, stellen Sie stattdessen den Proaktiven Ausgabestil ein.

Der Auto-Modus ist nur verfügbar, wenn Ihr Konto alle diese Anforderungen erfüllt:

  • Plan: Alle Pläne.
  • Organisation: Bei Team und Enterprise ist der Auto-Modus standardmäßig verfügbar. Administratoren können ihn für die Organisation deaktivieren, indem sie permissions.disableAutoMode in verwalteten Einstellungen auf "disable" setzen.
  • Modell: Auf der Anthropic API und Claude Platform on AWS, Claude Opus 4.6 oder später, Sonnet 4.6 oder später, oder ein Fable-Modell. Auf Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen nur Claude Sonnet 5, Opus 4.7 oder später und die Fable-Modelle. Ältere Modelle, einschließlich Sonnet 4.5, Opus 4.5, Haiku und claude-3-Modelle, werden auf keinem Anbieter unterstützt.
  • Anbieter: Standardmäßig auf der Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen verfügbar.

Wenn Claude Code meldet, dass der Auto-Modus nicht verfügbar ist, überprüfen Sie zunächst diese Anforderungen und ob eine Einstellungsdatei disableAutoMode setzt. Anthropic kann den Auto-Modus auch serverseitig deaktiviert haben, oder der Server kann den Auto-Modus für Ihr Konto abgelehnt haben. Eine Sitzung, die eine dieser Antworten erhalten hat, behält den Auto-Modus aus, bis die Sitzung endet. Starten Sie später eine neue Sitzung.

Eine separate Nachricht, die ein Modell benennt und sagt, dass der Auto-Modus die Sicherheit einer Aktion „nicht bestimmen kann", bedeutet, dass eine Klassifiziereranfrage fehlgeschlagen ist. Dieser Fehler ist normalerweise vorübergehend, kann aber auf Amazon Bedrock wiederholt auftreten, bis Ihr Konto das benannte Modell aufrufen kann. Siehe die Fehlerreferenz für die Ursachen und was zu tun ist.

Wenn Sie defaultMode: "auto" in Einstellungen setzen und eine Terminal-Sitzung im manuellen Modus ohne Fehler startet, befindet sich die Einstellung wahrscheinlich in .claude/settings.json oder .claude/settings.local.json. auto wird aus diesen Dateien nicht wirksam. Verschieben Sie es zu ~/.claude/settings.json. Für ein Gespräch, das die VS Code-Erweiterung gestartet hat, überprüfen Sie stattdessen die eigene Liste der Erweiterung in Genehmigungsmodi wechseln.

Auto-Modus auf Bedrock, Agent Platform oder Foundry

Auf Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen wird der Auto-Modus standardmäßig im Shift+Tab-Zyklus angezeigt. Das Erscheinen im Zyklus ändert nicht den Genehmigungsmodus, in dem eine Sitzung startet: Auf diesen Anbietern starten Terminal-Sitzungen in Ihrem defaultMode, der manuell ist, es sei denn, Sie ändern ihn, und Gespräche in der VS Code-Erweiterung starten im manuellen Modus, es sei denn, claudeCode.initialPermissionMode oder ein Modus, den Sie in der Erweiterung ausgewählt haben, setzt einen. Nur Claude Sonnet 5, Opus 4.7 oder später und die Fable-Modelle werden auf diesen Anbietern unterstützt.

Um den Auto-Modus zum Standard-Genehmigungsmodus beim Start zu machen, setzen Sie "permissions": {"defaultMode": "auto"} in Benutzer- oder verwalteten Einstellungen. Wählen Sie in Sitzungen, die die VS Code-Erweiterung startet, stattdessen Auto aus dem Modusindikator. Genehmigungsmodi wechseln behandelt, was diese Auswahl übertrumpft.

Die /doctor-Überprüfung schlägt diese Benutzereinstellungs-Standard auf diesen Anbietern auf die gleiche Weise vor wie auf der Anthropic API.

Um Entwickler daran zu hindern, den Auto-Modus zu verwenden, setzen Sie disableAutoMode in verwalteten Einstellungen auf "disable". Dies entfernt auto aus dem Shift+Tab-Zyklus, und eine Sitzung, die mit --permission-mode auto gestartet wurde, startet stattdessen im manuellen Modus. Eine bereits im Auto-Modus laufende Sitzung verlässt ihn, wenn die Einstellung diese Sitzung von einer von Admin bereitgestellten Quelle erreicht, und zeigt auto mode disabled by settings. Vor v2.1.251 behielt eine laufende Sitzung den Auto-Modus bis zum Ende.

In v2.1.158 bis v2.1.206 war der Auto-Modus auf diesen Anbietern aus, bis Sie CLAUDE_CODE_ENABLE_AUTO_MODE=1 setzten, und Claude Code ignorierte defaultMode: "auto" auf diesen Anbietern, es sei denn, die Variable wurde auch gesetzt. Die Variable wird immer noch aus Kompatibilitätsgründen akzeptiert und hat ab v2.1.207 keine Auswirkung.

Serverseitige Klassifiziererüberprüfung

Bei Enterprise-Plänen und Konten, die die Claude API verwenden, auf Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform und Microsoft Foundry, und wenn Sie ANTHROPIC_BASE_URL auf ein LLM-Gateway oder einen Proxy verweisen, fragt Claude Code im Auto-Modus den Server auf, um die Aktionen zu überprüfen, die zum Klassifizierer gehen als Teil der Modellabfragen der Sitzung. Wo der Server sie überprüft, entscheiden seine Urteile diese Aktionen. Wo er nicht überprüft, meist weil ein LLM-Gateway oder Proxy den Datenverkehr stört, oder weil die Plattform, Region oder Anmeldedaten noch keine serverseitigen Überprüfungen haben, fällt Claude Code auf seine eigenen Klassifiziereranfragen zurück, und sobald dieses Fallback für den Rest der Sitzung gilt, zeigt es einen Hinweis auf Klassifiziereranfrage-Gebühren auf Konten, bei denen diese Anfragen abgerechnet werden. Um das Fragen des Servers zu überspringen und immer Claude Codes eigene Klassifiziereranfragen zu verwenden, setzen Sie CLAUDE_CODE_AUTO_MODE_SERVER=0. Die Variable wird nicht auf einer direkten Verbindung zur Anthropic API gelesen. Wenn Sie CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 setzen und CLAUDE_CODE_AUTO_MODE_SERVER nicht gesetzt lassen, stoppt Claude Code auch das Fragen des Servers.

Das Fragen des Servers standardmäßig erfordert Claude Code v2.1.278 oder später.

Was der Klassifizierer standardmäßig blockiert

Der Klassifizierer vertraut Ihrem Arbeitsverzeichnis und den Remotes, die dafür konfiguriert wurden, als die Sitzung startete. Ein Remote, das während der Sitzung mit git remote add oder git remote set-url hinzugefügt oder umgeleitet wird, wird nicht vertraut, und alles andere wird als extern behandelt, bis Sie vertrauenswürdige Infrastruktur konfigurieren. Vor v2.1.200 wurden auch während der Sitzung hinzugefügte Remotes vertraut.

Standardmäßig blockiert:

  • Herunterladen und Ausführen von Code, wie curl | bash
  • Senden sensibler Daten an externe Endpunkte
  • Produktionsbereitstellungen und Migrationen
  • Massenlöschung auf Cloud-Speicher
  • Gewährung von IAM- oder Repo-Berechtigungen
  • Änderung gemeinsamer Infrastruktur
  • Irreversibles Zerstören von Dateien, die vor der Sitzung existierten
  • Force Push
  • Committen oder Pushen einer Änderung, die Geheimnisse oder sensible Daten außerhalb des Repositorys sendet, wenn es ausgeführt wird, oder erweitert, was eine Bereitstellung offenlegt. Dies umfasst einen CI-Workflow oder eine Bereitstellungskonfiguration, die ein Geheimnis an ein Ziel übergibt, das es nicht bereits erhält, ein Skript oder einen Einrichtungsschritt, der einen Geheimnisspeicher liest und die Daten sendet, und eine Konfigurationsänderung, die erweitert, was eine Bereitstellung veröffentlicht, wie eine Registry-, Sichtbarkeits-, Artefakt- oder Sourcemap-Einstellung. Die Überprüfung gilt auf jedem Branch, gilt auch wenn das Repository öffentlich ist, und wird ausgelöst, wenn die Änderung committed oder gepusht wird, unabhängig davon, ob dieser Commit oder Push die Pipeline auslöst; das Löschen erfordert die Benennung des Ausführungseffekts, nicht nur des Commits oder Pushes. Vor v2.1.211 war diese Überprüfung auf den Standard-Branch beschränkt: Ein Push dort wurde blockiert, wenn er sensible Inhalte trug, Änderungen verborgen oder falsch beschrieben waren im Vergleich zu dem, was Sie fragten, Inhalte von außerhalb des Repositorys portiert wurden oder um eine Überprüfung herumgeleitet wurden, die Sie fragten
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop oder git stash clear, die der Klassifizierer vermuten würde, würden nicht committete Änderungen verwerfen
  • git commit --amend, wenn der Commit am HEAD nicht in dieser Sitzung erstellt wurde
  • Ab v2.1.198, git commit --amend, wenn der Commit am HEAD bereits gepusht wurde. Eine Nachricht-nur-Umformulierung wird nicht blockiert: --amend -m ohne neu Gestaffeltes, auf einem Commit, den Claude während dieser Sitzung erstellt hat
  • terraform destroy, pulumi destroy, cdk destroy oder terragrunt destroy, und Anwendung eines Plans, der Ressourcen zerstört

Claude Code v2.1.195 und später blockieren standardmäßig mehr Kategorien. Mehrere hängen von Umgebungs-Einträgen ab, wie sensible Remote-Ziele und geschützte IaC-Bereiche, die Sie auf konkrete Namen eingrenzen können.

  • Schreiben in einen Geheimnisspeicher oder Ändern von DNS-Einträgen oder TLS-Zertifikaten
  • Zusammenführen eines Pull Requests, den kein Mensch genehmigt hat, Genehmigung von Claudes eigenem Pull Request oder Deaktivierung von CI-Überprüfungen
  • Posten eines Kommentars, der selbst ein Befehl zur Automatisierung ist, wie atlantis apply oder ein Bot's /deploy oder /merge
  • Umschalten, Ramping oder Löschen eines Produktions-Feature-Flags
  • Anwendung von Infrastrukturänderungen auf einen geschützten IaC-Bereich oder Entwässerung und Entfernung von Cluster-Knoten
  • Schreibvorgänge auf einen gemeinsamen Compute-Cluster, die über die benannte Ressource hinausgehen, wie ein Label-Selektor oder --all, der andere Benutzer's Jobs erfasst
  • Erstellen von Kubernetes-Ressourcen, die auf jedem Knoten ausgeführt werden oder Cluster-Datenverkehr abfangen, wie DaemonSets und Admission Webhooks
  • Interaktive Shells oder Port-Forwards in ein sensibles Remote-Ziel
  • Öffnen eines Tunnels oder einer Reverse Shell, die einen lokalen Service vom öffentlichen Internet erreichbar macht
  • Drucken eines Live-Credentials oder Tokens in das Transkript oder eine Datei
  • Zugriff auf einen Ort, der in Ihrer Umgebung als sensible Datenlocation aufgelistet ist, oder Kopieren von Daten daraus. Ab v2.1.198 blockiert dies auch das Senden von Daten von einem zu einer Zielgruppe, die der Eintrag ausschließt
  • Umleitung einer Paketinstallation um Ihre interne Paket-Registry zu einer öffentlichen Registry. Ab v2.1.198 gilt dies auch, wenn Sie Claude in der Konversation mitgeteilt haben, dass eine interne Registry oder ein Mirror existiert, nicht nur wenn eine in Ihrer Umgebung aufgelistet ist
  • Ausführung eines Befehls mit einem Flag, das einen Sicherheitsschutz deaktiviert, wie --insecure
  • Starten einer autonomen Agent-Schleife, die ohne menschliche Genehmigung oder einen Sandbox läuft, wie eine mit --dangerously-skip-permissions oder --no-sandbox gestartete. Ab v2.1.198 umfasst dies auch das Ausführen eines Drittanbieter-Agents oder Eval-Harness mit deaktivierter Isolation und Pro-Aktion-Genehmigung, wie ein Runner, der mit --yes-always gestartet wurde
  • Claude in Chrome-Browser-Aktionen, die Seiteninhalte, Cookies oder Anmeldedaten off-origin senden könnten

Claude Code v2.1.198 und später blockieren diese standardmäßig auch:

  • Löschen von Dateien in /tmp, $TMPDIR oder einem anderen gemeinsamen Scratch- oder Cache-Verzeichnis nach Wildcard, Glob oder Altersfilter statt nach einem spezifischen benannten Pfad
  • Einbeziehen sensibler Details in Inhalte, die gesendet, hochgeladen, veröffentlicht oder an andere Personen oder gemeinsame Systeme geschrieben werden, wenn Ihre eigene Nachricht diese Details nicht für diesen Empfänger autorisiert hat. PR- und Issue-Bodies, Commit-Nachrichten und Kommentare zählen als diese Art von ausgehendem Inhalt, wenn das Repository außerhalb der Vertrauensgrenze oder öffentlich ist, einschließlich der eigenen öffentlichen Repositorys Ihrer Organisation; interne Dateipfade, Code-Namen, Live-API-Antwortdaten wie E-Mails oder Kontobezeichner und Infrastruktur-Bezeichner zählen als sensible Details. Die PR-, Issue- und Commit-Nachrichten-Scoping erfordert Claude Code v2.1.200 oder später. Live-Personendaten aus einer API-Antwort in einem PR- oder Issue-Body, wie eine E-Mail-Adresse, ein Konto- oder Organisationsbezeichner oder eine Nutzungsmetrik, erfordert, dass Sie diese Details und den Empfänger benennen, unabhängig von der Sichtbarkeit oder Vertrauensgrenze des Repositorys. Diese Überprüfung erfordert Claude Code v2.1.203 oder später
  • Senden von Tastenanschlägen an Claude Codes eigenen tmux-Pane, um seine eigene Schnittstelle zu steuern, die der Klassifizierer als Claude behandelt, das seine eigenen Berechtigungen oder Überwachung ändert

Claude Code v2.1.200 und später blockieren diese standardmäßig auch:

  • Auskommentieren, Löschen oder Force-Passing eines Tests oder einer Assertion, die Sicherheitsverhalten schützt, wie Authentifizierung, Zugriffskontrolle, Eingabevalidierung oder Sandboxing
  • Löschen oder Abbau einer zustandsbehafteten Ressource, die Claude nicht in der Sitzung erstellt hat, wenn keine spezifischere Löschregel gilt und Sie diese Ressource nicht benannt haben
  • Umleitung einer API-Basis-URL, eines Proxy-Endpunkts, eines Webhook-Empfängers oder eines Registry-Mirrors auf einen Drittanbieter-Host, der nicht zur Aufgabe passt, auch in Beispieldateien wie .env.example
  • Änderung, wohin Pushes mit git remote set-url oder git remote add gehen, es sei denn, Sie haben den neuen Remote benannt
  • Pushen von Geheimnissen oder persönlichen oder anvertrauten Daten in ein Repository, das bekannt ist, öffentlich zu sein, oder Pushen von vertraulichem Material dorthin, das nicht Teil der eigenen Arbeit dieses Repositorys ist. Ein Dotfiles-Repository's eigene Materie ist die eine Ausnahme für persönliche oder anvertraute Daten, und Inhalte aus einem privaten Repository, die eine öffentliche Oberfläche erreichen, werden auf die gleiche Weise blockiert; beide Verfeinerungen erfordern Claude Code v2.1.203 oder später. Vor v2.1.203 wurden persönliche Daten mit vertraulichem Material gruppiert und nur blockiert, wenn sie nicht Teil der eigenen Arbeit dieses Repositorys waren. Wenn die Sichtbarkeit eines Repositorys nicht etabliert ist, blockiert der Klassifizierer nicht allein darauf; er beurteilt den Inhalt stattdessen gegen die anderen Regeln
  • Öffnen eines Pull Requests gegen ein anderes Repository oder eine andere Organisation, Forking mit gh repo fork oder Pushen in ein Drittanbieter-Repository, es sei denn, Sie haben dieses externe Ziel benannt

Claude Code v2.1.203 und später blockieren diese standardmäßig auch:

  • Inhalte aus einem sensiblen lokalen Speicher oder aus einer Datei, deren Name, Pfad oder Typ sie als sensibel kennzeichnet, die in einen Commit, einen Push, PR- oder Issue-Text, einen Gist oder Paste oder eine Paketveröffentlichung eingehen, es sei denn, Sie haben sowohl die Quelle als auch das Ziel benannt. Sitzungstranskripte und Gesprächsprotokolle, Anmeldedaten und Konfigurationspunkt-Ordner wie SSH-Schlüssel, Cloud-Anmeldedaten, Browser-Profile und Shell-Verlauf sowie Benutzer-Daten-Exporte zählen alle, und das Repository ist privat, löscht es nicht

Claude Code v2.1.205 und später blockieren diese standardmäßig auch:

  • Schreiben in Claude Code-Sitzungstranskripte, die .jsonl-Verlaufsdateien unter ~/.claude/projects/ oder Ihrem konfigurierten Konfigurationsverzeichnis, ob direkt oder durch einen Shell-Befehl. Die Regel umfasst auch die Metadatenzeilen, die Claude Code an jeden Transkripteintrag für seine eigenen Überprüfungen anhängt. Das Lesen eines Transkripts wird nicht blockiert
  • Eine rekursive erzwungene Löschung wie rm -rf "$VAR" oder Remove-Item -Recurse -Force $dir, deren Ziel eine Shell-Variable ist, oder ein Glob, der an einer verwurzelt ist, die nirgendwo in der Konversation zugewiesen ist, die der Klassifizierer sieht. Der Wert kam nur aus früherer Befehlsausgabe, die der Klassifizierer nie erhält, daher kann der Klassifizierer das Löschziel nicht gegen die anderen Löschregeln überprüfen. Der Block wird gelöscht, wenn Sie den genauen gelöschten Pfad benennen, oder wenn Claude die Löschung mit dem aufgelösten literalen Pfad, der in den Befehl geschrieben ist, erneut ausführt. Löschungen, deren Ziel der Klassifizierer auflösen kann, sind nicht betroffen. Remove-Item-Ziele, die ein bloßes * sind oder auf /* oder \* enden, erreichen den Klassifizierer nie: Claude Code lehnt sie direkt ab

Claude Code v2.1.257 und später blockieren diese standardmäßig auch:

  • Anfordern von Anmeldedaten vom Cloud-Instance-Metadaten-Endpunkt, wie 169.254.169.254, oder explizites Authentifizieren eines Cloud-, Cluster- oder Registry-Aufrufs mit der eigenen Service-Account oder Node-Identität der Maschine
  • Erreichen eines öffentlichen Hosts durch eine Route, die nicht direkt ist, wie ein Tunnel, eine Reverse Shell oder eine Resolver- oder Proxy-Konfiguration, die umgeschrieben wurde, um außerhalb zu verweisen
  • Lesen von Anmeldedaten, die dem Host gehören, nicht zu Ihrer Aufgabe, wie Node-Zertifikate oder die Node's Container-Registry-Auth
  • Verbindung zu oder Scannen von Sibling-Containern, Pods oder VMs, die Claude nicht gestartet hat, oder dem Node unter dem Container

Wenn Claude Code irgendwo läuft, das eines davon erlauben soll, beschreiben Sie dieses Setup in einem Host-Containment-Eintrag in autoMode.environment.

Claude Code v2.1.261 und später blockieren diese standardmäßig auch:

  • Posten oder Schreiben eines Links zu einem öffentlichen Paste-, Diagramm- oder Datenaustausch-Service in einer Nachricht, PR- oder Issue-Text, einem Dokument oder überall dort, wo der Link geöffnet oder abgerufen wird, wenn die URL selbst den geteilten Inhalt trägt, es sei denn, Sie haben diesen Service benannt

Standardmäßig erlaubt:

  • Lokale Dateivorgänge in Ihrem Arbeitsverzeichnis
  • Installation von Abhängigkeiten, die in Ihren Lock-Dateien oder Manifesten deklariert sind
  • Lesen von .env und Senden von Anmeldedaten an ihre passende API
  • Schreibgeschützte HTTP-Anfragen
  • Pushen zu jedem Branch des Repositorys, an dem Sie arbeiten, einschließlich des Standard-Branchs. Ein Nicht-Standard-Branch, dessen Name ihn als Deploy- oder Veröffentlichungsziel kennzeichnet, wie production oder gh-pages, ist nicht abgedeckt: Der Klassifizierer beurteilt einen Push dort auf seine eigenen Bedingungen. Der Inhalt des Pushes wird immer noch gegen die anderen Regeln überprüft, permissions.deny-Regeln können Push-Befehle immer noch wie geschrieben in jedem Modus blockieren, und der eigene Branch-Schutz des Remotes gilt immer noch. Vor v2.1.211 waren nur Pushes zum Branch, auf dem Sie starteten, Branches, die Claude erstellt hatte, und routinemäßige Pushes zum Standard-Branch standardmäßig erlaubt, und vor v2.1.203 war jeder direkte Push zum Standard-Branch blockiert

Claude Code v2.1.195 und später erlauben diese standardmäßig auch:

  • Löschen der genauen Jobs, die Claude früher in der gleichen Sitzung erstellt hat
  • Lesen, Überprüfen oder Schreiben von sicherheitsbezogenem Code, Konfigurationen und Bedrohungsmodellen als Teil Ihrer Aufgabe
  • Nachrichten zwischen Agents, die zusammen in der gleichen Multi-Agent-Sitzung arbeiten
  • Senden von Daten an die vertrauenswürdigen Domains, Buckets und Services, die Sie in environment auflisten. Dies umfasst nur Datenfluss, nicht destruktive oder Anmeldedaten-Operationen auf der gleichen Infrastruktur
  • Claude in Chrome-Navigation zu einer vertrauenswürdigen internen Domain, localhost oder einer URL, die Sie benannt haben

Sandbox-Befehle erhalten standardmäßig keinen Netzwerkzugriff. Claude benennt die Hosts, die ein Befehl auf dem Befehl selbst benötigt, der Klassifizierer überprüft sie mit dem Befehl, und eine genehmigte Liste öffnet diese Hosts nur für diesen einen Befehl. Pro-Befehl erlaubte Domains behandelt, was eine Liste öffnen kann und nicht und was passiert, wenn ein Befehl nach einem nicht aufgelisteten Host greift.

Führen Sie claude auto-mode defaults aus, um die vollständigen Regellisten als JSON zu drucken. Wenn routinemäßige Aktionen blockiert werden, kann ein Administrator vertrauenswürdige Repos, Buckets und Services über die autoMode.environment-Einstellung hinzufügen: siehe Auto-Modus konfigurieren.

Das Pushen zu jedem Branch des Repositorys, an dem Sie arbeiten, und das Erstellen eines Pull Requests, der Ihrer Anfrage entspricht, laufen ohne Eingabeaufforderung ab, es sei denn, der Push oder Pull Request fällt unter die blockierte Liste, wie Geheimnisse oder sensible Daten, die das Repository verlassen, oder ein Pull Request, der auf ein anderes Repository oder eine andere Organisation abzielt. Um einen menschlichen Checkpoint vor diesen Befehlen zu erfordern, während Sie im Auto-Modus bleiben, fügen Sie permissions.ask-Regeln hinzu, die den Befehl wie geschrieben abgleichen: siehe Häufige Grenzen.

Der erste Lesezugriff außerhalb der Arbeitsverzeichnisse

Während permissions.blockReadsOutsideWorkingDirectories aus ist, laufen Dateileseoperationen ohne Eingabeaufforderung im Auto-Modus ab, einschließlich Lesezugriffe außerhalb der Arbeitsverzeichnisse. Das erste Mal, wenn Claude das Read-, Grep- oder Glob-Tool auf einen Pfad außerhalb davon verwendet, fragt Claude Code Sie, ob Sie diese Lesezugriffe weiterhin erlauben möchten.

Die Eingabeaufforderung wird nicht in nicht-interaktiven -p-Läufen oder Hintergrund-Sitzungen angezeigt; Lesezugriffe dort laufen wie zuvor.

Was auch immer Sie antworten, Claude arbeitet weiter:

  • Weiterhin erlauben: Der Lesezugriff läuft, spätere Lesezugriffe außerhalb der Arbeitsverzeichnisse laufen wie zuvor, und Claude Code zeichnet Ihre Antwort auf, damit die Eingabeaufforderung nicht erneut angezeigt wird
  • Von jetzt an blockieren: Der Lesezugriff wird verweigert, und Claude Code setzt permissions.blockReadsOutsideWorkingDirectories in Ihren Benutzereinstellungen auf true, was die Dateiwerkzeuge dazu bringt, solche Lesezugriffe in jeder späteren Sitzung und jedem Genehmigungsmodus zu verweigern. Um Claude später einen solchen Pfad lesen zu lassen, fügen Sie sein Verzeichnis mit /add-dir hinzu oder entfernen Sie die Einstellung.
  • Nächstes Mal erneut fragen: Der Lesezugriff wird verweigert, und der nächste Lesezugriff außerhalb der Arbeitsverzeichnisse fordert erneut auf

Grenzen, die Sie in der Konversation angeben

Der Klassifizierer behandelt Grenzen, die Sie in der Konversation angeben, als Blocksignal. Wenn Sie Claude sagen „nicht pushen" oder „warten Sie, bis ich überprüfe, bevor Sie bereitstellen", blockiert der Klassifizierer passende Aktionen, auch wenn die Standard-Regeln sie erlauben würden. Eine Grenze bleibt in Kraft, bis Sie sie in einer späteren Nachricht aufheben. Claudes eigenes Urteil, dass eine Bedingung erfüllt wurde, hebt sie nicht auf.

Grenzen werden nicht als Regeln gespeichert. Der Klassifizierer liest sie bei jeder Überprüfung aus dem Transkript erneut, daher kann eine Grenze verloren gehen, wenn Kontext-Komprimierung die Nachricht entfernt, die sie angegeben hat. Für eine harte Garantie fügen Sie stattdessen eine Deny-Regel hinzu.

Wenn Auto-Modus zurückfällt

Wenn der Auto-Modus Ihre Sitzungsaktionen nicht genehmigen kann, hängt das, was passiert, vom Fall ab:

  • Eine blockierte Aktion: Claude Code zeigt eine Benachrichtigung an und listet die Aktion in /permissions unter der Registerkarte Kürzlich verweigert auf, wo Sie r drücken können, um sie mit manueller Genehmigung erneut zu versuchen. Wenn der Klassifizierer kein Urteil über die Aktion erzeugt, weil eine Sicherheitsüberprüfung, die vom Auto-Modus getrennt ist, die Anfrage des Klassifizierers verweigerte oder seine Antwort nicht geparst wurde, verweigert Claude Code die Aktion ohne die Benachrichtigung oder den Eintrag Kürzlich verweigert.
  • Wiederholte Blöcke: Wenn der Klassifizierer eine Aktion 3 Mal hintereinander oder 20 Mal insgesamt blockiert, pausiert der Auto-Modus und Claude Code setzt das Auffordern fort. Das Genehmigen der aufgeforderten Aktion setzt den Auto-Modus fort. Diese Schwellwerte sind nicht konfigurierbar. Jede erlaubte Aktion setzt den aufeinanderfolgenden Zähler zurück, während der Gesamtzähler für die Sitzung bestehen bleibt und nur zurückgesetzt wird, wenn sein eigenes Limit einen Fallback auslöst. Claude Code zählt eine Verweigerung nicht zu einem Schwellwert, wenn eine Sicherheitsüberprüfung, die vom Auto-Modus getrennt ist, die Anfrage des Klassifizierers verweigert; der verlinkte Eintrag behandelt, wie Claude Code diese Verweigerungen handhabt.
  • Sitzungen, die nicht auffordern können: Ein nicht-interaktiver nicht-interaktiver -p-Lauf ohne --permission-prompt-tool hat keine Eingabeaufforderung, auf die zurückgegriffen werden kann. Wenn wiederholte Blöcke einen Schwellwert erreichen, läuft die Aktion nicht und Claude arbeitet weiter. Das gleiche gilt, wenn eine Sicherheitsüberprüfung, die vom Auto-Modus getrennt ist, die Anfrage des Klassifizierers verweigert. Claude Code stoppt den Lauf in keinem Fall.
  • Ein Moduswechsel während einer Überprüfung: Wenn Sie Genehmigungsmodi wechseln, während eine Klassifiziererüberprüfung ausstehend ist, verwirft Claude Code ein Urteil, das der neue Modus nicht angefordert hätte, statt es anzuwenden: Sie werden stattdessen aufgefordert, oder die Aktion wird im dontAsk-Modus automatisch verweigert.

Wiederholte Blöcke bedeuten normalerweise, dass dem Klassifizierer Kontext über Ihre Infrastruktur fehlt. Verwenden Sie /feedback, um falsch positive zu melden, oder lassen Sie einen Administrator vertrauenswürdige Infrastruktur konfigurieren.

Jede Aktion durchläuft eine feste Entscheidungsreihenfolge. Der erste passende Schritt gewinnt: 
1. Aktionen, die Ihren [Allow-, Ask- oder Deny-Regeln](/docs/de/permissions#manage-permissions) entsprechen, werden sofort aufgelöst, mit diesen Ausnahmen:
   * Schreibvorgänge zu [geschützten Pfaden](#protected-paths) werden zum Klassifizierer weitergeleitet, auch wenn eine Allow-Regel passt, und ebenso `rm`- und `rmdir`-Löschungen, die auf einen [kritischen Pfad](#critical-paths) in Claude Code v2.1.218 und später abzielen
   * MCP-Tools, die mit [`requiresUserInteraction`](/docs/de/mcp#require-approval-for-a-specific-tool) gekennzeichnet sind, fordern Sie direkt auf, auch wenn eine Allow-Regel passt, und ebenso Connector-Tools [die Ihre Organisation auf `ask` gesetzt hat](/docs/de/mcp#organization-controls-on-connector-tools) in Sitzungen, in denen diese Einstellung Claude Code erreicht
   * Ein Shell-Befehl, der [pro-Befehl erlaubte Domains](/docs/de/sandboxing#per-command-allowed-domains-in-auto-mode) trägt, wird auch zum Klassifizierer weitergeleitet, auch wenn eine Allow-Regel passt, weil eine Regel den Befehl genehmigt, nicht seine Hosts
   * Ask-Regeln, die auf den Inhalt eines Befehls passen, wie `Bash(git push *)`, fallen auf eine Genehmigungseingabeaufforderung zurück
2. Schreibgeschützte Aktionen und Dateieditierungen in Ihrem Arbeitsverzeichnis werden automatisch genehmigt, außer Schreibvorgänge zu [geschützten Pfaden](#protected-paths) und [der erste Lesezugriff außerhalb der Arbeitsverzeichnisse](#first-read-outside-the-working-directories), die Sie auffordern
3. Alles andere geht zum Klassifizierer. Die Connector-Tools und `requiresUserInteraction`-MCP-Tools, die Sie direkt in Schritt 1 auffordern, erreichen den Klassifizierer nie, daher wird weder eine von der Organisation erforderliche Genehmigung noch ein Zustimmungsschritt automatisch genehmigt
4. Wenn der Klassifizierer blockiert, erhält Claude den Grund und versucht eine Alternative. In den meisten Sitzungen benennt der Grund die Regel, die der Klassifizierer passte, wie `[Data Exfiltration]`, statt eine schriftliche Erklärung zu geben; siehe [Verweigerungen überprüfen](/docs/de/auto-mode-config#review-denials)

Beim Eintritt in den Auto-Modus werden breite Allow-Regeln, die willkürliche Code-Ausführung gewähren, gelöscht:

* Pauschal `Bash(*)` oder `PowerShell(*)`
* Wildcard-Interpreter wie `Bash(python*)`
* Paketmanager-Ausführungsbefehle
* `Agent`-Allow-Regeln
* [`Monitor`](/docs/de/tools-reference#monitor-tool)-Allow-Regeln, weil Claude Code Monitor-Befehle durch die Shell ausführt

Enge Regeln wie `Bash(npm test)` bleiben in Kraft. Claude Code stellt die gelöschten Regeln wieder her, wenn Sie den Auto-Modus verlassen. Vor v2.1.236 ließ Claude Code `Monitor`-Allow-Regeln im Auto-Modus in Kraft, daher genehmigte eine Regel, die das ganze Tool passte, Monitor-Befehle ohne Klassifiziererüberprüfung.

Claude Code führt auch `git status` selbst vor einem Befehl aus, der nicht committete Arbeit verwerfen würde, wie `git reset --hard` oder `rm -rf`, und zeigt dem Klassifizierer, ob gestaffelte, geänderte oder nicht verfolgte Arbeit vorhanden ist. Claude Code meldet nicht verfolgte Dateien in dieser Überprüfung, auch wenn die Git-Konfiguration des Repositorys `status.showUntrackedFiles=no` setzt.

In den Klassifiziereranfragen, die Claude Code selbst sendet, sieht der Klassifizierer Benutzernachrichten, Tool-Aufrufe außer schreibgeschützten Lookups wie Dateileseoperationen und Suchen, und Ihren CLAUDE.md-Inhalt. Tool-Ergebnisse werden aus diesen Anfragen entfernt, daher kann feindselige Inhalte in einer Datei oder Webseite den Klassifizierer nicht direkt manipulieren.

Sie können einen Aufruf's Ergebnis mit einem [PostToolUse-Hook's `classifierContext`-Feld](/docs/de/hooks#annotate-a-result-for-the-auto-mode-classifier) kommentieren, das der Klassifizierer als von der Anwendung bereitgestellter Kontext liest. Das Feld erfordert Claude Code v2.1.236 oder später.

Eine separate serverseitige Sonde scannt eingehende Tool-Ergebnisse und kennzeichnet verdächtige Inhalte, bevor Claude sie liest. Für mehr darüber, wie diese Schichten zusammenarbeiten, siehe die [Auto-Modus-Ankündigung](https://claude.com/blog/auto-mode) und den [Engineering Deep Dive](https://www.anthropic.com/engineering/claude-code-auto-mode).
Wie Auto-Modus Subagents handhabt

Der Klassifizierer überprüft Subagent-Arbeit an drei Punkten:

  1. Bevor ein Subagent startet, wird die delegierte Aufgabenbeschreibung bewertet, daher wird eine gefährlich aussehende Aufgabe beim Spawn blockiert.
  2. Während der Subagent läuft, geht jede seiner Aktionen durch den Klassifizierer mit den gleichen Regeln wie die übergeordnete Sitzung, und jeder permissionMode in der Frontmatter des Subagents wird ignoriert.
  3. Wenn der Subagent fertig ist, überprüft der Klassifizierer seine Arbeit und seinen endgültigen Bericht, bevor die übergeordnete Sitzung den Bericht liest. Wenn der Klassifizierer die Arbeit oder den Bericht des Subagents kennzeichnet, oder eine separate API-Sicherheitsüberprüfung die Überprüfung verweigert, wird der Bericht immer noch geliefert, vorangestellt mit einer Sicherheitswarnung. Wenn der Klassifizierer für die Überprüfung nicht verfügbar ist, kommt der Bericht mit einem Hinweis an, die Arbeit des Subagents zu überprüfen, bevor Sie danach handeln.

Schritt 1 erfordert Claude Code v2.1.178 oder später. Frühere Versionen wendeten den Klassifizierer bei Schritten 2 und 3 an, bewerteten aber nicht die Aufgabenbeschreibung, bevor der Subagent startete.

Kosten und Latenz

Der Klassifizierer läuft standardmäßig auf Claude Sonnet 5 statt auf Ihrer /model-Auswahl. Ein Klassifizierermodell, das Anthropic serverseitig konfiguriert, hat Vorrang vor diesem Standard. Wenn das Modell Ihrer Sitzung Claude Sonnet 4.6 ist, oder wenn availableModels Sonnet 5 ausschließt, läuft der Klassifizierer stattdessen auf dem Modell Ihrer Sitzung oder auf einem Opus-Modell, wenn die Sitzung auf einem Fable-Modell läuft; auf Anbietern außer der Anthropic API ist dieses Opus-Fallback das Standard-Opus-Modell des Anbieters.

Die erste Auto-Modus-Anfrage Ihrer Sitzung validiert den Sonnet 5-Standard: Wenn die Anfrage erfolgreich ist, bleibt Sonnet 5 das Klassifizierermodell Ihrer Sitzung, und wenn sie fehlschlägt, weil das Modell nicht verfügbar ist, verwendet die Sitzung stattdessen das Fallback. Nachdem diese Validierung sich beruhigt hat, ändert sich das Klassifizierermodell nicht für die Sitzung.

Bei Enterprise-Plänen und bei Konten, die die Claude API verwenden, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform oder Microsoft Foundry, zählen Klassifiziereraufrufe zu Ihrer Token-Nutzung. Jede Überprüfung sendet einen Teil des Transkripts plus die ausstehende Aktion, was eine Hin- und Rückfahrt vor der Ausführung hinzufügt. Lesezugriffe und Arbeitsverzeichnis-Editierungen außerhalb geschützter Pfade überspringen den Klassifizierer, daher kommt der Overhead hauptsächlich von Shell-Befehlen und Netzwerkoperationen. Wo der Server die Aktionen als Teil der Modellabfragen der Sitzung überprüft, gibt es keine separaten Klassifiziereraufrufe zu zählen; siehe Serverseitige Klassifiziererüberprüfung.

Sandbox-Netzwerkzugriff fügt keine Pro-Verbindungs-Klassifiziereranfragen hinzu. Der Klassifizierer beurteilt die Hosts, die ein Befehl benennt zusammen mit dem Befehl in einer Überprüfung, und Claude Code überprüft jede Verbindung gegen die genehmigte Liste, ohne den Klassifizierer erneut aufzurufen.

Nur vorab genehmigte Tools mit dontAsk-Modus zulassen

Wenn Sie den dontAsk-Modus einstellen, lehnt Claude Code automatisch jeden Tool-Aufruf ab, der Sie sonst auffordern würde. Claude führt weiterhin Aktionen aus, die im Manual-Modus keine Genehmigung benötigen, wie z. B. Dateilesevorgänge in Ihren Arbeitsverzeichnissen und schreibgeschützte Bash-Befehle, sowie Aktionen, die Ihren permissions.allow-Regeln entsprechen, und Aufrufe, die von einem PreToolUse-Hook genehmigt wurden. Verwenden Sie diesen Modus für CI-Pipelines oder eingeschränkte Umgebungen, in denen Sie vorab definieren, was Claude tun darf; die Sitzung wartet nie auf Eingaben. Die Statusleiste zeigt ⏵⏵ don't ask on, während dieser Modus aktiv ist.

Claude Code lehnt Aufrufe ab, die Ihren expliziten ask-Regeln entsprechen, anstatt Sie aufzufordern. Es lehnt auch das integrierte AskUserQuestion-Tool ab, selbst wenn Ihre Allow-Regeln damit übereinstimmen, und macht dasselbe mit Connector-Tools, die Ihre Organisation auf ask gesetzt hat, in Sitzungen, in denen diese Einstellung Claude Code erreicht. Es lehnt MCP-Tools, die mit _meta["anthropic/requiresUserInteraction"] gekennzeichnet sind, auf die gleiche Weise ab, da ihre Genehmigungskarte eine Antwort benötigt, die dieser Modus nie erfasst; dies erfordert Claude Code v2.1.199 oder später.

rm- und rmdir-Löschungen, die auf einen kritischen Pfad abzielen, wie z. B. rm -rf / und rm -rf ~, werden abgelehnt, selbst wenn eine Allow-Regel damit übereinstimmt oder ein PreToolUse-Hook sie zulässt.

Cloud-Sitzungen auf Claude Code im Web ignorieren defaultMode: "dontAsk"; siehe bypassPermissions für Details.

Stellen Sie es beim Start mit dem Flag ein:

claude --permission-mode dontAsk

Alle Überprüfungen mit bypassPermissions-Modus überspringen

Der bypassPermissions-Modus deaktiviert Berechtigungsaufforderungen und Sicherheitsüberprüfungen, sodass Tool-Aufrufe sofort ausgeführt werden, einschließlich Schreibvorgänge in geschützte Pfade.

Die Aktionen, die kein Modus automatisch genehmigt fordern weiterhin in diesem Modus auf.

Zwei Cross-Session-Messaging Schutzmaßnahmen gelten weiterhin in diesem Modus und in interaktiven Terminal-Plan-Mode-Sitzungen, in denen Bypass-Berechtigungen verfügbar sind:

  • Die isolatePeerMachines Genehmigungsaufforderung für Nachrichten an Ihre Sitzungen über diese Maschine hinaus wird weiterhin angezeigt.
  • Wenn kein crossSessionInbound Wert zutrifft, hält Claude Code eine eingehende Nachricht von einer anderen Ihrer Sitzungen für Ihre Genehmigung und liefert ohne Fragen nur, wenn die sendende Sitzung sich selbst als auch Berechtigungsaufforderungen umgehend identifiziert. Wenn Sie den Berechtigungsmodus verlassen, während Nachrichten gehalten werden, wendet Claude Code die eingehenden Regeln erneut an und liefert jede gehaltene Nachricht, die sie jetzt akzeptieren.

In interaktiven Terminal-Sitzungen mit verfügbaren Bypass-Berechtigungen erzwingt Claude Code auch nicht Plan-Mode's Blockierungen. Claude wird immer noch angewiesen, ohne Bearbeitung zu planen, aber ein Dateibearbeitungs- oder Shell-Befehl, den es während der Planung versucht, läuft ohne Aufforderung. Explizite Ask-Regeln und rm und rmdir Löschungen, die auf einen kritischen Pfad abzielen, fordern weiterhin auf.

Der Plan-Mode behält seine Blockierungen überall dort bei, wo Claude Code ohne interaktives Terminal läuft, einschließlich nicht-interaktiver Ausführungen mit -p, Agent SDK Sitzungen und Unterhaltungen im Chat-Panel der VS Code-Erweiterung. Dort macht --allow-dangerously-skip-permissions bypassPermissions später auswählbar.

Sie können bypassPermissions nicht aus einer Sitzung eingeben, die Sie ohne ihn gestartet haben. Aktivieren Sie es beim Start mit permissions.defaultMode: "bypassPermissions" oder mit einem aktivierenden Flag:

claude --permission-mode bypassPermissions

Das Flag --dangerously-skip-permissions ist gleichwertig.

Claude Code verweigert bypassPermissions in einer Sitzung, die Sie mit --restricted starten. --restricted erfordert Claude Code v2.1.248 oder später.

Das erste Mal, wenn Sie eine interaktive Sitzung mit diesem Modus aktiviert starten, zeigt Claude Code einen Warnungsdialog, der Sie auffordert, Verantwortung für Aktionen ohne Berechtigungsprüfungen zu übernehmen. Claude Code speichert Ihre Akzeptanz in Benutzereinstellungen, sodass der Dialog nur einmal angezeigt wird. Wenn Sie ablehnen, beendet Claude Code. Im nicht-interaktiven Modus wird kein Dialog angezeigt, und eine Hintergrund-Sitzung, die mit --bg gestartet wurde, wird verweigert, bis Sie den Dialog in einer interaktiven Sitzung akzeptiert haben.

Auf Linux und macOS weigert sich Claude Code, in diesem Modus zu starten, wenn es als Root oder unter sudo ausgeführt wird:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Die Überprüfung wird automatisch in einer erkannten Sandbox übersprungen. Um autonom in einem Container zu laufen, verwenden Sie die Dev-Container Konfiguration, die Claude Code als Nicht-Root-Benutzer ausführt.

Claude Code im Web berücksichtigt defaultMode: "bypassPermissions" oder "dontAsk" aus Ihren Einstellungsdateien nicht, daher können die eingecheckten Einstellungen eines Repositorys keine Cloud-Sitzung im Bypass-Permissions-Modus starten. Die Einstellung wird stillschweigend ignoriert und die Sitzung startet im Berechtigungsmodus, der im Modusmenü angezeigt wird. Siehe Berechtigungsmodi wechseln, welche Modi Cloud-Sitzungen bieten.

Geschützte Pfade

Schreibvorgänge in eine kleine Anzahl von Pfaden werden niemals automatisch genehmigt, außer im bypassPermissions-Modus und in interaktiven Terminal-Sitzungen im Plan-Modus mit verfügbaren Bypass-Berechtigungen. Dies verhindert versehentliche Beschädigungen des Repository-Status und der eigenen Konfiguration von Claude.

Modus Schreibvorgänge in geschützten Pfaden
default, acceptEdits Abgefragt
plan Erlaubt in interaktiven Terminal-Sitzungen mit verfügbaren Bypass-Berechtigungen. Andernfalls zum Klassifizierer geleitet, wenn Auto-Modus während der Planung verfügbar ist, und abgefragt, wenn nicht
auto Zum Klassifizierer geleitet
dontAsk Verweigert
bypassPermissions Erlaubt

In einer Sitzung, die mit --restricted gestartet wurde, was Claude Code v2.1.248 oder später erfordert, kann der Klassifizierer Schreibvorgänge in geschützten Pfaden nicht genehmigen.

permissions.allow Regeln in Einstellungsdateien genehmigen Schreibvorgänge in geschützten Pfaden nicht im Voraus. Die Sicherheitsprüfung wird ausgeführt, bevor Claude Code die Allow-Regeln aus den Einstellungen auswertet, daher ändert ein Eintrag wie Edit(.claude/**) in ~/.claude/settings.json oder .claude/settings.json das Ergebnis pro Modus in der obigen Tabelle nicht. In Modi, die abfragen, bietet die Eingabeaufforderung für einen .claude/ Schreibvorgang Ja, und Claude darf seine eigenen Einstellungen für diese Sitzung bearbeiten, was spätere .claude/ Schreibvorgänge in dieser Sitzung genehmigt, ohne erneut abzufragen.

Geschützte Verzeichnisse:

  • .git
  • .config/git
  • .vscode
  • .idea
  • .husky
  • .cargo
  • .devcontainer
  • .yarn
  • .mvn
  • .claude, außer .claude/worktrees, wo Claude seine eigenen Git-Worktrees speichert

Geschützte Dateien:

  • .gitconfig, .gitmodules
  • .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
  • .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
  • .bazelrc, .bazelversion, .bazeliskrc
  • .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
  • gradle-wrapper.properties, maven-wrapper.properties
  • .devcontainer.json
  • .ripgreprc, pyrightconfig.json
  • .mcp.json, .claude.json

Kritische Pfade

Claude Code lässt nie eine permissions.allow Regel oder einen PreToolUse Hook, der "allow" zurückgibt, einen rm oder rmdir Befehl genehmigen, der auf einen kritischen Pfad abzielt, auch in Modi, die andere Aufforderungen überspringen. Dieser Schutzschalter schützt vor Modellfehler. Eine übereinstimmende Deny-Regel blockiert den Befehl weiterhin direkt.

Was stattdessen passiert, hängt von Ihrem Berechtigungsmodus ab:

Modus Was Claude Code mit einer kritischen Pfad-Löschung tut
default, acceptEdits Fragt Sie, um sie zu genehmigen
plan Fragt Sie, um sie zu genehmigen. Mit Auto-Modus während der Planung verfügbar und keine Bypass-Berechtigungen verfügbar, sendet es stattdessen zum Klassifizierer
auto Sendet es zum Klassifizierer
dontAsk Verweigert es
bypassPermissions Fragt Sie, um sie zu genehmigen

Wenn eine explizite Ask-Regel den Befehl übereinstimmt, fragt Claude Code Sie, auch im auto Modus. In Modi, die fragen, kann ein PermissionRequest Hook die Aufforderung auf die gleiche Weise beantworten wie jede andere.

Claude Code behandelt ein rm oder rmdir Ziel als kritischen Pfad, wenn es eines der folgenden ist:

  • Das Dateisystem-Root
  • Top-Level-Verzeichnisse, was bedeutet, jedes direkte Kind des Root, wie /usr, /etc oder /data
  • Ihr Home-Verzeichnis
  • Windows-Laufwerk-Roots und ihre Top-Level-Verzeichnisse, wie C:\ und C:\Windows
  • Ihr Arbeitsverzeichnis und seine übergeordneten Verzeichnisse
  • Ihre zusätzlichen Arbeitsverzeichnisse und ihre übergeordneten Verzeichnisse, aber nur wenn die Löschung ein Glob unter einem von ihnen ist, wie rm -rf <dir>/*. rm -rf <dir> auf dem Verzeichnis selbst löst diese Prüfung nicht aus

Claude Code behandelt auch ein Glob oder einen nachfolgenden Schrägstrich direkt unter einer Shell-Variable, wie rm -rf "$DIR"/*, als kritische Pfad-Löschung, da der Befehl zu einer Löschung vom Dateisystem-Root wird, wenn die Variable leer ist.

Das Verstecken der Löschung in einer Subshell mit (...), einer Brace-Gruppe mit { ...; }, Befehlsersetzung mit $(...) oder Backticks oder Prozessersetzung mit <(...) überspringt die Prüfung nicht. Claude Code findet eine kritische Pfad-Löschung, ob sie in der verschachtelten Form sitzt, wie in (rm -rf ~) oder echo "$(rm -rf ~)", oder anderswo im gleichen Befehl.

Remove-Item in PowerShell

Wenn Sie das PowerShell-Tool aktivieren, gibt Claude Code Remove-Item seine eigene Prüfung, getrennt von der rm kritischen Pfad-Liste. Das Ergebnis hängt vom Ziel ab, und der erste übereinstimmende Fall gilt:

  • System-Pfade: Das Dateisystem-Root und seine Top-Level-Verzeichnisse, Laufwerk-Roots und ihre Top-Level-Verzeichnisse, und Ihr Home-Verzeichnis. Claude Code verweigert den Befehl in jedem Modus, ohne Sie zu fragen.
  • Wildcards: Ein bloßes *, oder jedes Ziel, das mit /* oder \* endet, einschließlich eines Globs unter einer Shell-Variable wie $dir/*. Claude Code verweigert den Befehl in jedem Modus, ohne Sie zu fragen, bevor der Klassifizierer ihn sieht.
  • Ihr Arbeitsverzeichnis oder eines seiner übergeordneten Verzeichnisse, mit -Recurse: Claude Code behandelt den Befehl wie jeden anderen, der Genehmigung benötigt in Ihrem Berechtigungsmodus, daher fragt es Sie in Modi, die fragen, sendet es zum Klassifizierer im auto Modus, und verweigert es im dontAsk Modus. Der bypassPermissions Modus überspringt diese Prüfung.

Siehe auch

  • Berechtigungen: Allow-, Ask- und Deny-Regeln; verwaltete Richtlinien
  • Auto-Modus konfigurieren: Teilen Sie dem Klassifizierer mit, welche Infrastruktur Ihre Organisation vertraut
  • Hooks: Benutzerdefinierte Berechtigungslogik über PreToolUse und PermissionRequest Hooks
  • Sicherheit: Schutzmaßnahmen und Best Practices
  • Sandboxing: Dateisystem- und Netzwerkisolation für Bash-Befehle
  • Nicht-interaktiver Modus: Führen Sie Claude Code mit dem Flag -p aus