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.

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.

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.

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.

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.

claude --permission-mode plan

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. 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 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 Standard-Berechtigungsmodus. Dort setzen Sie stattdessen claudeCode.initialPermissionMode auf plan in Ihren VS Code-Benutzereinstellungen.

Eliminieren Sie Genehmigungsaufforderungen mit dem Auto-Modus

Der Auto-Modus ermöglicht Claude, ohne routinemäßige Genehmigungsaufforderungen 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 Ask-Regeln erzwingen weiterhin eine Aufforderung.

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 und genehmigt oder blockiert auch 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 Klärungsfragen 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: In 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. Bei 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 verfügbar in der Anthropic API, Claude Platform on 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 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 Klassifizierer-Anfrage fehlgeschlagen ist. Dieser Fehler ist normalerweise vorübergehend, kann aber bei 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

Bei 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: Bei 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-Startgenehmigungsmodus 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 diesen 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 war auch gesetzt. Die Variable wird weiterhin aus Kompatibilitätsgründen akzeptiert und hat ab v2.1.207 keine Auswirkung.

Serverseitige Klassifizierer-Ü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 Modellabfragen der Sitzung, anstatt seine eigenen Klassifizierer-Anfragen zu senden. Diese Sitzungen fragen:

• Eine direkte Verbindung zur Anthropic API: in einer interaktiven Terminal-Sitzung, auf jedem claude.ai-Plan und auf Konten, die die Claude API verwenden, wenn Anthropic dies ausrollt. Erfordert Claude Code v2.1.271 oder später auf Pro-, Max- und Team-Plänen und v2.1.278 oder später auf Enterprise-Plänen und Claude API-Konten. Ab v2.1.282 fragt eine Sitzung, die Feature-Flags nicht abruft, zum Beispiel weil Sie Telemetrie deaktiviert haben, den Server standardmäßig in jeder Art von Sitzung.
• Ein Cloud-Anbieter, oder ein LLM-Gateway oder Proxy: 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, unabhängig von Ihrem Plan. Das standardmäßige Fragen erfordert Claude Code v2.1.278 oder später.
• Eine angemeldete Claude-Apps-Gateway-Sitzung: erfordert Claude Code v2.1.280 oder später

Wo der Server die Aktionen überprüft, entscheiden seine Urteile diese. Zwei andere 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, der die Anfrage zur Überprüfung oder die Ergebnisse blockiert, und eine Plattform, Region oder Anmeldedaten, die noch keine serverseitigen Überprüfungen haben. Claude Code fällt auf seine eigenen Klassifizierer-Anfragen zurück. Sobald dieses Fallback für den Rest der Sitzung gilt, zeigt es eine Mitteilung über Klassifizierer-Anfrage-Gebühren auf Konten, bei denen diese Anfragen abgerechnet werden.
• Der Server gibt kein Urteil für eine Aktion: Claude Code verweigert die Aktion, anstatt sie unüberprü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, der Antworten kürzt oder die Ergebnisse umschreibt, kann beides verursachen. Bei einer direkten Verbindung zur Anthropic API geschieht es auch, wenn die Überprüfung des Servers für die Aktion fehlschlägt, zum Beispiel durch Timeout. Der Server hat kein Sicherheitsurteil zurückgegeben behandelt die Verweigerungsmitteilung, was passiert, wenn Verweigerungen wiederholt werden, und was zu tun ist.

