CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: Setup und Prüfung

Setze CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS auf Entwicklungsrechnern und gemeinsam genutzten CI-Runnern nicht. In Claude Code v2.1.311+ entfernt sie eine bestimmte Löschbestätigung, aber nur in Sitzungen mit bypassPermissions. Nutze sie nur in isolierten Wegwerfumgebungen, in denen der Verlust aller beschreibbaren Dateien akzeptabel ist.

Stand 2026-10-28 beschreibt Anthropic diese Ausnahme als Einstellung der Startumgebung. Sie aktiviert weder den Bypass-Modus noch schaltet sie alle anderen Berechtigungskontrollen ab.

Warum blockiert der gefährliche Modus weiterhin `rm -rf ~`?

Claude Code prüft erkannte Ziele von rm und rmdir getrennt von gewöhnlichen Tool-Freigaben. Das Flag --dangerously-skip-permissions wählt bypassPermissions. Dieser Modus behält die Prüfung kritischer Pfade bei, solange die neue Ausnahme nicht greift.

Eine allow-Regel kann einen erkannten Löschvorgang für einen kritischen Pfad nicht freigeben. Auch ein PreToolUse-Hook mit dem Rückgabewert allow kann das nicht. Standardmäßig fragt das Terminal nach einer Bestätigung und zeigt einen Countdown von zwei Minuten.

Bei einem Aufruf mit -p kann ein Berechtigungswerkzeug, ein SDK-Callback oder ein freigebender PermissionRequest-Hook über den Vorgang entscheiden. Ohne eine dieser Komponenten wird er standardmäßig abgelehnt.

Die Definition kritischer Pfade umfasst:

