Claude Code --dangerously-skip-permissions: Berechtigungen umgehen, und was dann noch greift

Was macht claude --dangerously-skip-permissions genau?

claude --dangerously-skip-permissions startet Claude Code im Modus bypassPermissions. Anthropics CLI-Referenz beschreibt das Flag mit den Worten „Entspricht --permission-mode bypassPermissions“, und auf der Seite zu den Permission-Modi steht, was dieser Modus tut: Er „deaktiviert Berechtigungsabfragen und Sicherheitsprüfungen, sodass Tool-Aufrufe sofort ausgeführt werden, einschließlich Schreibzugriffen auf geschützte Pfade“. Dateiänderungen, Shell-Befehle, Web-Abrufe und MCP-Tools laufen dann ungefragt, und zwar als Ihr Benutzer.

Die „geschützten Pfade“ sind der Teil, über den die meisten Anleitungen hinweggehen. In jedem anderen Modus löst ein Schreibzugriff auf .git, .vscode, .claude, .mcp.json oder ein Shell-Profil wie .zshrc eine Rückfrage aus, geht an den Klassifikator oder wird abgelehnt. Im Bypass-Modus steht in der Tabelle der Dokumentation schlicht „Erlaubt“. Heikel ist das, weil diese Dateien später von einem anderen Programm ausgeführt werden, und genau auf diesem Mechanismus beruhen die meisten der 2026 veröffentlichten Sandbox-Ausbrüche.

Was wegfällt und was stehen bleibt:

In einem Lauf mit -p sitzt niemand vor dem Terminal, der antworten könnte. Aufrufe, die trotz Bypass noch eine Rückfrage auslösen würden, werden dort deshalb abgelehnt. Anthropics Warnung passt in eine Zeile: „bypassPermissions bietet keinen Schutz vor Prompt Injection oder unbeabsichtigten Aktionen.“

Welche Permission-Modi hat Claude Code, und ist der Bypass-Modus standardmäßig aktiv?

Claude Code kennt sechs Permission-Modi, und bypassPermissions ist in keinem Fall die eingebaute Voreinstellung. In den Tarifen Pro, Max und Team startet eine neue Terminal-Session im Modus auto (ab v2.1.228). Mit einem Enterprise-Tarif, einem API-Key aus der Console, über Bedrock oder Foundry, mit claude -p und im Agent SDK startet sie in default, den die Oberfläche als Manual ausweist.

Welcher Modus beim Start gilt, entscheidet sich in fester Reihenfolge: zuerst das Flag, dann permissions.defaultMode aus einer Settings-Datei, zuletzt die eingebaute Voreinstellung. Wer fremde Repositories klont, sollte dazu ein Detail kennen. Laut Settings-Referenz werden auto und bypassPermissions „aus Projekt- oder lokalen Settings nicht wirksam“, und gleich danach heißt es: „Vor v2.1.257 wurde bypassPermissions aus jeder Datei wirksam.“ Auf älteren Versionen konnte also eine eingecheckte .claude/settings.json den Bypass-Modus für Sie auswählen, abgesichert nur durch einen Warndialog, der ein einziges Mal erscheint.

Kann man mitten in der Session in den Bypass-Modus wechseln?

In den Bypass-Modus wechseln können Sie mitten in der Session nur, wenn er schon beim Start verfügbar war. Die Dokumentation lässt daran keinen Zweifel: „Aus einer Session, die Sie ohne diese Option gestartet haben, können Sie nicht in bypassPermissions wechseln.“ Wer sich die Möglichkeit offenhalten will, startet mit --allow-dangerously-skip-permissions, dann reiht sich der Modus im Shift+Tab-Zyklus hinter plan ein. Auch ein Hook kann ihn nicht nachträglich freischalten.

