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.

VS Code

Während einer Sitzung: Klicken Sie auf den Modusindikator am unteren Rand des Eingabefelds. Er verwendet diese Beschriftungen für die Modi auf dieser Seite:

Als Standard: Um den Berechtigungsmodus zu fixieren, in dem Konversationen starten, setzen Sie claudeCode.initialPermissionMode in Ihren VS Code-Benutzereinstellungen auf default, manual, acceptEdits, plan oder bypassPermissions. Die Einstellung akzeptiert nicht auto; um im Auto-Modus zu starten, lassen Sie sie ungesetzt und wählen Sie Auto aus dem Modusindikator einmal aus, wie Punkt 2 unten beschreibt. Die Erweiterung startet jede neue Konversation in der ersten dieser Punkte, die zutrifft:

1. claudeCode.initialPermissionMode
2. Der Modus, den Sie zuletzt aus dem Modusindikator gewählt haben, wenn er Manual, Edit automatically oder Auto war. Das Auswählen von Plan oder Bypass permissions gilt nur für diese Konversation
3. permissions.defaultMode aus verwalteten Einstellungen oder ~/.claude/settings.json
4. Der integrierte Standard für Ihren Plan, Anbieter und Organisationseinstellungen

Die Erweiterung liest nie .claude/settings.json oder .claude/settings.local.json eines Projekts für den Start-Berechtigungsmodus. Wenn claudeCode.claudeProcessWrapper gesetzt ist, gelten Punkte 3 und 4 nicht: Diese Konversationen starten im Manual-Modus, es sei denn, Punkt 1 oder Punkt 2 setzt einen Berechtigungsmodus.

Vor v2.1.283 galt Punkt 3 nur bei Pro-, Max- und Team-Plänen in Sitzungen, die Feature-Flags abrufen.

Auto wird im Modusindikator angezeigt, wenn Auto-Modus verfügbar ist.

Bypass permissions erfordert den Schalter Allow dangerously skip permissions in den Erweiterungseinstellungen. Ohne ihn wird der Berechtigungsmodus nicht im Indikator angezeigt, und ein bypassPermissions Wert aus Punkt 1 oder Punkt 3 startet die Konversation stattdessen im Manual-Modus. Auto aus jedem Punkt startet die Konversation ebenfalls im Manual-Modus, wenn Auto-Modus nicht verfügbar ist.

Siehe den VS Code-Leitfaden für erweiterungsspezifische Details.

JetBrains

Das JetBrains-Plugin führt Claude Code im IDE-Terminal aus, daher funktioniert das Wechseln von Berechtigungsmodi genauso wie in der CLI: Drücken Sie Shift+Tab zum Durchlaufen, oder übergeben Sie --permission-mode beim Start.

Desktop

Während einer Sitzung: Verwenden Sie auf der Registerkarte Code den Moduswahlschalter in der Zeile unter dem Eingabefeld. Nicht jeder Modus wird im Wahlschalter angezeigt:

• Auto: wird angezeigt, wenn Auto-Modus verfügbar ist
• Bypass permissions: erfordert den Schalter Allow bypass permissions mode in den Desktop-Einstellungen bei Pro- und Max-Plänen; bei Team- und Enterprise-Plänen wird dies stattdessen durch die Organisationsrichtlinie gesteuert

Cowork verwendet diese Modi nicht. Es hat seine eigenen Berechtigungsmodi, die separat aktiviert werden, und zeigt überhaupt keinen Moduswahlschalter an, bis ein Modus über seinen Standard hinaus für Ihr Konto aktiviert wird. Siehe die Cowork-Dokumentation.

Für Desktop-spezifische Details siehe Wählen Sie einen Berechtigungsmodus im Desktop-Leitfaden.

Als Standard: Setzen Sie defaultMode in Einstellungen. Die Desktop-App liest die gleichen Einstellungsdateien wie die CLI und wendet den Berechtigungsmodus auf neue lokale Sitzungen an.

Ein Modus, den Sie im Moduswahlschalter auswählen, wird pro Ordner gespeichert und hat Vorrang vor defaultMode für diesen Ordner. Plan ist die Ausnahme: Das Auswählen gilt nur für die aktuelle Sitzung.

Wo defaultMode in einer Einstellungsdatei steht, sehen Sie im Beispiel unter Starten Sie in einem anderen Berechtigungsmodus.

Web and mobile

Verwenden Sie auf claude.ai/code das Modusmenü in der Zeile unter dem Eingabefeld. Tippen Sie in der mobilen App auf die Schaltfläche + im Eingabefeld und dann auf Permission. Cloud-Sitzungen und Remote-Control-Sitzungen bieten unterschiedliche Berechtigungsmodi:

• Cloud-Sitzungen: Bearbeitungen akzeptieren, Plan und Auto. Bearbeitungen akzeptieren entspricht dem default Modus: Cloud-Sitzungen genehmigen Dateibearbeitungen vorab, unabhängig vom Modus, daher zeigt das Menü Bearbeitungen akzeptieren statt Manual an. Cloud-Sitzungen respektieren weiterhin defaultMode: "acceptEdits" aus den Einstellungen. Der Auto-Modus wird nur angezeigt, wenn Ihre Organisation ihn zulässt und das ausgewählte Modell ihn unterstützt. Bypass permissions ist nicht verfügbar.
• Remote Control-Sitzungen auf Ihrem lokalen Computer: Manual, Bearbeitungen akzeptieren, Plan und Auto für eine Sitzung, die Sie selbst gestartet haben, und Sie können Bypass permissions nicht aus der App auswählen. Um Auto zu verwenden, muss die Sitzung die Verfügbarkeitsanforderungen des Auto-Modus erfüllen. Für einen Projekt-Thread, der auf Ihrem Computer läuft, siehe Führen Sie einen Thread auf Ihrem eigenen Computer aus.
  • Außer für Bypass permissions zeigt das Menü den Berechtigungsmodus an, in dem sich die lokale Sitzung befindet, einschließlich eines vom Terminal aus festgelegten Modus. Es wird aktualisiert, wenn sich der Berechtigungsmodus in der App oder im Terminal ändert.
  • Sitzungen, die von der Desktop-App oder der VS Code-Erweiterung gehostet werden, melden Berechtigungsmodus-Änderungen an claude.ai, während sie passieren, genauso wie Sitzungen, die in einem Terminal gehostet werden.

Für Remote Control muss der lokale Computer, auf dem die Sitzung läuft, mit Ihrem claude.ai-Konto angemeldet sein; API-Schlüssel werden nicht unterstützt. Sie können auch den Start-Berechtigungsmodus beim Start dieser lokalen Sitzung festlegen:

claude remote-control --permission-mode acceptEdits

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. Mit Ausnahme von touch werden diese Befehle auch automatisch genehmigt, wenn ihnen sichere Umgebungsvariablen wie LANG=C oder NO_COLOR=1 oder Prozess-Wrapper wie timeout, nice oder nohup vorangestellt sind. Wie bei Dateibearbeitungen gilt die automatische Genehmigung nur für Pfade in Ihrem Arbeitsverzeichnis oder additionalDirectories.

Bei Folgendem wird weiterhin nachgefragt:

• Pfade außerhalb dieses Bereichs
• Schreibvorgänge in geschützte Pfade
• Erkannte rm- und rmdir-Löschungen kritischer Pfade
• touch mit allem, was über einfache Dateipfade hinausgeht, zum Beispiel eine Option, ein Glob oder ein Präfix wie timeout 5 oder LANG=C
• Alle anderen Bash-Befehle außer dem integrierten Satz nur lesender Befehle

Jeder Pfad durchläuft auch die Symlink-Prüfung, daher wird ein Schreibvorgang, der außerhalb dieses Bereichs aufgelöst wird, ebenfalls nicht automatisch genehmigt.

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.

Was mit einem Shell-Befehl während der Planung geschieht, hängt von der Sitzung ab, und der erste dieser Fälle, der zutrifft, gilt:

• Interaktive Terminal-Sitzungen mit verfügbaren Bypass-Berechtigungen: Weder der Klassifizierer noch eine Aufforderung gilt für Planungsbefehle. Alle Überprüfungen mit bypassPermissions-Modus überspringen behandelt die wenigen Dinge, die dort weiterhin auffordern.
• Auto-Modus verfügbar und die useAutoModeDuringPlan Einstellung aktiviert, was die Standardeinstellung ist: Der Klassifizierer überprüft Shell-Befehle außer kritischen Pfad-Entfernungen statt Sie zu fragen. Genehmigte Befehle laufen, und abgelehnte werden blockiert.
• Auto-Modus nicht verfügbar oder useAutoModeDuringPlan deaktiviert: Befehle außerhalb des integrierten schreibgeschützten Satzes fordern zur Genehmigung auf, auch wenn der Sandbox-Auto-Allow-Modus aktiviert ist.

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 für Ihre Sitzung verfügbar ist, beispielsweise weil Ihre Organisation ihn deaktiviert hat, 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 Start-Berechtigungsmodus. Dort setzen Sie stattdessen claudeCode.initialPermissionMode auf plan in Ihren VS Code-Benutzereinstellungen.

Berechtigungsabfragen mit dem Auto-Modus eliminieren

Der Auto-Modus ermöglicht es Claude, ohne routinemäßige Berechtigungsabfragen auszuführen. Ein separates Klassifikatormodell überprüft Aktionen, bevor sie ausgeführt werden, 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 Ask-Regeln erzwingen weiterhin eine Abfrage.

Mit Claude Code v2.1.283 oder später ist der Auto-Modus der integrierte Start-Berechtigungsmodus für interaktive Terminal- und VS Code-Sitzungen in jedem Plan und bei jedem Anbieter. Bei früheren Versionen ist er der integrierte Start-Berechtigungsmodus nur bei Pro-, Max- und Team-Plänen.

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

Standardmäßig überprüft der Klassifikator keine erkannten rm- und rmdir-Löschvorgänge auf kritischen Pfaden, wie etwa rm -rf / oder rm -rf ~. Unter Kritische Pfade wird beschrieben, was in jedem Berechtigungsmodus mit ihnen geschieht.

Der Auto-Modus ermutigt Claude auch, ohne Unterbrechung für Klärungsfragen weiterzuarbeiten, obwohl Claude immer noch fragt, wenn Ihr Prompt oder ein Skill explizit darauf angewiesen ist. Für stärkeres autonomes Verhalten in einem Modus, der Sie weiterhin um Bestätigung bittet, stellen Sie stattdessen den Proactive-Ausgabestil ein.

[!WARNING]