Die Wurzel des Dateisystems, etwa /.
Direkte Unterverzeichnisse der Wurzel, darunter /usr, /etc und /data.
Dein Home-Verzeichnis, einschließlich seines kurzen Namens im Windows-Format 8.3, etwa C:\Users\LONGNA~1.
Windows-Laufwerkswurzeln und ihre direkten Unterverzeichnisse, etwa C:\ und C:\Windows. Auch Schreibweisen wie \\?\C:\ und \\localhost\C$ zählen dazu.
Dein Arbeitsverzeichnis und dessen übergeordnete Verzeichnisse.
Zusätzliche Arbeitsverzeichnisse und deren übergeordnete Verzeichnisse, aber nur bei einem Glob-Muster innerhalb eines solchen Verzeichnisses, etwa rm -rf <dir>/*.

Das zusätzliche Verzeichnis selbst mit rm -rf <dir> zu löschen, löst diese spezielle Prüfung nicht aus. Eine andere Regel kann trotzdem greifen, etwa wenn das Verzeichnis zugleich direkt unter der Dateisystemwurzel liegt.

Die Prüfung erfasst Befehle, die Claude Code erkennt. Ein übersehener Befehl erhält keinen besonderen Schutz, und andere freigegebene Programme können ebenfalls Dateien löschen. Für PowerShells Remove-Item und Löschbefehle von cmd gelten eigene Prüfungen.

Setze die Variable für eine isolierte Terminalsitzung

Setze die Variable in der Umgebung, die claude startet, und wähle bypassPermissions ausdrücklich. Ein geeigneter Anwendungsfall ist ein automatisierter Job, der absichtlich ein entbehrliches Arbeitsverzeichnis leert.

Verwende eine funktionierende, authentifizierte CLI in Version v2.1.311 oder neuer. Führe diese Prüfungen in Bash unter macOS, Linux oder WSL aus:

claude --version
claude auth status --text

Falls die Authentifizierung fehlschlägt, nutze claude auth login mit deiner freigegebenen Kontokonfiguration. Startet die falsche Binärdatei, folge den Prüfungen für Installation und PATH von Claude Code. Aktualisiere eine ältere Installation, bevor du fortfährst.

Starte die gewünschte Sitzung mit einer temporären Zuweisung in Bash:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

Die Zuweisung gilt für diesen Befehl und seine Kindprozesse. In der aufrufenden Shell bleibt sie nicht bestehen. Du kannst --permission-mode bypassPermissions durch --dangerously-skip-permissions ersetzen.

Starte Claude Code in der isolierten Umgebung nicht als root. Unter Linux und macOS lehnt der Bypass-Modus Starts als root oder über sudo normalerweise ab. Erkannte Sandboxes bilden eine Ausnahme.

Trage diese Variable nicht im env-Block von ~/.claude/settings.json, .claude/settings.json oder .claude/settings.local.json ein. Laut Referenz der Umgebungsvariablen ignoriert Claude Code sie dort. Ein Wechsel in eine andere Einstellungsebene löst das Problem nicht.

Die Ausnahme gilt nur, während die Sitzung tatsächlich bypassPermissions verwendet, nicht in plan. Sie betrifft die Prüfung kritischer Pfade in den Tools Bash und Monitor. Dazu gehören auch Befehle, die diese Prüfung nicht vollständig analysieren kann.

Um eine bereits exportierte Einstellung zu entfernen, beende die betroffene Sitzung und entferne die Zuweisung aus ihrer Startquelle. Führe in deiner Shell unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS aus und starte anschließend eine neue Sitzung.

Prüfe die Startmeldung, ohne etwas zu löschen

Lies die Startmeldung von Claude Code, um zu prüfen, ob die Ausnahme wirksam werden kann. Eine erfolgreiche Modellantwort allein belegt den Berechtigungszustand nicht.

Führe für eine kurze Diagnose in der isolierten Umgebung Folgendes in Bash aus:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

Die CLI-Flags entfernen integrierte Tools aus der verfügbaren Auswahl und sperren MCP-Tools für diese Diagnose. Sie beschränken die Tools, die das Modell aufrufen kann. Hooks beim Start und Erweiterungen werden weiterhin geladen.

Der Befehl fordert eine Antwort READY auf stdout an. Er speichert die Startausgabe von stderr in claude-startup.log, ohne einen Löschvorgang anzufordern.

Die dokumentierten Startmeldungen enthalten eine dieser drei Formulierungen:

Teil der Startmeldung	Bedeutung
`is set, so dangerous rm commands can run without a prompt`	Die Ausnahme kann greifen, sobald verwaltete Einstellungen und Plugin-Hooks geladen sind. Relevante Regeln oder Hooks können sie weiterhin verhindern.
`has no effect in this session`	Die übliche Bestätigung oder Ablehnung bleibt während dieser Sitzung bestehen. Behebe die Ursache und starte neu.
`has no effect while the Windows registry cannot be read for managed settings`	Die üblichen Prüfungen bleiben aktiv, solange die Registry-Abfrage fehlschlägt. Eine spätere erfolgreiche Abfrage kann die Ausnahme ohne Neustart aktivieren.

Übergib in einer Anwendung mit dem Agent SDK die Option stderr, um die Meldung zu erhalten. Eine fehlende Ausgabe beweist nicht, dass die Bestätigung für kritische Pfade aktiv bleibt. Prüfe, ob die Startvariable vererbt wurde, welcher Berechtigungsmodus aktiv ist und ob die Sitzung indirekt gestartet wurde.

Endet die Diagnose vor der Startmeldung, prüfe zuerst den Startfehler. Ein Authentifizierungs- oder Konfigurationsfehler ist von dieser Berechtigungseinstellung getrennt zu betrachten.

Neun Gründe, warum die Variable keine Wirkung hat

Prüfe Version, Startumgebung und aktiven Modus, bevor du andere Einstellungen änderst. Gleiche danach deinen Fall mit den dokumentierten Ausnahmen ab.

Dies sind alternative Ursachen. Behalte Schutzmaßnahmen bei, die dein Team bewusst eingerichtet hat.

Ursache	Prüfung und Vorgehen
1. Eine andere Komponente bearbeitet Berechtigungsanfragen	Prüfe `--permission-prompt-tool` oder einen SDK-Callback `canUseTool` ohne `--permission-prompts none`. Prüfe außerdem jeden `PermissionRequest`-Hook unabhängig vom Matcher sowie Mods, die dieses Ereignis bearbeiten. Entferne einen unbeabsichtigten Handler und starte neu.
2. Die Sitzung läuft in einem grafischen Chatfenster	Das Chatfenster der Erweiterung von VS Code und die Desktop-App wenden diese Ausnahme nicht an. Starte die CLI in deinem eigenen Terminal. Das integrierte Terminal einer IDE eignet sich ebenfalls.
3. Eine `deny`- oder `ask`-Regel betrifft Bash, Edit oder Read	Jede solche Regel deaktiviert die Ausnahme, auch ohne Bezug zum Löschen. Sobald Claude Code die Regel gelesen hat, bleibt die Ausnahme für die ganze Sitzung gesperrt, selbst nach dem Entfernen der Regel. Eine genehmigte Regeländerung erfordert einen Neustart. Um ein Tool wegzulassen, nutze `--tools` statt einer `deny`-Regel.
4. Lesezugriffe außerhalb der Arbeitsverzeichnisse sind gesperrt	Prüfe `permissions.blockReadsOutsideWorkingDirectories`. Wenn du diesen Schutz bewusst deaktivieren möchtest, entferne alle Einträge, die diesen Schlüssel auf `true` setzen, und starte neu.
5. Claude Code wurde innerhalb einer anderen Sitzung gestartet	Ein Start über das Bash-Tool oder einen Hook einer Sitzung behält die üblichen Prüfungen bei. Das gilt auch bei einer Variablenzuweisung in der Befehlszeile. Starte aus deiner eigenen Shell. Diese Beschränkung verschachtelter Sitzungen ist keine Sicherheitsgrenze.
6. Ein `PreToolUse`-Hook gibt `ask` zurück	Prüfe die Entscheidung des Hooks für den Löschvorgang. Korrigiere eine unbeabsichtigte Antwort `ask`. Eine Antwort `allow` allein kann die gewöhnliche Prüfung kritischer Pfade nicht umgehen.
7. Claude Code hat die Sitzung erstellt	Von Claude Code erstellte Hintergrundsitzungen starten ohne die Variable. Das gilt auch für Teamagenten in geteilten Ansichten und Sitzungen, die ein Remote Control-Server erstellt. Wenn du die Ausnahme benötigst, starte die Sitzung direkt im Terminal.
8. Verwaltete Einstellungen wurden nicht erfolgreich geladen	Bitte die Administration, die fehlerhafte Einstellungsquelle zu reparieren. Untersuche mit `claude doctor`, warum serverseitig verwaltete Einstellungen nicht abgerufen werden können. Für fehlgeschlagene Registry-Abfragen gilt das Verhalten der nächsten Zeile.
9. Die Abfrage der Windows-Registry schlägt fehl	Das betrifft Windows und WSL, auch wenn WSL keine Registry-Einstellungen verwendet. Mögliche Ursachen sind deaktivierte Interoperabilität, Windows in einer anderen Sprache als Englisch oder ein Container auf einem WSL2-Kernel. Aktiviere die Interoperabilität nur, wenn dies erlaubt ist. Andernfalls führe die vorgesehene Bereinigung selbst aus.

Prüfe nach einer genehmigten Änderung erneut die Startmeldung. Verhält sich ein Windows-Hook unerwartet, nutze zuerst die Prüfungen für die aktive Binärdatei und Windows-Hooks, bevor du die Berechtigungsrichtlinie änderst.

Prüfe Startquellen und setze Teamrichtlinien durch

Prüfe sowohl Konfigurationsdateien als auch die Umgebung des Prozesses, der Claude Code startet. Eine Suche ohne Treffer im Repository zeigt nicht, welche Variablen ein gehosteter CI-Dienst einfügt.

Finde dauerhafte Zuweisungen und blockiere sie in CI

Durchsuche das Repository und übliche Shell-Profile, ohne Dateiinhalte auszugeben. Dieses Bash-Beispiel benötigt ripgrep und gibt nur die Namen von Dateien mit Treffern aus:

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

Prüfe Treffer vor einer Änderung. Eine Erwähnung in einem Dokument ist noch kein aktiver Export. Suche auch in nachgeladenen Profildateien, Startskripten, Containerdefinitionen und Umgebungsdateien.

Prüfe CI-Variablen auf Organisations-, Repository-, Umgebungs- und Jobebene. Kontrolliere die Umgebung des Runner-Dienstes und jeden Schritt, der vor dem Start von Claude Code Variablen verändert. Schreibe nicht die gesamte Umgebung in Logs.

Platziere diese Bash-Prüfung in einem kontrollierten CI-Startskript unmittelbar vor dem Aufruf von Claude Code:

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

Die Prüfung lehnt jede vorhandene Zuweisung ab, auch einen leeren Wert oder 0. Das ist eine bewusst strenge Richtlinie des Startskripts. Es bedeutet nicht, dass jeder Wert die Funktion aktiviert. Geschützt sind nur Aufrufe, die diese Prüfung tatsächlich durchlaufen.

Sperre den Bypass-Modus über verwaltete Einstellungen

Sperre den Bypass-Modus, wenn dein Team ihn nicht benötigt. Da die Ausnahme diesen Modus voraussetzt, entfällt damit ihre Grundlage. Ein env-Block in verwalteten Einstellungen kann die nur beim Start gelesene Variable nicht neutralisieren.

Ergänze die aktiven verwalteten Einstellungen deiner Organisation um diesen Eintrag:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Wenn du die Richtlinie als Datei verteilst, nutze diese Pfade:

macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux und WSL: /etc/claude-code/managed-settings.json
Windows: C:\Program Files\ClaudeCode\managed-settings.json

Starte Claude Code neu und rufe /status auf. Prüfe, ob Setting sources die vorgesehene verwaltete Quelle nennt. Ein erneuter Versuch, bypassPermissions zu aktivieren, sollte abgelehnt werden.

Prüfe vor dem Rollout die ausgewählte Quelle. Eine verwaltete Quelle mit höherer Priorität kann die verteilte Datei verdrängen. Schütze die Richtlinie über die Geräteverwaltung. Personen mit lokalen Administratorrechten können eine dateibasierte Richtlinie bearbeiten.

Was schützt zuverlässiger: `deny`-Regeln oder eine Sandbox?

Nutze Isolation durch das Betriebssystem, um den Zugriff auf das Dateisystem zu begrenzen. Berechtigungsregeln steuern einzelne Tool-Aufrufe. Die Bestätigung für kritische Pfade ist eine zusätzliche Prüfung, kein vollständiger Dateisystemschutz.

Behalte nützliche deny-Regeln bei. Allerdings vergleichen Bash-Regeln den Befehlstext. Bash(rm *) erfasst nicht jede Aufrufform oder andere Programme, die Dateien löschen. Prüfe auch installierte Hooks und Mods, da Erweiterungen Berechtigungsentscheidungen beeinflussen können.

Ergänze auf unterstützten macOS-, Linux- und WSL2-Systemen die verwaltete Richtlinie um diese Sandbox-Einstellungen:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Diese Konfiguration verhindert den Start, wenn die Sandbox nicht verfügbar ist, und deaktiviert Wiederholungsversuche außerhalb der Sandbox. Natives Windows unterstützt diese Sandbox nicht. Die Richtlinie würde dort deshalb den Start verhindern.

Prüfe mit /sandbox die wirksame Konfiguration und die Abhängigkeiten. Kontrolliere excludedCommands und beschreibbare Pfade. Der strikte Modus lässt weiterhin Ausnahmen zu. Benutzereinstellungen oder --settings können manche Listen erweitern.

Auch Befehle in der Sandbox können beschreibbare Projektdaten löschen. Die integrierte Grenze erfasst zudem nicht jeden Hook, lokal gestarteten MCP-Server oder jedes Dateitool. Für unbeaufsichtigte Arbeit mit umfassenderen Anforderungen isoliere den gesamten Prozess von Claude Code in einem Container, einer VM oder einer Sandbox-Laufzeit. Binde wertvolle Host-Pfade nicht schreibbar ein. Die Arbeitskopie muss sich ersetzen lassen.

Warum blockiert der gefährliche Modus weiterhin rm -rf ~?