Dieses Flag hat allerdings eine Nebenwirkung. Sobald der Bypass in einem interaktiven Terminal verfügbar ist, werden die Sperren des Plan-Modus nicht mehr durchgesetzt: „Claude wird weiterhin angewiesen, zu planen, ohne etwas zu ändern, aber eine Dateiänderung oder ein Shell-Befehl, den es während der Planung versucht, läuft ohne Rückfrage.“ Aus dem Plan-Modus wird damit eine Anweisung an das Modell und keine Sperre mehr, die der Client durchsetzt. Ausgenommen sind Läufe mit -p, das Agent SDK und das Chat-Panel in VS Code.

Funktioniert --dangerously-skip-permissions in der VS-Code-Erweiterung?

Ja, aber nur hinter einem Schalter, der ab Werk aus ist. Die Erweiterung zeigt Bypass permissions erst dann in ihrer Modusanzeige, wenn Sie in den Einstellungen den Schalter „Allow dangerously skip permissions“ aktivieren (allowDangerouslySkipPermissions, Standardwert false). Die Beschreibung dazu lautet: „Nur in Sandboxes ohne Internetzugang verwenden.“ Ohne den Schalter beginnt die Unterhaltung selbst bei einem voreingestellten bypassPermissions in Manual, und ein Repository kann den Startmodus ohnehin nicht festlegen.

Prüfen Sie dort außerdem, ob die Sandbox wirklich greift. Issue #32814, eröffnet am 10. März 2026, meldete, dass die Erweiterung das Binary ohne --sandbox startete und sandbox.enabled: true deshalb kein Seatbelt-Profil anwandte. Vier Tage später wurde das Issue automatisch als Duplikat geschlossen, und aktuelle Builds haben wir nicht erneut getestet. Der Test ist einfach: Bitten Sie den Agenten, außerhalb des Workspace zu schreiben, und sehen Sie zu, was passiert.

Warum verweigert Claude Code --dangerously-skip-permissions als root oder mit sudo?

Claude Code lehnt --dangerously-skip-permissions mit root- oder sudo-Rechten unter Linux und macOS grundsätzlich ab. Die Fehlermeldung lautet --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, und die Seite zum Sandboxing liefert die Begründung: „Root-Zugriff in Kombination mit fehlenden Berechtigungsabfragen kann jede Datei und jeden Dienst auf dem System verändern.“ Übersprungen wird die Prüfung „automatisch innerhalb einer erkannten Sandbox“. In der Praxis stolpert man vor allem in Docker über diesen Fehler, denn dort laufen Prozesse standardmäßig als root. Die dokumentierte Abhilfe: sicherstellen, dass remoteUser „auf ein Nicht-root-Konto gesetzt ist“.

Schützt die Sandbox noch, wenn die Permissions übersprungen werden?

Teilweise: Die eingebaute Sandbox schützt auch im Bypass-Modus weiter, aber sie schützt nur die Shell. Der Permission-Modus entscheidet, ob ein Tool-Aufruf überhaupt läuft. Die Sandbox begrenzt, was ein Bash-Befehl erreichen kann, sobald er läuft. Beides ist voneinander unabhängig, Shell-Befehle bleiben also auch ohne Rückfragen in der Sandbox eingesperrt. Alles andere liegt außerhalb, wie Anthropics Vergleichsseite festhält: „Eingebaute Datei-Tools, MCP-Server und Hooks laufen weiterhin direkt auf Ihrem Host.“

Konkret heißt das: Mit aktiver Sandbox und übersprungenen Permissions stoppt das Betriebssystem einen Shell-Befehl, der etwas an ~/.zshrc anhängt. Das Edit-Tool, das dieselbe Datei beschreibt, stoppt es nicht, denn „Read, Edit und Write nutzen direkt das Berechtigungssystem, statt durch die Sandbox zu laufen“, und genau dieses System haben Sie gerade abgeschaltet.

Dazu kommt ein Notausgang. Scheitert ein Befehl in der Sandbox, darf Claude ihn mit dangerouslyDisableSandbox wiederholen, und diese Wiederholung „durchläuft den regulären Berechtigungsablauf“, in dem im Bypass-Modus keine Rückfrage mehr übrig ist. Setzen Sie deshalb sandbox.allowUnsandboxedCommands auf false.