Der Auto-Modus reduziert Berechtigungsabfragen, garantiert aber keine Sicherheit. Verwenden Sie ihn für Aufgaben, bei denen Sie der allgemeinen Richtung vertrauen, nicht als Ersatz für eine Überprüfung bei sensiblen Operationen.

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: Bei der Anthropic API und Claude Platform auf AWS Claude Opus 4.6 oder später, Sonnet 4.6 oder später, Haiku 5.5 oder ein Fable-Modell. Bei Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen nur Claude Sonnet 5 oder später, Opus 4.7 oder später, Haiku 5.5 und die Fable-Modelle. Ältere Modelle, einschließlich Sonnet 4.5, Opus 4.5, Haiku 4.5 und claude-3-Modelle, werden bei keinem Anbieter unterstützt.
• Anbieter: Standardmäßig verfügbar bei der Anthropic API, Claude Platform auf AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen.

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 daher 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 Klassifikatoranfrage fehlgeschlagen ist. Dieser Fehler ist normalerweise vorübergehend, kann sich aber bei Amazon Bedrock wiederholen, 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 ohne Fehler im Manual-Modus 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 nach ~/.claude/settings.json. Überprüfen Sie für eine Konversation, die die VS Code-Erweiterung gestartet hat, stattdessen die eigene Liste der Erweiterung in Berechtigungsmodi wechseln.

Auto-Modus auf Bedrock, Agent Platform oder Foundry

Bei Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeten Claude-Apps-Gateway-Sitzungen ist der Auto-Modus standardmäßig verfügbar. Wenn Sie dort keinen Berechtigungsmodus setzen, starten interaktive Sitzungen im Auto-Modus, und claude -p- oder Agent SDK-Läufe starten im Manual-Modus, dessen Konfigurationswert default ist:

• Interaktive Terminal- und VS Code-Sitzungen: Um sie in einem anderen Berechtigungsmodus als auto zu starten, setzen Sie permissions.defaultMode wie in In einem anderen Berechtigungsmodus starten beschrieben, oder wählen Sie einen aus dem Modus-Indikator der VS Code-Erweiterung. In welchem Modus eine Sitzung startet listet die Claude Code-Versionen auf, die sie im Auto-Modus starten.
• claude -p- und Agent SDK-Läufe: Um einen Lauf im Auto-Modus zu starten, übergeben Sie --permission-mode auto an claude -p, oder übergeben Sie permissionMode: "auto" in TypeScript bzw. permission_mode="auto" in Python. Wenn Sie keinen Berechtigungsmodus übergeben, siehe Tool-Aufrufe in claude -p- und Agent SDK-Läufen verweigert, wo auch frühere Claude Code-Versionen behandelt werden.

Nur Claude Sonnet 5 oder später, Opus 4.7 oder später, Haiku 5.5 und die Fable-Modelle werden auf diesen Anbietern unterstützt. Bei jedem anderen Modell startet die Sitzung stattdessen im Manual-Modus. Der Auto-Modus mit Haiku 5.5 auf diesen Anbietern erfordert Claude Code v2.1.293 oder später.

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 wird, startet stattdessen im Manual-Modus. Eine bereits im Auto-Modus laufende Sitzung verlässt ihn, wenn die Einstellung diese Sitzung aus einer von Administratoren bereitgestellten Quelle erreicht, und zeigt auto mode disabled by settings. Vor v2.1.251 behielt eine laufende Sitzung den Auto-Modus bis zu ihrem Ende.

Serverseitige Klassifikatorüberprüfung

Im Auto-Modus kann Claude Code den Server bitten, die Aktionen zu überprüfen, die die Entscheidungsreihenfolge zur Überprüfung sendet, als Teil der Modellanfragen der Sitzung, anstatt eigene Klassifikatoranfragen zu senden. Diese Sitzungen fragen beim Server an:

• Eine direkte Verbindung zur Anthropic API: in interaktiven Terminal-Sitzungen sowie in -p-, Agent SDK-, VS Code-Erweiterungs- und Desktop-App-Sitzungen, unabhängig von Ihrem Plan oder Kontotyp, während Anthropic dies einführt. In interaktiven Terminal-Sitzungen erfordert dies Claude Code v2.1.271 oder später bei Pro-, Max- und Team-Plänen und v2.1.278 oder später bei Enterprise-Plänen und Claude API-Konten. In -p-, Agent SDK-, VS Code-Erweiterungs- und Desktop-App-Sitzungen erfordert dies Claude Code v2.1.281 oder später. Ab v2.1.282 fragt eine Sitzung, die keine Feature-Flags abruft, zum Beispiel weil Sie die Telemetrie deaktiviert haben, in jeder Art von Sitzung standardmäßig beim Server an.
• Ein Cloud-Anbieter oder ein LLM-Gateway oder Proxy: bei Claude Platform auf AWS, Amazon Bedrock, Google Cloud's Agent Platform und Microsoft Foundry, und wann immer Sie ANTHROPIC_BASE_URL auf ein LLM-Gateway oder einen Proxy verweisen lassen, unabhängig von Ihrem Plan. Das standardmäßige Anfragen erfordert Claude Code v2.1.278 oder später.
• Eine angemeldete Claude-Apps-Gateway-Sitzung: erfordert Claude Code v2.1.280 oder später
• Eine Cloud-Sitzung in einer von Anthropic gehosteten Umgebung: unabhängig von Ihrem Plan, wenn Sie sie im Web, in der mobilen App oder in der Desktop-App mit ausgewählter Option Cloud starten. Sitzungen, die von einer geplanten Cloud-Aufgabe gestartet werden, fragen beim Server an, während Anthropic dies einführt.

Wenn der Server die Aktionen überprüft, entscheiden seine Urteile über sie. Zwei weitere Ergebnisse sind möglich:

• Der Server überprüft die Sitzung nicht: Eine Antwort wird ohne Überprüfungsergebnisse abgeschlossen, oder der Server antwortet, dass er diese Sitzung nicht überprüft. Die häufigsten Ursachen sind ein LLM-Gateway oder Proxy, das die Anfrage zur Überprüfung oder die Ergebnisse verwirft, und eine Plattform, Region oder Anmeldedaten, für die es noch keine serverseitigen Überprüfungen gibt. Claude Code fällt auf seine eigenen Klassifikatoranfragen zurück. Sobald dieser Fallback für den Rest der Sitzung gilt, zeigt es bei Konten, bei denen diese Anfragen in Rechnung gestellt werden, einen Hinweis zu Gebühren für Klassifikatoranfragen.
• Der Server gibt kein Urteil für eine Aktion ab: Claude Code verweigert die Aktion, anstatt sie ungeprüft auszuführen. Bei jeder Verbindung geschieht dies, wenn die Antwort endet, bevor die Überprüfungsergebnisse ankommen, oder die Ergebnisse in einer Form ankommen, die Claude Code nicht lesen kann. Ein LLM-Gateway oder Proxy, das Antworten kürzt oder die Ergebnisse umschreibt, kann beides verursachen. Bei einer direkten Verbindung zur Anthropic API geschieht dies auch, wenn die Überprüfung des Servers für die Aktion fehlschlägt, zum Beispiel durch ein Timeout. Der Server hat kein Sicherheitsurteil zurückgegeben behandelt die Verweigerungsmeldung, was geschieht, wenn sich Verweigerungen wiederholen, und was zu tun ist.

Um die Anfrage beim Server zu überspringen und immer die eigenen Klassifikatoranfragen von Claude Code zu verwenden, setzen Sie CLAUDE_CODE_AUTO_MODE_SERVER=0. Bei einer direkten Verbindung zur Anthropic API erfordert die Variable Claude Code v2.1.281 oder später. Wenn Sie sie dort auf 1 setzen, wird die Serverüberprüfung in einer Sitzung aktiviert, die sie noch nicht hat, es sei denn, Sie haben auch CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 gesetzt. Wenn Sie CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 setzen und CLAUDE_CODE_AUTO_MODE_SERVER nicht setzen, fragt Claude Code ebenfalls nicht mehr beim Server an, außer wie in Vorabversions-Funktionen deaktivieren beschrieben.

Standard-Klassifikatormodell

Standardmäßig gehen Klassifikatoranfragen an Claude Sonnet 5. Wenn /status Auto mode server als Enabled anzeigt, werden sie nur für Aufrufe außerhalb der Überprüfung durch den Server gesendet.

Suchen Sie die erste Zeile in dieser Tabelle, die auf Ihre Sitzung zutrifft. Sie erhalten das Modell dieser Zeile statt Sonnet 5.

Wenn Sonnet 5 oder das Modell in ANTHROPIC_DEFAULT_SONNET_MODEL bei Ihrem Anbieter nicht verfügbar ist oder durch die Modellrichtlinie Ihrer Organisation ausgeschlossen wird, verwendet Claude Code ein Fallback-Modell. Das ist das Modell Ihrer Sitzung oder ein Opus-Modell in einer Fable-Sitzung.

Klassifikatormodell wählen

Setzen Sie mit Claude Code v2.1.302 oder später CLAUDE_CODE_AUTO_MODE_MODEL auf eine vollständige Modell-ID, um den Klassifikator auf einem anderen Modell als dem Standard auszuführen. Die eigenen vollständigen Modell-IDs Ihres Cloud-Anbieters funktionieren ebenfalls. Dieses ~/.claude/settings.json-Beispiel setzt Claude Sonnet 4.6:

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

Wenn nicht Ihr Modell überprüft

Wenn mehrere Situationen zutreffen, richten Sie sich nach der zuerst aufgeführten.

Prüfen, welches Modell der Klassifikator verwendet hat

Starten Sie aus Ihrer Shell eine Auto-Modus-Sitzung mit --debug-file:

claude --permission-mode auto --debug-file classifier-debug.log

Lassen Sie Claude einen Shell-Befehl ausführen, der nicht nur lesend ist, und durchsuchen Sie dann das Log nach classifier_request_started:

• Ihr Modell nach model=: Die Variable ist wirksam geworden
• Ein anderes Modell nach model=: Durchsuchen Sie das Log nach ignoring CLAUDE_CODE_AUTO_MODE_MODEL; dort finden Sie den Grund und gegebenenfalls einen nötigen Schritt
• Keine solche Zeile: Lesen Sie Auto mode server in /status an der Claude Code-Eingabeaufforderung ab:
  • Enabled: Der Server ist so eingestellt, dass er die Aufrufe dieser Sitzung überprüft.
  • Disabled: Stellen Sie sicher, dass der Berechtigungsmodus auto ist, und lassen Sie Claude dann einen weiteren Befehl ausführen, der nicht nur lesend ist.

Was der Klassifikator standardmäßig blockiert

Der Klassifikator vertraut Ihrem Arbeitsverzeichnis und den Remotes, die dafür konfiguriert waren, als die Sitzung begann. Einem 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.

Standardmäßig blockiert:

• Herunterladen und Ausführen von Code, wie curl | bash

• Senden sensibler Daten an externe Endpunkte

• Produktionsbereitstellungen und Migrationen

• Massenlöschung in Cloud-Speicher

• Gewährung von IAM- oder Repo-Berechtigungen

• Änderung gemeinsam genutzter Infrastruktur

• Irreversibles Zerstören von Dateien, die vor der Sitzung existierten

• Force Push