Um das Fragen des Servers zu überspringen und immer Claude Codes eigene Klassifizierer-Anfragen 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. Das Setzen auf 1 dort schaltet die Serverseitige Überprüfung in einer Sitzung ein, die sie noch nicht hat, wie eine -p- oder Agent SDK-Sitzung, 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 gesetzt lassen, stoppt Claude Code auch das Fragen des Servers.

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 Registrierung, Sichtbarkeit, ein Artefakt oder eine 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 eine Überprüfung umgangen wurde, die Sie fragten
• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop oder git stash clear, von denen der Klassifizierer 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 nur-Nachricht-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 für 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-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 Service vom öffentlichen Internet erreichbar macht
• Drucken einer Live-Anmeldedaten oder eines 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 Paketregistrierung zu einer öffentlichen Registrierung. Ab v2.1.198 gilt dies auch, wenn Sie Claude in der Konversation mitgeteilt haben, dass eine interne Registrierung 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-Agenten 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-Nachricht-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-Bereich, um seine eigene Schnittstelle zu steuern, was der Klassifizierer als Claude behandelt, das seine eigenen Berechtigungen oder Aufsicht ä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 Registrierungs-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 eigenes Thema ist die einzige 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 markiert, 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 Literalpfad, 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 Registrierungsaufrufs 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 Container-Registry-Auth des Knotens
• Verbindung zu oder Scannen von Sibling-Containern, Pods oder VMs, die Claude nicht gestartet hat, oder dem Knoten 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 markiert, 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 Agenten, die zusammen in der gleichen Multi-Agent-Sitzung arbeiten
• Senden von Daten an die vertrauenswürdigen Domänen, 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 Domäne, 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 Domänen 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.

Pushen zu jedem Branch des Repositorys, an dem Sie arbeiten, und Erstellen eines Pull Requests, der Ihrer Anfrage entspricht, laufen ohne Aufforderung, 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 Aufforderung im Auto-Modus, 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 Aufforderung 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 Aufforderung nicht wieder 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 „pushe nicht" oder „warte, bis ich überprüfe, bevor ich bereitstelle", blockiert der Klassifizierer 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 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.

Genehmigungen, die Sie in der Konversation angeben

Wenn Sie Claude sagen, dass eine blockierte Aktion erlaubt ist, liest der Klassifizierer das als Ihre Genehmigung und kann den Block löschen. Wie Sie es formuliert haben, entscheidet, ob die Aktion läuft und wie weit die Genehmigung reicht:

• Benennen Sie die Aktion und ihre Besonderheiten: Ihre Nachricht muss die Aktion und das Spezifische benennen, das sie gefährlich macht, wie der Branch eines Force Push. Das Benennen des Verbs allein löscht nichts, daher lässt „Sie können force-pushen" den Block in Kraft.
• Erwarten Sie, dass es eine Aktion abdeckt: Eine Genehmigung umfasst die destruktive Aktion, die Sie benannt haben, daher wird eine spätere Aktion wieder blockiert, es sei denn, Sie haben die Genehmigung als stehend gewährt. Um ein routinemäßiges Muster nicht mehr eine Aktion nach der anderen zu genehmigen, fügen Sie es zu autoMode.allow hinzu.
• Einige Blöcke bleiben in Kraft: Die Vorrangordnung des Klassifizierers legt fest, welche Blöcke Ihre Genehmigung erreichen kann. Um einen Schritt auszuführen, den sie nicht löschen wird, verlassen Sie den Auto-Modus und beantworten Sie die Genehmigungsaufforderung.

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 und listet die Aktion in /permissions unter der Registerkarte Kürzlich verweigert auf, wo Sie r drücken können, um sie mit einer manuellen 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 selbst 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 -p-Lauf ohne ein --permission-prompt-tool hat keine Aufforderung, 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.
• Kein Urteil vom Server: Unter serverseitiger Klassifizierer-Überprüfung verweigert Claude Code eine Aktion, für die der Server kein Urteil gibt, und stoppt die Runde nach zehn Antworten hintereinander ohne Urteil. Siehe Der Server hat kein Sicherheitsurteil zurückgegeben.
• Ein Modusschalter 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.

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) markiert 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 Domänen](/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 Befehlsinhalte abgleichen, wie `Bash(git push *)`, fallen auf eine Genehmigungsaufforderung 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 [dem ersten Lesezugriff außerhalb der Arbeitsverzeichnisse](#first-read-outside-the-working-directories), die Sie auffordern
   * In einer Sitzung mit [serverseitiger Klassifizierer-Überprüfung](#server-side-classifier-review) warten schreibgeschützte und [Sandbox](/docs/de/sandboxing#sandbox-modes)-Shell-Befehle auf diese Überprüfung und werden blockiert, wenn sie diese kennzeichnet
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 abgeglichen hat, 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 abglich, 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 Klassifizierer-Anfragen, 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) annotieren, 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).

claude --permission-mode dontAsk

claude --permission-mode bypassPermissions

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