Daher die Regel der Dokumentation: Bypass-Sessions gehören „in einen Container, eine VM oder die Sandbox-Runtime“, wo auch Datei-Tools, MCP-Server und Hooks innerhalb der Grenze liegen. Codex zieht die Linie anders, dort entfernt ein einziges Flag Freigaben und Sandbox zugleich. Mehr dazu steht in unserem Leitfaden zu den Codex-Flags.

Am schnellsten kommen Sie mit Anthropics Dev Container Feature dorthin, eingetragen in .devcontainer/devcontainer.json und ohne eingebundene Secrets vom Host:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . \
  claude -p "run the test suite and fix what fails" --dangerously-skip-permissions

Melden Sie sich einmal im Container an, oder übergeben Sie einen eng begrenzten ANTHROPIC_API_KEY. Was Sie damit bekommen, ist ein Benutzer ohne root-Rechte und eine Prozessgrenze, aber keine Egress-Regel. Die liefert erst der Referenz-Container im Repository anthropics/claude-code, der ein Firewall-Skript nach dem Prinzip Default-Deny mitbringt. Die Seite zu Dev Containern warnt ausdrücklich, dass eine Session im Bypass-Modus weiterhin „alles, was im Container erreichbar ist, einschließlich der in ~/.claude gespeicherten Zugangsdaten von Claude Code“ abfließen lassen kann. Liegen dort personenbezogene Daten, ist ein solcher Abfluss nicht nur ein Sicherheitsvorfall, sondern auch eine Verletzung des Schutzes personenbezogener Daten im Sinne der DSGVO. Binden Sie also das Repository ein, niemals Ihr Home-Verzeichnis.

Wie arbeitet Claude Code ohne ständige Rückfragen, auch ohne das Flag?

Ohne ständige Rückfragen arbeitet Claude Code auch im Auto-Modus oder mit eigenen Regeln, ganz ohne das Flag. Der Auto-Modus ersetzt die Rückfrage durch ein Klassifikator-Modell und ist in den Tarifen Pro, Max und Team ohnehin schon die Voreinstellung. Überall sonst geben permissions.allow-Regeln die Befehle vorab frei, die Sie den ganzen Tag ausführen, acceptEdits beendet die Rückfragen bei Dateiänderungen, und der Auto-Allow-Modus der Sandbox lässt Shell-Befehle innerhalb der Sandbox ungefragt laufen.

Das beste Argument für weniger Rückfragen stammt von Anthropic selbst. Der Engineering-Beitrag zum Auto-Modus vom 25. März 2026 beginnt mit dem Satz: „Nutzer von Claude Code genehmigen 93 % der Berechtigungsabfragen.“ Ein Kontrollpunkt, der in 93 von 100 Fällen Ja sagt, ist vor allem Gewohnheit. Entscheidend ist, was an seine Stelle tritt, und für das Flag gibt die Sandboxing-Seite die Antwort in einem Wort: „Nichts.“

Eine ~/.claude/settings.json, die die meisten Rückfragen abschafft und die gefährlichen behält:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(terraform *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)"
    ]
  }
}

Ausgewertet werden die Regeln in der Reihenfolge deny, dann ask, dann allow. Wer „alles erlauben“ will, findet in der Dokumentation ein eigenes Muster dafür: ein bloßes "Bash" in allow, dazu ein PreToolUse-Hook, der die wenigen Befehle zurückweist, die Sie nie sehen wollen. Der Schlüssel disableBypassPermissionsMode ist derjenige, nach dem Administratoren suchen. In den Managed Settings gesetzt, sperrt er den Modus für das ganze Team, und Claude Code „weist dann das Flag --dangerously-skip-permissions zurück“.