• Committen oder Pushen einer Änderung, die bei ihrer Ausführung Geheimnisse oder sensible Daten aus dem Repository hinaussenden oder erweitern würde, 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 Setup-Schritt, der einen Geheimnisspeicher liest und die Daten hinaussendet, und eine Konfigurationsänderung, die erweitert, was eine Bereitstellung veröffentlicht, etwa eine Registry-, Sichtbarkeits-, Artefakt- oder Sourcemap-Einstellung. Die Prüfung gilt auf jedem Branch, gilt auch, wenn das Repository öffentlich ist, und greift, wenn die Änderung committet oder gepusht wird, unabhängig davon, ob dieser Commit oder Push die Pipeline auslöst; um sie aufzuheben, muss der Ausführungseffekt benannt werden, nicht nur der Commit oder Push

• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop oder git stash clear, von denen der Klassifikator annimmt, dass sie nicht committete Änderungen verwerfen würden

• 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 reine Umformulierung der Nachricht wird nicht blockiert: --amend -m ohne neu gestagte Änderungen, bei einem Commit, den Claude während dieser Sitzung erstellt hat

• terraform destroy, pulumi destroy, cdk destroy oder terragrunt destroy sowie das Anwenden eines Plans, der Ressourcen zerstört

• Schreiben in einen Secret Manager oder Ändern von DNS-Einträgen oder TLS-Zertifikaten

• Mergen eines Pull Requests, den kein Mensch genehmigt hat, Genehmigen von Claudes eigenem Pull Request oder Deaktivieren von CI-Prüfungen

• Posten eines Kommentars, der selbst ein Befehl an eine Automatisierung ist, wie atlantis apply oder /deploy bzw. /merge eines Bots

• Umschalten, schrittweises Hochfahren oder Löschen eines Produktions-Feature-Flags

• Anwenden von Infrastrukturänderungen auf einen geschützten IaC-Bereich oder Leeren und Entfernen von Cluster-Knoten

• Schreibvorgänge in einen gemeinsam genutzten Compute-Cluster, die über die von Ihnen benannte Ressource hinausgehen, wie ein Label-Selektor oder --all, der Jobs anderer Benutzer erfasst

• Erstellen von Kubernetes-Ressourcen, die auf jedem Knoten laufen oder Cluster-Verkehr 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 Dienst aus dem öffentlichen Internet erreichbar macht

• Ausgeben gültiger Anmeldedaten oder eines Tokens in das Transkript oder eine Datei

• Zugreifen auf einen Ort, der in Ihrer Umgebung als sensibler Datenort aufgeführt ist, Kopieren von Daten daraus oder Senden von Daten daraus an eine Zielgruppe, die der Eintrag ausschließt

• Umleiten einer Paketinstallation an Ihrer internen Paket-Registry vorbei zu einer öffentlichen Registry. Dies gilt, wenn eine interne Registry oder ein Mirror in Ihrer Umgebung aufgeführt ist oder wenn Sie Claude in der Konversation mitgeteilt haben, dass eine solche existiert

• Ausführen eines Befehls mit einem Flag, das einen Sicherheitsschutz deaktiviert, wie --insecure

• Starten einer autonomen Agentenschleife, die ohne menschliche Genehmigung oder Sandbox läuft, etwa einer mit --dangerously-skip-permissions oder --no-sandbox gestarteten. Dies umfasst das Ausführen eines Drittanbieter-Agenten oder Eval-Harness mit deaktivierter Isolation und deaktivierter Genehmigung pro Aktion, etwa eines mit --yes-always gestarteten Runners

• Browser-Aktionen von Claude in Chrome, die Seiteninhalte, Cookies oder Anmeldedaten an einen anderen Origin senden könnten

• Löschen von Dateien in /tmp, $TMPDIR oder einem anderen gemeinsam genutzten Scratch- oder Cache-Verzeichnis per Wildcard, Glob oder Altersfilter statt über einen konkret benannten Pfad

• Einbeziehen sensibler Details in Inhalte, die an andere Personen oder gemeinsam genutzte Systeme gesendet, hochgeladen, veröffentlicht oder geschrieben werden, wenn Ihre eigene Nachricht diese Details für diesen Empfänger nicht autorisiert hat. PR- und Issue-Texte, Commit-Nachrichten und Kommentare zählen als diese Art von ausgehendem Inhalt, wenn das Repository außerhalb der Vertrauensgrenze liegt oder öffentlich ist, einschließlich der eigenen öffentlichen Repositorys Ihrer Organisation; interne Dateipfade, Codenamen, Live-Daten aus API-Antworten wie E-Mails oder Kontokennungen sowie Infrastrukturkennungen zählen als sensible Details. Live-Personendaten aus einer API-Antwort in einem PR- oder Issue-Text, wie eine E-Mail-Adresse, eine Konto- oder Organisationskennung oder eine Nutzungsmetrik, erfordern, dass Sie diese Details und den Empfänger benennen, unabhängig von der Sichtbarkeit oder Vertrauensgrenze des Repositorys

• Senden von Tastenanschlägen an den eigenen tmux-Bereich von Claude Code, um dessen eigene Oberfläche zu steuern, was der Klassifikator so behandelt, als würde Claude seine eigenen Berechtigungen oder seine eigene Aufsicht ändern

• Auskommentieren, Löschen oder erzwungenes Bestehen eines Tests oder einer Assertion, die Sicherheitsverhalten absichert, wie Authentifizierung, Zugriffskontrolle, Eingabevalidierung oder Sandboxing

• Löschen oder Abbauen einer zustandsbehafteten Ressource, die Claude nicht in der Sitzung erstellt hat, wenn keine spezifischere Löschregel greift und Sie diese Ressource nicht benannt haben

• Umleiten 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

• Ändern, wohin Pushes gehen, mit git remote set-url oder git remote add, es sei denn, Sie haben das neue Remote benannt

• Pushen von Geheimnissen oder persönlichen oder anvertrauten Daten in ein Repository, das bekanntermaßen öffentlich ist, oder Pushen von vertraulichem Material dorthin, das nicht zur eigenen Arbeit dieses Repositorys gehört. Der eigene Gegenstand eines Dotfiles-Repositorys ist die einzige Ausnahme für persönliche oder anvertraute Daten, und Inhalte aus einem privaten Repository, die eine beliebige öffentliche Oberfläche erreichen, werden auf die gleiche Weise blockiert. Wenn die Sichtbarkeit eines Repositorys nicht feststeht, blockiert der Klassifikator nicht allein deswegen; er beurteilt den Inhalt stattdessen anhand der anderen Regeln

• Öffnen eines Pull Requests gegen ein anderes Repository oder eine andere Organisation, Forken mit gh repo fork oder Pushen in ein Drittanbieter-Repository, es sei denn, Sie haben dieses externe Ziel benannt

• 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, einen PR- oder Issue-Text, einen Gist oder Paste oder eine Paketveröffentlichung gelangen, es sei denn, Sie haben sowohl die Quelle als auch das Ziel benannt. Sitzungstranskripte und Konversations-Logs, Punkt-Ordner mit Anmeldedaten und Konfiguration wie SSH-Schlüssel, Cloud-Anmeldedaten, Browser-Profile und Shell-Verlauf sowie Exporte von Benutzerdaten zählen alle dazu, und dass das Repository privat ist, hebt die Blockierung nicht auf

• Schreiben in Sitzungstranskripte von Claude Code, also die .jsonl-Verlaufsdateien unter ~/.claude/projects/ oder Ihrem konfigurierten Konfigurationsverzeichnis, ob direkt oder über einen Shell-Befehl. Die Regel umfasst auch die Metadatenzeilen, die Claude Code für seine eigenen Prüfungen an jeden Transkripteintrag anhängt. Das Lesen eines Transkripts wird nicht blockiert