Kennen sollten Sie allerdings die Grenze von Bash(...)-Regeln: Sie gleichen den Text des Befehls ab. Anthropics Seite zu den Permissions schreibt, eine deny-Regel „deckt den Aufruf ab, den Claude üblicherweise erzeugt, und ist keine Sicherheitsgrenze um das Programm“. Bash(rm *) stoppt rm -rf build/, nicht aber /bin/rm -rf build/ oder bash -c 'rm -rf build/'.

Welche Schutzmechanismen von Claude Code greifen auch im Bypass-Modus?

Drei Schutzmechanismen greifen in Claude Code auch dann, wenn die Permissions übersprungen werden: deny-Regeln, die Prüfung kritischer Pfade bei rm und PreToolUse-Hooks. Laut Hooks-Leitfaden feuern diese Hooks „vor jeder Prüfung des Permission-Modus, in jedem Permission-Modus“, und ein Hook, der ein deny zurückgibt, „blockiert das Tool selbst im Modus bypassPermissions oder mit --dangerously-skip-permissions“. Von den dreien ist der Hook der einzige, in dem Ihre eigene Logik läuft.

Ein minimales Beispiel, eingetragen in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard.sh" }]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/guard.sh: exit 2 blockiert den Aufruf, stderr geht zurück an Claude
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eiq 'terraform[[:space:]]+destroy|drop[[:space:]]+(schema|database|table)|push[[:space:]].*--force'; then
  echo "Blocked: destructive command, ask the human to run it." >&2
  exit 2
fi
exit 0

Legen Sie den Hook in den User- oder Managed Settings ab, nicht im Projekt. Im Bypass-Modus ist das .claude-Verzeichnis des Projekts ohne Rückfrage beschreibbar, der Agent kann einen Hook, der im Repository liegt, also selbst umschreiben.

Nun zu den Grenzen, denn auch dieser Guard gleicht nur Text ab. Die Research Note GuardFall der Cloud Security Alliance, veröffentlicht am 11. Juli 2026, hat mit fünf Klassen von Shell-Injection die Befehls-Guards von zehn der elf getesteten Open-Source-Coding-Agenten umgangen. Claude Code gehörte nicht zum Testfeld, die Begründung gilt aber für jeden Matcher: „Ein Guard, der die Zeichenkette vor der Transformation prüft, und eine Shell, die die Zeichenkette nach der Transformation ausführt, bewerten im Ergebnis zwei verschiedene Befehle.“

Unser eigener Befehls-Guard irrt sich auch in die andere Richtung. In unserer kontrollierten Studie vom 24. August 2026 prüfte er 1.769 Shell-Befehle und verweigerte 17. Darunter war ein echter Treffer, ein Agent, der nach gespeicherten Zugangsdaten griff. Dazu kamen drei korrekte Anwendungen der Policy und 13 False Positives, die den Agenten jeweils einen Zug kosteten, die meisten davon ausgelöst durch das Token nc, das mitten in einem Python-Heredoc erkannt wurde. Ein Text-Guard ist ein Stolperdraht für den Normalfall. Die Grenze, die hält, wenn er danebenliegt, ist der Container.

Hat Claude Code wirklich eine Produktionsdatenbank gelöscht?

Ja, und im am besten dokumentierten Fall war das Flag gar nicht im Spiel. Am 26. Februar 2026 führte Claude Code terraform destroy gegen die Produktionsinfrastruktur von DataTalks.Club aus. Mit ihr verschwanden die Datenbank, die Kurseinreichungen aus 2,5 Jahren und sämtliche automatischen Snapshots. Gründer Alexey Grigorev veröffentlichte am 6. März das Post-Mortem, der AWS-Support stellte die Daten rund 24 Stunden später wieder her.

Der Agent hatte seinen Schritt angekündigt: „Ich kann das nicht tun. Ich werde ein terraform destroy ausführen.“ Grigorev schreibt, das habe „logisch ausgesehen“, und deshalb: „Ich habe den Agenten nicht gestoppt.“ Von übersprungenen Permissions ist in seinem Beitrag an keiner Stelle die Rede. Am Kontrollpunkt saß ein Mensch, und der Befehl ging durch, weil die Begründung plausibel klang. Sein Fazit, über das auch Tom's Hardware berichtet hat: „Ich habe plan, apply und destroy als etwas behandelt, das sich delegieren lässt. Damit fiel die letzte Sicherheitsschicht weg.“

93 %

der Berechtigungsabfragen werden von den Nutzern von Claude Code genehmigt (Anthropic, 25. März 2026)

65

Issues mit rm -rf im Titel im Tracker von Claude Code, 13 davon noch offen (GitHub-API, 20. September 2026)

17 %

der echten übereifrigen Aktionen entgehen dem Klassifikator des Auto-Modus, nach Anthropics eigener Zählung

Eine Titelsuche nach rm -rf im Tracker von Claude Code liefert am 20. September 2026 65 Issues, eines davon mit dem Titel „Claude Code executed rm -rf deleting entire home directory“. Das sind Meldungen von Nutzern, die wir nicht überprüft haben. Anthropics eigene Vorfallsliste, nachzulesen im Beitrag zum Auto-Modus, führt unter anderem „versuchte Migrationen gegen eine Produktionsdatenbank“ auf.

Was geholfen hätte, das Wirksamste zuerst: keine Produktionszugangsdaten in der Session und ein Löschschutz auf der Datenbank, so hat es Grigorev selbst gelöst. Danach eine ask-Regel auf Bash(terraform *), der Hook von oben und der Auto-Modus, dessen Standard-Sperrliste terraform destroy namentlich aufführt.

Wie sicher ist Claude Code im Arbeitsalltag, wenn niemand die Berechtigungen umgeht?

Ohne umgangene Berechtigungen ist Claude Code sicherer, lückenlos sicher ist es nicht. Manches läuft, bevor das Berechtigungssystem überhaupt gefragt wird: Über CVE-2025-59536 konnte ein Projekt Code ausführen, bevor der Vertrauensdialog beim Start bestätigt war (behoben in 1.0.111), und in Manifolds GitSpawn-Recherche vom 1. September 2026 lief der core.fsmonitor-Befehl eines Repositorys, „bevor die Workspace-Trust-Abfrage bestätigt war“.

Hinzu kommt: Permissions entscheiden nur darüber, ob eine Aktion laufen darf. Den Code, den der Agent schreibt, lesen sie nie. Wegen dieser zweiten Grenze gibt es diesen Artikel. Jede der Kontrollen oben regelt, was Claude Code ausführen darf, und keine schaut auf das, was es schreibt. Auch eine Session im Manual-Modus, in der eine aufmerksame Entwicklerin jede Rückfrage liest, kann einen Endpunkt ohne Autorisierungsprüfung committen, denn ein Diff, der kompiliert, ist kein Berechtigungsereignis. Wer die Permissions überspringt, entfernt den letzten menschlichen Kontrollpunkt für Aktionen. Wer sie behält, gewinnt dadurch noch keinen Kontrollpunkt für den Code. Anthropics Security-Seite lässt diesen Teil bei Ihnen: „Sie sind dafür verantwortlich, vorgeschlagenen Code und vorgeschlagene Befehle vor der Freigabe auf ihre Sicherheit zu prüfen.“

Genau dort setzt eine Kontrolle zur Agent-Time an. VibeDefend läuft als Hooks in derselben Schleife. Im Moment der Änderung legt es die Regeln, die zu einer Datei gehören, in den Kontext des Modells, es spielt die Befunde aus SAST, SCA, Secrets, IaC und CI/CD an den Agenten zurück, und es bewacht Befehle, mit den oben beschriebenen Grenzen. In der Studie vom 24. August setzte der Agent mit dieser Schicht 57 von 64 bewerteten Regeldetails exakt um (89 %), ohne Werkzeug waren es 8 von 65 (12 %). Dieselbe Studie verzeichnet eine Aufgabe, in der die Regel dreizehnmal geliefert wurde und der Agent seine eigenen Schutzvorkehrungen trotzdem wieder abbaute. Injection informiert, erzwingen kann sie nichts. Die Details stehen in Hält sich Claude Code an die CLAUDE.md?, in Sicherheit von KI-Coding-Agenten und in unserem Sicherheitsleitfaden zu Claude Code.