• Ein rekursives erzwungenes Löschen wie rm -rf "$VAR" oder Remove-Item -Recurse -Force $dir, dessen Ziel eine Shell-Variable ist, die nirgendwo in der für den Klassifikator sichtbaren Konversation zugewiesen wird, oder ein Glob, der auf einer solchen Variable aufsetzt. Der Wert stammt nur aus früherer Befehlsausgabe, die der Klassifikator nie erhält, daher kann der Klassifikator das Löschziel nicht anhand der anderen Löschregeln überprüfen. Die Blockierung wird aufgehoben, wenn Sie den genauen zu löschenden Pfad benennen oder wenn Claude das Löschen erneut ausführt und dabei den aufgelösten literalen Pfad in den Befehl schreibt. Löschvorgänge, deren Ziel der Klassifikator auflösen kann, sind nicht betroffen.

  Ein Glob direkt unter der Variable, wie in rm -rf "$VAR"/*, ist stattdessen ein kritischer Pfad. Remove-Item-Ziele, die ein bloßes * sind oder auf /* oder \* enden, erreichen den Klassifikator nie: Claude Code verweigert sie direkt.

Mehrere dieser Kategorien hängen von Umgebungs-Einträgen ab, etwa sensiblen Remote-Zielen und geschützten IaC-Bereichen, die Sie auf konkrete Namen eingrenzen können.

Claude Code v2.1.257 und später blockieren standardmäßig zusätzlich:

• Anfordern von Anmeldedaten vom Instanz-Metadaten-Endpunkt der Cloud, wie 169.254.169.254, oder explizites Authentifizieren eines Cloud-, Cluster- oder Registry-Aufrufs mit dem eigenen Service-Account oder der Knotenidentität der Maschine
• Erreichen eines öffentlichen Hosts auf einem anderen Weg als über eine direkte Anfrage, etwa über einen Tunnel, eine Reverse Shell oder eine Resolver- oder Proxy-Konfiguration, die so umgeschrieben wurde, dass sie nach außen zeigt
• Lesen von Anmeldedaten, die zum Host statt zu Ihrer Aufgabe gehören, wie Knotenzertifikate oder die Container-Registry-Authentifizierung des Knotens
• Verbinden mit oder Scannen von benachbarten Containern, Pods oder VMs, die Claude nicht gestartet hat, oder des Knotens unter dem Container

Wenn Claude Code in einer Umgebung läuft, die 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 standardmäßig zusätzlich:

• Posten oder Schreiben eines Links zu einem öffentlichen Paste-, Diagramm- oder Datenaustauschdienst in einer Nachricht, einem PR- oder Issue-Text, einem Dokument oder an einer anderen Stelle, an der der Link geöffnet oder abgerufen wird, wenn die URL selbst den geteilten Inhalt enthält, es sei denn, Sie haben diesen Dienst benannt

Standardmäßig erlaubt:

• Lokale Dateivorgänge in Ihrem Arbeitsverzeichnis

• Installieren von Abhängigkeiten, die in Ihren Lock-Dateien oder Manifesten deklariert sind

• Lesen von .env und Senden von Anmeldedaten an die zugehörige API

• Nur lesende HTTP-Anfragen

• Pushen zu jedem Branch des Repositorys, in dem Sie arbeiten, einschließlich des Standard-Branchs. Ein anderer als der Standard-Branch, dessen Name ihn als Bereitstellungs- oder Veröffentlichungsziel kennzeichnet, wie production oder gh-pages, ist nicht abgedeckt: Der Klassifikator beurteilt einen Push dorthin für sich.

  Der Inhalt eines Pushs wird weiterhin anhand der anderen Regeln des Klassifikators geprüft, und permissions.deny-Regeln können Push-Befehle wie geschrieben in jedem Modus weiterhin blockieren. Der eigene Branch-Schutz des Remotes gilt weiterhin.

• Löschen genau der Jobs, die Claude früher in derselben Sitzung erstellt hat

• Lesen, Überprüfen oder Schreiben von sicherheitsbezogenem Code, Konfigurationen und Bedrohungsmodellen als Teil Ihrer Aufgabe

• Nachrichten zwischen Agenten, die in derselben Multi-Agent-Sitzung zusammenarbeiten

• Senden von Daten an die vertrauenswürdigen Domains, Buckets und Dienste, die Sie in environment auflisten. Dies umfasst nur den Datenfluss, nicht destruktive oder Anmeldedaten betreffende Operationen auf derselben Infrastruktur

• Navigation von Claude in Chrome zu einer vertrauenswürdigen internen Domain, zu localhost oder zu einer URL, die Sie benannt haben

In einer Sandbox ausgeführte Befehle erhalten standardmäßig keinen Netzwerkzugriff. Claude benennt die Hosts, die ein Befehl benötigt, direkt am Befehl, der Klassifikator überprüft sie zusammen 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 was nicht und was geschieht, wenn ein Befehl auf einen nicht aufgeführten Host zugreift.

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

Pushen zu jedem Branch des Repositorys, in dem Sie arbeiten, und Erstellen eines Pull Requests, der Ihrer Anfrage entspricht, laufen ohne Abfrage, es sei denn, der Push oder Pull Request fällt unter die Blockierliste, etwa Geheimnisse oder sensible Daten, die das Repository verlassen, oder ein Pull Request, der auf ein anderes Repository oder eine andere Organisation abzielt. Um vor diesen Befehlen einen menschlichen Checkpoint zu verlangen und dabei im Auto-Modus zu 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

Solange permissions.blockReadsOutsideWorkingDirectories deaktiviert ist, laufen Dateilesevorgänge mit Ausnahme von Lesezugriffen auf Netzwerkpfade im Auto-Modus ohne Abfrage, einschließlich Lesezugriffen außerhalb der Arbeitsverzeichnisse. Wenn Claude das Read-, Grep- oder Glob-Tool zum ersten Mal auf einen Pfad außerhalb davon anwendet, fragt Claude Code, ob dieser Lesezugriff erlaubt werden soll.

Die Abfrage erscheint nicht in nicht-interaktiven -p-Läufen oder Hintergrundsitzungen; Lesezugriffe laufen dort wie bisher.

Was auch immer Sie antworten, Claude arbeitet weiter:

• Ja, und weiterhin alle Lesezugriffe außerhalb der Arbeitsverzeichnisse erlauben: Der Lesezugriff läuft, spätere Lesezugriffe außerhalb der Arbeitsverzeichnisse laufen wie bisher, und Claude Code speichert Ihre Antwort, damit die Abfrage nicht erneut erscheint
• Nein, und Lesezugriffe außerhalb der Arbeitsverzeichnisse ab jetzt blockieren: Der Lesezugriff wird verweigert, und Claude Code setzt permissions.blockReadsOutsideWorkingDirectories in Ihren Benutzereinstellungen auf true, wodurch die Datei-Tools solche Lesezugriffe in jeder späteren Sitzung und in jedem Berechtigungsmodus 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.
• Nein, und beim nächsten Mal erneut fragen: Der Lesezugriff wird verweigert, und beim nächsten Lesezugriff außerhalb der Arbeitsverzeichnisse wird erneut nachgefragt
• Ja, aber beim nächsten Mal erneut fragen: Der Lesezugriff läuft, nichts wird gespeichert, und beim nächsten Lesezugriff außerhalb der Arbeitsverzeichnisse wird erneut nachgefragt

Grenzen, die Sie in der Konversation angeben

Der Klassifikator behandelt Grenzen, die Sie in der Konversation angeben, als Blockiersignal. Wenn Sie Claude sagen „nicht pushen“ oder „warte mit dem Deployment, bis ich es überprüft habe“, blockiert der Klassifikator passende Aktionen, auch wenn die Standardregeln sie erlauben würden. Eine Grenze bleibt in Kraft, bis Sie sie in einer späteren Nachricht aufheben. Claudes eigene Einschätzung, dass eine Bedingung erfüllt wurde, hebt sie nicht auf.

Grenzen werden nicht als Regeln gespeichert. Der Klassifikator liest sie bei jeder Prüfung erneut aus dem Transkript, daher kann eine Grenze verloren gehen, wenn die Kontextkomprimierung die Nachricht entfernt, in der sie angegeben wurde. Für eine feste Garantie fügen Sie stattdessen eine Deny-Regel hinzu.

Genehmigungen, die Sie in der Konversation angeben

Wenn Sie Claude sagen, dass eine blockierte Aktion erlaubt ist, liest der Klassifikator das als Ihre Genehmigung und kann die Blockierung aufheben. Wie Sie es formuliert haben, entscheidet, ob die Aktion ausgeführt wird und wie weit die Genehmigung reicht:

• Benennen Sie die Aktion und ihre Einzelheiten: Ihre Nachricht muss die Aktion und das konkrete Detail benennen, das sie gefährlich macht, etwa den Branch eines Force Push. Das Verb allein zu nennen, hebt nichts auf, daher lässt „du kannst force-pushen“ die Blockierung bestehen.
• Rechnen Sie damit, dass sie eine Aktion abdeckt: Eine Genehmigung deckt die destruktive Aktion ab, die Sie benannt haben, daher wird eine spätere Aktion erneut blockiert, es sei denn, Sie haben die Genehmigung als dauerhaft erteilt. Um ein wiederkehrendes Muster nicht mehr Aktion für Aktion genehmigen zu müssen, fügen Sie es zu autoMode.allow hinzu.
• Einige Blockierungen bleiben bestehen: Die Rangfolge des Klassifikators legt fest, welche Blockierungen Ihre Genehmigung erreichen kann. Um einen Schritt auszuführen, den sie nicht freigibt, verlassen Sie den Auto-Modus und beantworten Sie die Berechtigungsabfrage.

Wenn der Auto-Modus zurückfällt

Wenn der Auto-Modus die Aktionen Ihrer Sitzung nicht genehmigen kann, hängt das Weitere vom Fall ab:

• Eine blockierte Aktion: Claude Code zeigt eine Benachrichtigung und listet die Aktion in /permissions auf der Registerkarte Recently denied auf, wo Sie r drücken können, um sie mit einer manuellen Genehmigung erneut zu versuchen.
• Wiederholte Blockierungen: Wenn der Klassifikator eine Aktion 3 Mal hintereinander oder insgesamt 20 Mal blockiert, pausiert der Auto-Modus und Claude Code fragt wieder nach. Das Genehmigen der abgefragten Aktion setzt den Auto-Modus fort. Siehe Schwellenwerte für wiederholte Blockierungen für die Zählung der Blockierungen.
• Kein Urteil vom Klassifikator: Wenn eine vom Auto-Modus getrennte Sicherheitsprüfung die Anfrage des Klassifikators selbst ablehnt oder die Antwort des Klassifikators nicht geparst werden kann, verweigert Claude Code die Aktion ohne Benachrichtigung und ohne Eintrag unter Recently denied. Siehe Auto-Modus kann die Sicherheit einer Aktion nicht bestimmen für die Meldung, die jeder Fall zeigt, und was zu tun ist.
• Kein Urteil vom Server: Bei serverseitiger Klassifikatorüberprüfung verweigert Claude Code eine Aktion, für die der Server kein Urteil abgibt, und beendet den Turn nach zehn Antworten in Folge ohne Urteil. Siehe Der Server hat kein Sicherheitsurteil zurückgegeben.
• Ein Moduswechsel während einer Prüfung: Wenn Sie den Berechtigungsmodus wechseln, während eine Klassifikatorprüfung aussteht, verwirft Claude Code ein Urteil, das der neue Modus nicht angefordert hätte. Sie werden stattdessen um Genehmigung gebeten, oder die Aktion wird im dontAsk-Modus automatisch verweigert.

Schwellenwerte für wiederholte Blockierungen

Die Schwellenwerte von 3 Blockierungen hintereinander und 20 Blockierungen insgesamt sind nicht konfigurierbar. Der Gesamtzähler bleibt für die Sitzung bestehen und wird nur zurückgesetzt, wenn sein eigenes Limit einen Fallback auslöst. Claude Code zählt eine Verweigerung für keinen der beiden Schwellenwerte, wenn eine vom Auto-Modus getrennte Sicherheitsprüfung die Anfrage des Klassifikators selbst ablehnt.

Ein nicht-interaktiver -p-Lauf ohne --permission-prompt-tool hat keine Abfrage, auf die er zurückfallen kann. Wenn wiederholte Blockierungen einen Schwellenwert erreichen, wird die Aktion nicht ausgeführt und Claude arbeitet weiter. Claude Code beendet den Lauf nicht.

Wiederholte Blockierungen bedeuten in der Regel, dass dem Klassifikator Kontext über Ihre Infrastruktur fehlt. Verwenden Sie /feedback, um Fehlalarme zu melden, oder lassen Sie einen Administrator vertrauenswürdige Infrastruktur konfigurieren.

Wie der Auto-Modus Aktionen bewertet

Die folgenden Abschnitte behandeln die Reihenfolge, in der Claude Code eine Aktion bewertet, wie der Klassifikator die Arbeit von Subagenten überprüft und was Klassifikatoraufrufe an Kosten und Latenz verursachen.

Wie der Klassifikator Aktionen bewertet

Jede Aktion durchläuft eine feste Entscheidungsreihenfolge. Der erste passende Schritt gewinnt:

1. Aktionen, die Ihren Allow-, Ask- oder Deny-Regeln entsprechen, werden sofort aufgelöst, mit diesen Ausnahmen:
   • Schreibvorgänge in geschützte Pfade werden an den Klassifikator weitergeleitet, auch wenn eine Allow-Regel zutrifft. Wenn der geschützte Pfad die Datei ist, auf die eine per Symlink verknüpfte Einstellungsdatei verweist, kann der Schreibvorgang stattdessen bei Ihnen nachfragen, wie in der Liste der geschützten Pfade beschrieben
   • Keine Allow-Regel genehmigt erkannte rm- und rmdir-Löschvorgänge in kritischen Pfaden
   • MCP-Tools, die mit requiresUserInteraction gekennzeichnet sind, fragen direkt bei Ihnen nach, auch wenn eine Allow-Regel zutrifft, ebenso Konnektor-Tools, die Ihre Organisation auf ask gesetzt hat, in Sitzungen, in denen diese Einstellung Claude Code erreicht
   • Ein Shell-Befehl mit befehlsspezifischen erlaubten Domains wird ebenfalls an den Klassifikator weitergeleitet, auch wenn eine Allow-Regel zutrifft, da eine Regel den Befehl genehmigt, nicht seine Hosts
   • Ask-Regeln, die auf den Inhalt eines Befehls zutreffen, wie z. B. Bash(git push *), greifen auf eine Berechtigungsabfrage zurück
   • Ein Schreibvorgang, den die Symlink-Prüfung zu einem geschützten Pfad auflöst, fragt bei Ihnen nach, wenn der von Claude angeforderte Pfad selbst nicht geschützt ist
   • Ein Lesevorgang von einem Netzwerkpfad fragt bei Ihnen nach, auch wenn eine Allow-Regel zutrifft
2. Nur lesende Aktionen und Dateibearbeitungen in Ihrem Arbeitsverzeichnis werden automatisch genehmigt, mit Ausnahme von Schreibvorgängen in geschützte Pfade und dem ersten Lesevorgang außerhalb der Arbeitsverzeichnisse, bei dem nachgefragt wird
   • In einer Sitzung mit serverseitiger Klassifikatorprüfung warten nur lesende und in der Sandbox ausgeführte Shell-Befehle auf diese Prüfung und werden blockiert, wenn sie dabei gekennzeichnet werden
   • Ein Schreibvorgang innerhalb Ihres Arbeitsverzeichnisses, den die Symlink-Prüfung zu einem Ort außerhalb davon auflöst, fragt bei Ihnen nach
   • Wenn Claude ein von jemand anderem erstelltes Artefakt liest, gelten die in diesem Abschnitt aufgeführten Genehmigungsfälle
   • Ein Lesevorgang von einem Netzwerkpfad fragt bei Ihnen nach
3. Alles andere geht an den Klassifikator, abgesehen von Löschvorgängen in kritischen Pfaden bei deren Standardbehandlung. Die Konnektor-Tools und requiresUserInteraction-MCP-Tools, die in Schritt 1 direkt bei Ihnen nachfragen, erreichen den Klassifikator ebenfalls nie, sodass weder eine von der Organisation geforderte Genehmigung noch ein Zustimmungsschritt automatisch genehmigt wird
4. Wenn der Klassifikator blockiert, erhält Claude den Grund. In den meisten Sitzungen nennt der Grund die Regel, die der Klassifikator zugeordnet hat, wie z. B. [Data Exfiltration], statt eine schriftliche Erklärung zu liefern; siehe Ablehnungen überprüfen

Ein von Ihnen installierter Mod, der tool.check verarbeitet, kann ebenfalls eine Aktion genehmigen. Für die Fälle, in denen seine Genehmigung nicht an Ihren Regeln und Hooks vorbeikommt, siehe Berechtigungen mit Hooks erweitern.

Wie Browser-Aktionen von Claude in Chrome in der VS Code-Erweiterung genehmigt werden, erfahren Sie unter Berechtigungsabfragen in VS Code-Sitzungen.

Beim Wechsel in den Auto-Modus werden breite Allow-Regeln, die beliebige Codeausführung gewähren, verworfen:

• Pauschale Regeln Bash(*) oder PowerShell(*)
• Interpreter mit Wildcard wie Bash(python*)
• Run-Befehle von Paketmanagern
• Agent-Allow-Regeln
• Monitor-Allow-Regeln, weil Claude Code Monitor-Befehle über die Shell ausführt

Enge Regeln wie Bash(npm test) bleiben in Kraft. Claude Code stellt die verworfenen Regeln wieder her, wenn Sie den Auto-Modus verlassen. Vor v2.1.236 ließ Claude Code Monitor-Allow-Regeln im Auto-Modus in Kraft, sodass eine Regel, die das gesamte Tool abdeckte, Monitor-Befehle ohne Klassifikatorüberprüfung genehmigte.

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

In den Klassifikatoranfragen, die Claude Code selbst sendet, sieht der Klassifikator Benutzernachrichten, Tool-Aufrufe außer nur lesenden Abfragen wie Dateilesevorgängen und Suchen sowie Ihren CLAUDE.md-Inhalt. Tool-Ergebnisse werden aus diesen Anfragen entfernt, sodass feindseliger Inhalt in einer Datei oder Webseite den Klassifikator nicht direkt manipulieren kann.

Sie können das Ergebnis eines Aufrufs mit dem classifierContext-Feld eines PostToolUse-Hooks annotieren, das der Klassifikator als von der Anwendung bereitgestellten Kontext liest. Das Feld erfordert Claude Code v2.1.236 oder später.

Eine separate serverseitige Prüfung scannt eingehende Tool-Ergebnisse und kennzeichnet verdächtige Inhalte, bevor Claude sie liest. Mehr darüber, wie diese Ebenen zusammenwirken, erfahren Sie in der Ankündigung des Auto-Modus und im technischen Deep Dive.

Wie der Auto-Modus Subagenten behandelt

Der Klassifikator prüft die Arbeit von Subagenten an drei Punkten:

1. Bevor ein Subagent startet, wird die delegierte Aufgabenbeschreibung bewertet, sodass eine gefährlich aussehende Aufgabe bereits beim Starten blockiert wird.
2. Während der Subagent läuft, durchläuft jede seiner Aktionen dieselbe Entscheidungsreihenfolge wie in der übergeordneten Sitzung, mit denselben Block- und Allow-Regeln. Ein permissionMode im Frontmatter des Subagenten wird ignoriert.
3. Wenn der Subagent fertig ist, überprüft der Klassifikator seine Arbeit und seinen Abschlussbericht, bevor die übergeordnete Sitzung den Bericht liest. Wenn der Klassifikator die Arbeit oder den Bericht des Subagenten kennzeichnet oder eine separate API-Sicherheitsprüfung die Überprüfung ablehnt, wird der Bericht dennoch zugestellt, jedoch mit vorangestellter Sicherheitswarnung. Wenn der Klassifikator für die Überprüfung nicht verfügbar ist, wird der Bericht mit dem Hinweis zugestellt, die Arbeit des Subagenten zu überprüfen, bevor darauf aufgebaut wird.

Kosten und Latenz

Die Klassifikatoranfragen von Claude Code können auf einem anderen Modell als Ihrer /model-Auswahl laufen. Siehe auf welchem Modell sie laufen.

Bei Enterprise-Plänen und bei Konten, die die Claude API, Claude Platform auf AWS, Amazon Bedrock, Google Cloud's Agent Platform oder Microsoft Foundry verwenden, zählen Klassifikatoraufrufe zu Ihrer Token-Nutzung. Jede Prüfung sendet einen Teil des Transkripts plus die ausstehende Aktion und fügt vor der Ausführung einen Roundtrip hinzu. Lesezugriffe und Bearbeitungen im Arbeitsverzeichnis außerhalb geschützter Pfade überspringen den Klassifikator, daher entsteht der Overhead hauptsächlich durch Shell-Befehle und Netzwerkoperationen. Wenn der Server die Aktionen als Teil der Modellanfragen der Sitzung überprüft, gibt es keine separaten Klassifikatoraufrufe, die gezählt werden; siehe Serverseitige Klassifikatorüberprüfung.

Netzwerkzugriff in der Sandbox verursacht keine Klassifikatoranfragen pro Verbindung. Der Klassifikator beurteilt die Hosts, die ein Befehl benennt, zusammen mit dem Befehl in einer einzigen Überprüfung, und Claude Code prüft jede Verbindung anhand der genehmigten Liste, ohne den Klassifikator erneut aufzurufen.

Nur vorab genehmigte Tools mit dontAsk-Modus zulassen

Wenn Sie den dontAsk-Modus einstellen, lehnt Claude Code automatisch jeden Tool-Aufruf ab, bei dem sonst bei Ihnen nachgefragt würde, wobei ein von Ihnen installierter Mod einige dieser Aufrufe dennoch genehmigen kann. Welche Aufrufe ein Mod genehmigen kann, erfahren Sie unter Berechtigungen mit Hooks erweitern.

Claude führt weiterhin Aktionen aus, die im Manual-Modus keine Genehmigung benötigen, wie z. B. Dateilesevorgänge in Ihren Arbeitsverzeichnissen und nur lesende Bash-Befehle. Aktionen, die Ihren permissions.allow-Regeln entsprechen, und Aufrufe, die von einem PreToolUse-Hook genehmigt wurden, werden ebenfalls ausgeführt. 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 bei Ihnen nachzufragen. Es lehnt auch das integrierte AskUserQuestion-Tool ab, selbst wenn Ihre Allow-Regeln damit übereinstimmen, und macht dasselbe mit Konnektor-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.

Eine Allow-Regel oder ein PreToolUse-Hook kann Folgendes nicht genehmigen:

• Erkannte rm- und rmdir-Löschungen auf kritischen Pfaden, wie z. B. rm -rf / und rm -rf ~
• Lesevorgänge von einem Netzwerkpfad

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 Prüfungen mit dem bypassPermissions-Modus überspringen

Der Modus bypassPermissions deaktiviert Berechtigungsabfragen und Sicherheitsprüfungen, sodass Tool-Aufrufe sofort ausgeführt werden, einschließlich Schreibvorgängen in geschützte Pfade.

Auch im Modus bypassPermissions wird bei jeder der Aktionen, die kein Modus automatisch genehmigt, nachgefragt oder die Aktion abgelehnt, wobei Sie jedoch die Abfrage für gefährliche rm-Befehle ausschalten können. Das Lesen eines öffentlichen Artefakts einer anderen Organisation erfordert Ihre Genehmigung, und dieser Modus fragt nicht danach, daher kann Claude ein solches Artefakt nicht lesen. Die Ablehnungen für Remove-Item in PowerShell gelten ebenfalls in diesem Modus.

Zwei Schutzmaßnahmen für sitzungsübergreifende Nachrichten gelten weiterhin in diesem Modus sowie in interaktiven Terminal-Sitzungen im Plan-Modus, in denen die Umgehung von Berechtigungen verfügbar ist:

• Die Genehmigungsabfrage von isolatePeerMachines für Nachrichten an Ihre Sitzungen außerhalb dieses Rechners wird weiterhin angezeigt.
• Wenn kein crossSessionInbound-Wert zutrifft, hält Claude Code eine eingehende Nachricht aus einer anderen Ihrer Sitzungen zur Genehmigung durch Sie zurück und stellt sie nur dann ohne Nachfrage zu, wenn sich die sendende Sitzung als eine Sitzung ausweist, die ebenfalls Berechtigungsabfragen überspringt. Wenn Sie den Berechtigungsmodus verlassen, während Nachrichten zurückgehalten werden, wendet Claude Code die Regeln für eingehende Nachrichten erneut an und stellt alle zurückgehaltenen Nachrichten zu, die diese Regeln nun zulassen.

In interaktiven Terminal-Sitzungen mit verfügbarer Umgehung von Berechtigungen setzt Claude Code außerdem die Sperren des Plan-Modus nicht durch. Claude wird weiterhin angewiesen, ohne Bearbeitungen zu planen, aber eine Dateibearbeitung oder ein Shell-Befehl, den Claude während der Planung versucht, wird ohne Nachfrage ausgeführt. Bei expliziten Ask-Regeln sowie bei erkannten Löschvorgängen mit rm und rmdir, die auf einen kritischen Pfad abzielen, wird weiterhin nachgefragt.

Der Plan-Modus behält seine Sperren überall dort bei, wo Claude Code ohne interaktives Terminal ausgeführt wird, einschließlich nicht interaktiver Ausführungen mit -p, Sitzungen mit dem Agent SDK und Konversationen im Chat-Bereich der VS Code-Erweiterung. Dort macht --allow-dangerously-skip-permissions den Modus bypassPermissions später auswählbar.

[!WARNING]

Verwenden Sie diesen Modus nur in isolierten Umgebungen wie Containern, VMs oder Dev-Containern ohne Internetzugang, in denen Claude Code Ihr Hostsystem nicht beschädigen kann.

Sie können bypassPermissions nicht aus einer Sitzung heraus aktivieren, die Sie ohne diese Option gestartet haben. Aktivieren Sie den Modus beim Start mit permissions.defaultMode: "bypassPermissions" oder mit einem entsprechenden Flag:

claude --permission-mode bypassPermissions

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

Claude Code lehnt bypassPermissions in einer Sitzung ab, die Sie mit --restricted starten. --restricted erfordert Claude Code v2.1.248 oder höher.

Wenn Sie zum ersten Mal eine interaktive Sitzung mit aktiviertem Modus starten, zeigt Claude Code einen Warndialog an, in dem Sie gebeten werden, die Verantwortung für Aktionen zu übernehmen, die ohne Berechtigungsprüfungen ausgeführt werden:

• Wenn Sie zustimmen: Claude Code setzt skipDangerousModePermissionPrompt in ~/.claude/settings.json auf true, sodass spätere Sitzungen den Dialog überspringen. Um den Dialog erneut anzuzeigen, entfernen Sie den Schlüssel aus dieser Datei oder setzen Sie ihn auf false. Die Referenz zu skipDangerousModePermissionPrompt listet die weiteren Einstellungsdateien auf, in denen Sie oder Ihre Organisation ihn festlegen können.
• Wenn Sie ablehnen: Claude Code wird beendet.

Im nicht interaktiven Modus wird kein Dialog angezeigt.

Eine Hintergrundsitzung berücksichtigt Ihre Zustimmung, wenn sie in den Benutzer- oder verwalteten Einstellungen gespeichert ist:

• Ist keine Zustimmung gespeichert, wird claude --bg --permission-mode bypassPermissions abgelehnt. Stimmen Sie dem Dialog zuerst in einer interaktiven Sitzung zu.

• Ist skipDangerousModePermissionPrompt nur in .claude/settings.local.json gesetzt, startet die Hintergrundsitzung, wobei die Umgehungsanfrage ignoriert wird:

  • Wird --allow-dangerously-skip-permissions ignoriert, ist bypassPermissions nicht im Shift+Tab-Zyklus enthalten.
  • Wird --permission-mode bypassPermissions oder --dangerously-skip-permissions ignoriert, startet die Sitzung stattdessen im Manual-Modus.

  Fügen Sie "skipDangerousModePermissionPrompt": true zu ~/.claude/settings.json hinzu und starten Sie dann eine neue Hintergrundsitzung.

Unter Linux und macOS verweigert Claude Code den Start im Modus bypassPermissions, wenn es als root oder unter sudo ausgeführt wird:

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

Diese Prüfung wird innerhalb einer erkannten Sandbox automatisch übersprungen. Um Claude Code autonom in einem Container auszuführen, verwenden Sie die Dev-Container-Konfiguration, die Claude Code als Nicht-root-Benutzer ausführt.

Cloud-Sitzungen berücksichtigen defaultMode: "bypassPermissions" oder "dontAsk" aus Ihren Einstellungsdateien nicht, sodass die eingecheckten Einstellungen eines Repositorys keine Cloud-Sitzung im Modus zur Umgehung von Berechtigungen starten können. Die Einstellung wird stillschweigend ignoriert, und die Sitzung startet stattdessen in dem Berechtigungsmodus, der im Modus-Dropdown angezeigt wird. Unter Berechtigungsmodi wechseln erfahren Sie, welche Modi Cloud-Sitzungen anbieten.

[!WARNING]

bypassPermissions bietet keinen Schutz vor Prompt-Injection oder unbeabsichtigten Aktionen. Für Sicherheitsprüfungen im Hintergrund mit deutlich weniger Berechtigungsabfragen verwenden Sie stattdessen den Auto-Modus. Administratoren können diesen Modus blockieren, indem sie permissions.disableBypassPermissionsMode in den verwalteten Einstellungen auf "disable" setzen.

Umgehung von Berechtigungen in einer Hintergrundsitzung ignoriert

Dieser Hinweis bedeutet, dass die Hintergrundsitzung Ihre Zustimmung zur Warnung zur Umgehung von Berechtigungen nicht in den Benutzer- oder verwalteten Einstellungen gefunden hat und daher die beim Start gestellte Umgehungsanfrage ignoriert hat:

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

Fügen Sie "skipDangerousModePermissionPrompt": true zu ~/.claude/settings.json hinzu und starten Sie dann eine neue Hintergrundsitzung.

claude agents zeigt die Warnung zur Umgehung von Berechtigungen an, die interaktive Sitzungen überspringen

Wenn claude agents die Warnung zur Umgehung von Berechtigungen anzeigt, obwohl Ihre interaktiven Sitzungen sie überspringen, prüfen Sie, ob skipDangerousModePermissionPrompt in .claude/settings.local.json oder in einer --settings-Datei gesetzt ist. Interaktive Sitzungen werten den Schlüssel dort als Ihre Zustimmung zur Warnung, claude agents hingegen nicht. Unabhängig davon, ob Sie ihn dort finden, stimmen Sie der Warnung zu, um den Schlüssel zu ~/.claude/settings.json hinzuzufügen, wo claude agents danach sucht.

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.

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.

In den Modi, die Schreibvorgänge in geschützten Pfaden zum Klassifizierer leiten, fordert ein Schreibvorgang, den die Symlink-Prüfung in einen geschützten Pfad auflöst, Sie auf, wenn der Pfad, den Claude angefordert hat, selbst nicht geschützt ist.

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 Schreibvorgang in den .claude/-Ordner des Projekts oder in ~/.claude/ eine dieser sitzungsbezogenen Optionen an:

• Für den .claude/-Ordner des Projekts: Ja, und Claude darf Dateien in diesem .claude-Ordner des Projekts für diese Sitzung bearbeiten
• Für ~/.claude/: Ja, und Claude darf Dateien in seinem ~/.claude/-Ordner für diese Sitzung bearbeiten

Geschützte Verzeichnisse:

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, mit einigen Ausnahmen, beispielsweise:
  • Die eigenen Git-Worktrees von Claude unter .claude/worktrees/
  • Die eigenen Plandateien der aktuellen Sitzung in ~/.claude/plans/ oder in dem von Ihnen festgelegten plansDirectory
  • Das eigene Scratch-Verzeichnis einer Hintergrundsitzung unter ~/.claude/jobs/<id>/tmp/
  • Markdown-Dateien im Auto-Memory-Verzeichnis des Projekts, beispielsweise ~/.claude/projects/<project>/memory/, in einer Sitzung, die ohne --restricted gestartet wurde
  • Markdown-Dateien in einem Subagenten-Memory-Verzeichnis, beispielsweise .claude/agent-memory/, in einer Sitzung, die ohne --restricted gestartet wurde
• Ein Verzeichnis, das Sie mit --plugin-dir geladen haben, da Claude Code den Code eines Mods von dort aus neu lädt und ausführt, wenn sich eine Datei ändert
• ~/.claude/dev-mods/ oder dev-mods/ in dem Verzeichnis, auf das CLAUDE_CONFIG_DIR verweist, wo Claude die Mods speichert, die es für Sie schreibt

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
• Eine Datei, die Sie beim Start der Sitzung an --settings, --mcp-config oder --agents übergeben haben
• Die Datei, auf die Ihre Benutzer-, Projekt- oder lokale Einstellungsdatei verweist, wenn die Einstellungsdatei selbst ein symbolischer Link ist, beispielsweise in ein Dotfiles-Repository. In den Modi, die Schreibvorgänge in geschützten Pfaden zum Klassifikator leiten, fragt ein Schreibvorgang in diese Datei stattdessen bei Ihnen nach, selbst wenn eine Allow-Regel zutrifft. Ist der eigene Pfad der Datei zugleich der Pfad einer Einstellungsdatei, beispielsweise .claude/settings.json in einem anderen Ordner, wird der Schreibvorgang wie andere Schreibvorgänge in geschützten Pfaden zum Klassifikator geleitet

Kritische Pfade

Kritische Pfade sind die Verzeichnisse, die Claude Code vor rm- und rmdir-Befehlen schützt, wie das Dateisystem-Root, Ihr Home-Verzeichnis und Ihr Arbeitsverzeichnis. Claude Code prüft diese Befehle, bevor sie ausgeführt werden, und keine Allow-Regel genehmigt einen Befehl, dessen Ziel Claude Code als kritischen Pfad erkennt. Die Überprüfung kann einige Befehle übersehen, daher ersetzt sie keine Kontrolle auf Betriebssystemebene wie Sandboxing.

Eine Entfernung eines kritischen Pfads ist ein rm- oder rmdir-Befehl, dessen Ziel Claude Code als kritischen Pfad erkennt. Auch kein PreToolUse-Hook, der "allow" zurückgibt, genehmigt einen solchen Befehl. Eine Allow-Regel oder ein PreToolUse-Hook kann ihn selbst in den Berechtigungsmodi nicht genehmigen, die andere Abfragen überspringen.

[!WARNING]

Ein Befehl, den die Überprüfung übersieht, wird nicht gesondert behandelt, sodass alles, was in Ihrer Sitzung Bash-Befehle genehmigt, ihn ohne Abfrage genehmigen kann. Dazu gehören eine Allow-Regel, der bypassPermissions-Modus und der Auto-Allow-Modus der Sandbox. Die Überprüfung gilt für rm und rmdir, daher können auch andere genehmigte Befehle kritische Pfade löschen.

Diese Kontrollen gelten unabhängig davon, ob die Überprüfung einen Befehl erkennt:

• Deny-Regeln: Eine Deny-Regel, die dem Befehl entspricht, blockiert ihn, wobei ein von Ihnen installierter Mod einige dieser Aufrufe dennoch genehmigen kann
• Sandboxing: Beim Sandboxing begrenzt das Betriebssystem, in welche Pfade Bash-Befehle schreiben können. In einer Sandbox ausgeführte Befehle können Ihr Arbeitsverzeichnis dennoch löschen
• Strikter Sandbox-Modus: Standardmäßig kann ein in einer Sandbox ausgeführter Befehl außerhalb der Sandbox erneut versucht werden, und eine Allow-Regel oder der bypassPermissions-Modus kann diesen Wiederholungsversuch ohne Abfrage genehmigen. Der strikte Sandbox-Modus schaltet den Wiederholungsversuch aus

Was mit einer Entfernung geschieht, die Claude Code erkennt, hängt von Ihrem Berechtigungsmodus ab. Remove-Item und die cmd-Entfernungs-Built-ins haben ihre eigenen Überprüfungen, die in Remove-Item in PowerShell behandelt werden.

Welche Pfade sind kritisch

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

• Das Dateisystem-Root
• Verzeichnisse der obersten Ebene, d. h. alle direkten Unterordner des Root, wie /usr, /etc oder /data
• Ihr Home-Verzeichnis. Unter Windows zählt auch sein 8.3-Kurzname, wie C:\Users\LONGNA~1
• Windows-Laufwerk-Roots und ihre Verzeichnisse der obersten Ebene, wie C:\ und C:\Windows. Schreibweisen wie \\?\C:\ und \\localhost\C$ zählen als C:\
• Ihr Arbeitsverzeichnis und seine übergeordneten Verzeichnisse
• Ihre zusätzlichen Arbeitsverzeichnisse und ihre übergeordneten Verzeichnisse, aber nur wenn die Entfernung ein Glob unter einem von ihnen ist, wie rm -rf <dir>/*. rm -rf <dir> im Verzeichnis selbst löst diese Überprüfung nicht aus

Informationen zu Pfaden eingehängter Laufwerke wie /mnt/c oder /Volumes/USB finden Sie unter Die Abfrage für eingehängte Laufwerke.

Die Überprüfungen des 8.3-Kurznamens des Home-Verzeichnisses sowie der Schreibweisen \\?\C:\ und \\localhost\C$ erfordern Claude Code v2.1.292 oder später.

Andere Ziele, die als kritische Pfade zählen

Claude Code behandelt auch die folgenden rm- und rmdir-Ziele als kritische Pfade. Die letzte Spalte sagt, warum jedes zählt.

Um die Überprüfung auf einem Ziel auszuschalten, das nur Befehlsersetzungsausgabe ist, setzen Sie CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 in der Umgebung, die Claude Code startet.

Entfernungen in verschachtelten Befehlen und Inline-Skripten

Claude Code schaut auch in diese Konstrukte:

• Verschachtelte Befehle: eine Subshell mit (...), eine Brace-Gruppe mit { ...; }, Befehlsersetzung mit $(...) oder Backticks, oder Prozessersetzung mit <(...). Claude Code findet eine Entfernung eines kritischen Pfads, ob sie sich in der verschachtelten Form befindet, wie in (rm -rf ~) oder echo "$(rm -rf ~)", oder anderswo im gleichen Befehl.
• Inline-Skripte: ein Skript, das mit -c an sh, bash, zsh oder eine ähnliche POSIX-Shell übergeben wird, wie in bash -c 'rm -rf ~'.
  • Wenn das Skript in doppelte Anführungszeichen gesetzt ist, erweitert die aufrufende Shell seine Variablen, bevor die innere Shell das Skript erhält. In find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \; erweitert sich der Befehl zu einer Entfernung vom Dateisystem-Root einmal pro Treffer, und Claude Code behandelt es als Entfernung eines kritischen Pfads.
  • Ein einfach angeführtes Skript, das $1 an einen echten Wert bindet, wie sh -c 'rm -rf "$1"/*' _ {} es tut, wird nicht gekennzeichnet.

Um die Überprüfung für einen kritischen Pfad auszuschalten, der direkt in einem -c-Skript eingegeben wird, wie ~, setzen Sie CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 in der Umgebung, die Claude Code startet.

Einen gekennzeichneten Befehl umschreiben

Wie man einen Befehl umschreibt, damit er die Überprüfung besteht, hängt davon ab, welche der anderen Ziele er verwendet:

• Ein Glob oder nachgestellter Schrägstrich unter einer Variable wie $DIR: schützen Sie jede Erweiterung, damit die Shell mit einem Fehler stoppt, wenn die Variable nicht gesetzt oder leer ist, wie in rm -rf "${DIR:?}"/*, oder verwenden Sie einen literalen Pfad. Eine Entfernung, deren Erweiterungen auf diese Weise geschützt sind, besteht diese Überprüfung, daher wird sie im bypassPermissions-Modus ohne Eingabeaufforderung ausgeführt, es sei denn, eine andere kritische Pfad-Überprüfung kennzeichnet sie.
• Ein Glob oder nachgestellter Schrägstrich unter einer Variable, die normalerweise gesetzt ist, wie $HOME: verwenden Sie einen literalen Pfad.
• Eine Variable, die aus einer Verzeichnis-Druck-Ersetzung zugewiesen wird: verwenden Sie einen literalen Pfad. Ein "${D:?}"-Schutz löscht diese Überprüfung nicht, da die Variable nicht leer ist.
• Ein Ziel, das nur Befehlsersetzungsausgabe ist: führen Sie die Ersetzung zuerst selbst aus, dann entfernen Sie die literalen Pfade, die sie ausgibt. Die Eingabeaufforderung teilt Claude mit, dasselbe zu tun.

Für einen Glob oder nachgestellten Schrägstrich unter einer Variable benennt die Eingabeaufforderung den gekennzeichneten rm und sagt, wie man ihn umschreibt, damit die Überprüfung besteht.

Die Abfrage Dangerous rm operation not ruled out

Die vollständige Begründung lautet:

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

Diese Begründung bedeutet, dass die Shell den Befehl möglicherweise anders liest als Claude Code, sodass sich eine Entfernung in einem nicht überprüften Teil befinden könnte, selbst wenn kein rm vorhanden ist. Im auto- oder bypassPermissions-Modus stammt eine Ablehnung mit diesem Satz von derselben Überprüfung:

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

Sie erhalten die Abfrage oder Ablehnung, die eine Entfernung eines kritischen Pfads in Ihrem Berechtigungsmodus erhält, bypassPermissions eingeschlossen, wobei Sie diese Abfrage im bypassPermissions-Modus ausschalten können. Sie können den Befehl nicht mit einer Bash- oder Bash(*)-Allow-Regel, dem Auto-Allow-Modus der Sandbox oder einem PreToolUse-Hook genehmigen, der "allow" zurückgibt. Lesen Sie den Befehl und genehmigen Sie dann die Abfrage oder führen Sie ihn nach einer Ablehnung in Ihrer Shell aus.

Die Abfrage für eingehängte Laufwerke

Die Abfrage für eingehängte Laufwerke erscheint unter macOS, Linux und WSL, wenn ein rekursiver rm auf einen aufgeführten Pfad eines eingehängten Laufwerks abzielt, wie /mnt/c oder /Volumes/USB/build. Ihre Begründung lautet Dangerous rm operation on mounted drive path: <path>. Ein /*-Ziel erhält die Abfrage auch ohne das Rekursiv-Flag, da Claude Code rm /Volumes/USB/build/* als Entfernung von /Volumes/USB/build liest.

Selbst mit einer Allow-Regel für rm behandelt Claude Code den Befehl als Entfernung eines kritischen Pfads: eine Abfrage oder eine Ablehnung, abhängig von Ihrem Berechtigungsmodus. Genehmigen Sie die Abfrage, damit der rm ausgeführt wird, oder schalten Sie die Abfrage aus.

Pfade, die die Abfrage für eingehängte Laufwerke auslösen

Gleichen Sie das Ziel Ihrer rekursiven rm- oder /*-Entfernung mit diesen Pfadformen ab, wobei jeder Platzhalter wie <drive> oder <name> für genau ein Pfadsegment steht:

Bei einem rekursiven oder nicht rekursiven rm auf /Volumes, /media oder /mnt selbst sehen Sie stattdessen die Begründung für kritische Pfade Dangerous rm operation on critical path: <path>.

Ein relatives Ziel wird ab Ihrem Arbeitsverzeichnis gezählt, daher zielt rm -rf build, während Sie in /Volumes/USB arbeiten, auf /Volumes/USB/build ab und löst die Abfrage aus.

Die Abfrage für eingehängte Laufwerke ausschalten

Um die Abfrage für eingehängte Laufwerke nicht mehr zu erhalten, während Abfragen aus anderen Gründen bestehen bleiben, starten Sie Claude Code mit CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 in seiner Umgebung. Setzen Sie die Variable beispielsweise in Ihrer Shell und starten Sie claude von dort aus:

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

In einer so gestarteten Sitzung entfällt die Abfrage für eingehängte Laufwerke für ein ganzes Laufwerk wie /Volumes/USB sowie für die anderen aufgeführten Pfade. Wenn Sie Bash(rm *) erlauben, den Manual-Modus verwenden und in /Volumes/USB arbeiten, wird rm -rf build ohne Abfrage ausgeführt.

Eine Abfrage, die weiterhin Dangerous rm operation on mounted drive path anzeigt, bedeutet, dass die Variable die Sitzung nicht erreicht:

• Variable in einer Einstellungsdatei: Claude Code ignoriert die Variable im env-Block einer Einstellungsdatei, unabhängig von der Art der Einstellungsdatei. Setzen Sie die Variable daher stattdessen dort, wo Sie claude starten
• Sitzung ohne die Variable gestartet: Starten Sie claude erneut aus einer Umgebung, in der die Variable gesetzt ist, da eine laufende Sitzung sie nicht übernimmt

Entfernungen, die bei ausgeschalteter Abfrage für eingehängte Laufwerke weiterhin nachfragen

Im Manual-Modus mit einer Allow-Regel für rm kann ein rm auf einem Pfad eines eingehängten Laufwerks weiterhin eine Abfrage auslösen, ohne die Begründung Dangerous rm operation on mounted drive path:

• Ziel außerhalb Ihrer Arbeitsverzeichnisse: rm -rf /Volumes/USB/other löst eine Abfrage aus, während Sie in /Volumes/USB/project arbeiten. Um diese Abfrage zu vermeiden, fügen Sie der Sitzung ein Verzeichnis hinzu, das das Ziel enthält
• Ziel mit einem *: rm -rf build/* löst eine Abfrage aus. Genehmigen Sie diese Abfrage, um den Befehl auszuführen, oder bitten Sie Claude, jedes Ziel ohne * zu benennen
• Ziel, das ein kritischer Pfad ist: /mnt selbst und Ihr Arbeitsverzeichnis selbst bleiben kritische Pfade, daher löst rm -rf auf einem davon eine Abfrage aus. Genehmigen Sie diese Abfrage, damit der rm ausgeführt wird

Entfernungen kritischer Pfade in jedem Berechtigungsmodus

Was Claude Code mit einer Entfernung eines kritischen Pfads tut, hängt von Ihrem Berechtigungsmodus ab:

Wenn eine explizite Ask-Regel dem Befehl entspricht, fordert Claude Code Sie stattdessen auf, auch im auto-Modus und ohne Zeitlimit. In Modi, die fragen, kann ein PermissionRequest-Hook die Eingabeaufforderung beantworten.

Um diese Entfernungen im bypassPermissions-Modus ohne Abfrage auszuführen, siehe Die Abfrage für Entfernungen kritischer Pfade ausschalten.

Zeitlimits und Ablehnungen in auto- und bypassPermissions-Modi

In auto- und bypassPermissions-Modi zeigt die Terminal-Eingabeaufforderung für eine Entfernung eines kritischen Pfads einen Countdown von zwei Minuten:

• Wenn der Countdown abläuft, bevor Sie antworten, lehnt Claude Code den Befehl ab und teilt Claude mit, was stattdessen zu tun ist, damit eine unbeaufsichtigte Sitzung weiterarbeitet.
• Drücken Sie eine beliebige Taste, während die Eingabeaufforderung offen ist, um den Countdown zu stoppen und die Eingabeaufforderung warten zu lassen, bis Sie antworten.
• Nachdem drei dieser Eingabeaufforderungen in einer Sitzung unbeantwortet ablaufen, zeigt Claude Code sie nicht mehr an und lehnt weitere Entfernungen kritischer Pfade sofort ab. Das Senden einer neuen Nachricht setzt den Zähler zurück.

Das Zeitlimit gilt ab Claude Code v2.1.281, ebenso die Ablehnung im auto-Modus außerhalb des Terminals.

Außerhalb des Terminals erhalten Sie diese Abfrage nicht:

Wo immer die Entfernung abgelehnt wird, können Sie den gesamten Befehl lesen und in Ihrer Shell ausführen.

Um zu ändern, was Sie in jedem Modus erhalten, setzen Sie CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT auf 1:

• bypassPermissions: Die Terminal-Abfrage hat kein Zeitlimit, und das Chat-Panel von VS Code fragt Sie
• auto: Der Klassifikator entscheidet, im Terminal, im Chat-Panel von VS Code, in -p-Ausführungen und in Agent SDK-Sitzungen

Setzen Sie die Variable in der Umgebung, die Claude Code startet, etwa in Ihrer Shell oder in der env-Option des SDK, nicht in einer Einstellungsdatei von Claude Code. Für das Chat-Panel fügen Sie sie zu claudeCode.environmentVariables in der eigenen Benutzer-settings.json von VS Code hinzu und starten dann eine neue Konversation:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

Die Abfrage für Entfernungen kritischer Pfade im bypassPermissions-Modus ausschalten

Um Bash-Befehle rm und rmdir, die auf kritische Pfade abzielen, im bypassPermissions-Modus ohne Abfrage auszuführen, starten Sie Claude Code mit CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 in seiner Umgebung. Dies erfordert Claude Code v2.1.311 oder später. Claude Code liest die Variable nur aus der Startumgebung und ignoriert sie im env-Block einer Einstellungsdatei. Setzen Sie sie beispielsweise in Ihrer Shell und starten Sie claude von dort aus:

macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

Windows PowerShell

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

Wenn diese Variable gesetzt ist, verlieren Sie eine Sicherheitsabfrage für destruktive Löschvorgänge: Ein Befehl wie rm -rf ~ kann ausgeführt werden, ohne Sie zu fragen. Setzen Sie sie nur in einer isolierten Umgebung, deren Inhalt Sie verlieren können.

Entfernungen werden nur im bypassPermissions-Modus selbst ohne Abfrage ausgeführt, nicht im Plan-Modus, und nur für das, was die Überprüfung kritischer Pfade in den Tools Bash und Monitor kennzeichnet. Dazu gehören Befehle, die Claude Code nicht vollständig parsen kann und die ebenfalls ohne Abfrage ausgeführt werden.

Startmeldungen zur Abfrage für Entfernungen kritischer Pfade

Um zu prüfen, ob CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS wirkt, lesen Sie die Zeile, die Claude Code beim Start ausgibt. In einer -p-Ausführung steht sie auf stderr. In einer Agent SDK-App übergeben Sie die stderr-Option, um sie zu lesen. Die Zeile lautet eine der folgenden:

• is set, so dangerous rm commands can run without a prompt: Entfernungen können ohne Abfrage ausgeführt werden, sobald verwaltete Einstellungen und Plugin-Hooks geladen sind. Wenn Entfernungen weiterhin eine Abfrage oder Ablehnung erhalten, siehe Warum die Abfrage für Entfernungen kritischer Pfade aktiv bleibt
• has no effect in this session: Entfernungen behalten ihre übliche Abfrage oder Ablehnung für die gesamte Sitzung. Um das zu ändern, suchen Sie Ihren Fall unter Warum die Abfrage für Entfernungen kritischer Pfade aktiv bleibt
• has no effect while the Windows registry cannot be read for managed settings: Entfernungen behalten ihre übliche Abfrage oder Ablehnung, und die Variable wird ohne Neustart wirksam, wenn ein späteres Lesen der Registry erfolgreich ist. Wenn Entfernungen weiterhin eine Abfrage oder Ablehnung erhalten, siehe Warum die Abfrage für Entfernungen kritischer Pfade aktiv bleibt

Eine fehlende Zeile bedeutet nicht, dass die Abfrage aktiv ist: Eine Agent SDK-App ohne stderr-Option sieht keine Zeile, und Entfernungen können trotzdem ohne Abfrage ausgeführt werden. Prüfen Sie andernfalls, ob Sie die Variable in der Startumgebung gesetzt haben, ob die Sitzung in den bypassPermissions-Modus wechseln kann und ob claude nicht innerhalb einer anderen Sitzung läuft. Einige Sitzungen starten ohne die Variable.

Wenn Sie eine dieser Zeilen sehen und die Variable nicht gesetzt haben, finden Sie heraus, wo sie gesetzt wird, etwa in Ihrem Shell-Profil, und entfernen Sie sie.

Warum die Abfrage für Entfernungen kritischer Pfade aktiv bleibt

Wenn CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS keine Wirkung hat und Entfernungen ihre übliche Abfrage oder Ablehnung behalten, prüfen Sie Ursachen wie diese:

• Etwas anderes verarbeitet Berechtigungsabfragen: ein --permission-prompt-tool oder ein Agent SDK-canUseTool-Callback ohne --permission-prompts none, ein PermissionRequest-Hook mit beliebigem Matcher oder ein Mod, der dieses Ereignis verarbeitet. Entfernen Sie den Hook, den Mod, das Tool oder den Callback und starten Sie claude neu
• Das Chat-Panel der VS Code-Erweiterung oder die Desktop-App führt die Sitzung aus: Starten Sie claude stattdessen in einem Terminal, etwa im integrierten Terminal einer IDE
• Eine Regel betrifft Bash, Edit oder Read: eine Deny- oder Ask-Regel, die auf eines dieser Tools abzielt, beim Start oder sobald Claude Code sie während der Sitzung liest, selbst wenn Sie sie später entfernen. Entfernen Sie die Regel und starten Sie claude neu. Um ein Tool auszuschließen, verwenden Sie --tools statt einer Deny-Regel
• permissions.blockReadsOutsideWorkingDirectories ist aktiviert: Entfernen Sie die Einstellung aus jeder Einstellungsdatei, die sie auf true setzt, und starten Sie dann claude neu
• claude läuft innerhalb einer anderen Sitzung: ein claude, das aus dem Bash-Tool einer Sitzung oder aus einem Hook gestartet wurde, selbst mit der Variable in seiner Befehlszeile. Starten Sie claude aus Ihrer eigenen Shell. Verlassen Sie sich nicht auf diese Einschränkung für verschachtelte Sitzungen als Sicherheitsgrenze
• Ein PreToolUse-Hook antwortet für eine Entfernung mit ask: Ändern Sie, was der Hook zurückgibt
• Claude Code startet die Sitzung für Sie: Hintergrundsitzungen, Teammitglieder eines Agent-Teams in geteilten Bereichen und Sitzungen, die ein Remote Control-Server erstellt, starten ohne die Variable. Starten Sie claude aus Ihrer eigenen Shell
• Verwaltete Einstellungen können nicht gelesen werden: Claude Code hat Ihre Quellen für verwaltete Einstellungen nicht erfolgreich gelesen. Wenn servergesteuerte Einstellungen weiterhin nicht geladen werden, siehe Remote managed settings failed to load. Bei jedem anderen Fehler, der keine Registry-Abfrage betrifft, bitten Sie die Person, die diese Quelle verwaltet, ihn zu beheben
• Die Windows-Registry kann nicht abgefragt werden: Unter Windows und in WSL benötigt die Variable eine Antwort aus der Registry, auch wenn WSL sie nicht für Einstellungen verwendet. Die Abfrage kann die gesamte Sitzung lang fehlschlagen: auf einem nicht englischsprachigen Windows, in WSL mit deaktiviertem Interop oder in einem Container auf einem WSL2-Kernel. Wenn Interop deaktiviert ist, aktivieren Sie es. Andernfalls führen Sie diese Entfernungen selbst aus

Remove-Item in PowerShell

Wenn Sie das PowerShell-Tool aktivieren, gibt Claude Code Remove-Item und den cmd-Built-ins rd, rmdir, del und erase ihre eigenen Überprüfungen, getrennt von der rm-Liste kritischer Pfade. Für Remove-Item hängt das Ergebnis vom Ziel ab, und der erste passende Fall gilt:

• Systempfade: das Dateisystem-Root und seine Verzeichnisse der obersten Ebene, Laufwerk-Roots und ihre Verzeichnisse der obersten Ebene sowie Ihr Home-Verzeichnis. Claude Code lehnt den Befehl in jedem Modus ab, ohne Sie zu fragen.
• Platzhalter: ein bloßes * oder ein beliebiges Ziel, das auf /* oder \* endet, einschließlich eines Globs unter einer Shell-Variable wie $dir/*. Claude Code lehnt den Befehl in jedem Modus ab, 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 in Ihrem Berechtigungsmodus genehmigt werden muss, daher fordert es Sie in Modi auf, die fragen, sendet es in auto-Modus an den Klassifizierer und lehnt es im dontAsk-Modus ab. Der bypassPermissions-Modus überspringt diese Überprüfung.

Der Fall der Systempfade gilt auch für rd, rmdir, del und erase, wenn Claude sie über cmd ausführt, wie in cmd /c rd /s /q C:\Users. Standardmäßig lehnt Claude Code einen solchen Befehl in jedem Modus ab, ohne Sie zu fragen. Diese cmd-Überprüfung erfordert Claude Code v2.1.283 oder später.

Bei der Beurteilung eines cmd-Ziels behandelt Claude Code eine PowerShell-Variable, die auf literalen Text folgt, als leer. Das macht cmd /c rd /s /q "C:\$name" zu einer Entfernung von C:\, daher wird sie auch abgelehnt. Ein nachgestellter Platzhalter zählt als der Ordner, den er leert, daher wird cmd /c del /q C:\* abgelehnt und cmd /c del /q dist\* in Ihrem Projekt nicht.

Um die cmd-Überprüfung auszuschalten, setzen Sie CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 in der Umgebung, die Claude Code startet. Claude Code ignoriert diese Variable in einem env-Block einer Einstellungsdatei. Remove-Item auf einem Systempfad bleibt in jedem Fall abgelehnt.

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