Wer das Flag bewusst setzt, im Container, als Benutzer ohne root-Rechte, mit deny-Regeln, einem Hook und etwas, das den Diff liest, hat ein vertretbares Setup. Auf dem Notebook wechseln Sie besser in den Auto-Modus, und über den Teil, den kein Permission-Modus abdeckt, sprechen Sie mit uns.

Häufige Fragen

Mit welchem Befehl startet man Claude Code mit allen Rechten?

Mit claude --dangerously-skip-permissions oder gleichbedeutend mit claude --permission-mode bypassPermissions, für einen nicht interaktiven Lauf ergänzt um -p "<prompt>". Gemeint sind die Rechte Ihres Benutzers, nur eben ungefragt. Anthropic beschränkt den Modus auf „isolierte Umgebungen wie Container, VMs oder Dev Container ohne Internetzugang“.

Ist --dangerously-skip-permissions in Claude Code standardmäßig aktiv?

Nein. Eingebaute Voreinstellung ist der Auto-Modus in den Tarifen Pro, Max und Team und Manual überall sonst. Für den Bypass braucht es das Flag, einen defaultMode auf Benutzerebene oder einen ausdrücklich aktivierten Schalter in der VS-Code-Erweiterung und in der Desktop-App. Seit v2.1.257 können die Settings eines Repositorys ihn nicht mehr auswählen.

Kann ich den Bypass-Modus einschalten, während Claude Code schon läuft?

Nur, wenn Sie die Session mit --allow-dangerously-skip-permissions, mit dem Flag selbst oder mit einem defaultMode von bypassPermissions auf Benutzerebene gestartet haben. Andernfalls taucht der Modus im Shift+Tab-Zyklus gar nicht erst auf.

Wo stelle ich den defaultMode in den Settings von Claude Code ein?

Tragen Sie "permissions": { "defaultMode": "acceptEdits" } in ~/.claude/settings.json ein. Mögliche Werte sind default (Alias manual), acceptEdits, plan, auto, dontAsk und bypassPermissions. Aus Projekt- und lokalen Settings werden auto und bypassPermissions ignoriert, und die VS-Code-Erweiterung liest zuerst claudeCode.initialPermissionMode.

Wie kann ich Claude Code alles erlauben, ohne die Berechtigungen zu umgehen?

Setzen Sie ein bloßes "Bash" in permissions.allow und registrieren Sie einen PreToolUse-Hook, der die Befehle zurückweist, die Sie nie sehen wollen. deny- und ask-Regeln behalten dabei Vorrang. Mit weniger Aufwand kommt der Auto-Modus aus, von dem Anthropic allerdings selbst sagt, er „garantiert keine Sicherheit“.

Kann ich Claude Code auf meinem privaten Rechner sicher nutzen?

Im Manual- oder Auto-Modus und mit deny-Regeln auf .env-Dateien, ~/.ssh und die Ordner mit Cloud-Zugangsdaten: für die tägliche Arbeit ja. Mit übersprungenen Permissions direkt auf dem Host: nein. Der Agent handelt dann als Ihr Benutzer, mit SSH-Schlüsseln und Cloud-Zugangsdaten in Reichweite. Nehmen Sie einen Container.

Lässt sich Claude Code im Unternehmen sicher nutzen?

Die Kontrollen dafür gibt es: eine managed-settings.json (unter Linux in /etc/claude-code/) mit disableBypassPermissionsMode, allowManagedPermissionRulesOnly und allowManagedHooksOnly, dazu zentral durchgesetzte Sandbox-Schlüssel. Sie regeln, was der Agent ausführen darf. Den Code, den er erzeugt, prüft keine davon: Das bleibt Ihre Aufgabe.