Claude Dangerously Skip Permissions: Was der Modus erlaubt

Was schaltet Claude Dangerously Skip Permissions ab?

--dangerously-skip-permissions und --permission-mode bypassPermissions aktivieren denselben Modus. Claude kann Dateien ändern, Shell-Befehle ausführen und andere Tools aufrufen, ohne die üblichen Freigaben abzuwarten. Auch Schreibzugriffe auf geschützte Pfade sind erlaubt. Beim ersten interaktiven Start erscheint ein Hinweis auf die eigene Verantwortung. Wer ihn ablehnt, beendet damit Claude Code. Anthropics Dokumentation zum Bypass-Modus

Berechtigungen lassen sich mit einer Freigabestelle vergleichen, Isolation mit den Wänden einer Werkstatt. Wer die Freigabestelle abschafft, hat damit noch keine Wände errichtet. Der Gewinn ist eine unterbrechungsfreie Sitzung. Der Preis dafür: Es entfällt die Gelegenheit, eine problematische Aktion vor ihrer Ausführung abzufangen.

Damit verschiebt sich der Arbeitsablauf. Statt einzelne Vorgänge freizugeben, wird zuerst die Umgebung festgelegt und anschließend das Ergebnis geprüft. Das sorgt weder für korrekten Code noch macht es bösartige Anweisungen harmlos.

Welche Schutzmechanismen bleiben bestehen?

„Skip“ bedeutet nicht, dass sämtliche Kontrollen verschwinden. Die folgenden Unterschiede erklären, weshalb auch ein vermeintlich unbeaufsichtigter Lauf anhalten oder eine Aktion verweigern kann:

Die genaue Einstellung für die letzte Zeile lautet permissions.blockReadsOutsideWorkingDirectories: true. Erkannte Bash-Befehle zum Lesen von Dateien können außerhalb der erlaubten Verzeichnisse weiterhin eine Rückfrage auslösen. Durch die Sandbox erzwungene Sperren verhalten sich anders. In einem nicht interaktiven Bypass-Lauf mit -p werden Aufrufe, die weiterhin eine Rückfrage erfordern würden, stattdessen verweigert. Aktionen, die kein Modus automatisch freigibt, Einstellung für Lesezugriffe außerhalb der Arbeitsverzeichnisse

Blockierende PreToolUse-Hooks bleiben ebenfalls Teil der Toolfreigabe. Für EndConversation gilt eine besondere Ausnahme: Solange ein anderes Tool verfügbar bleibt, schränken deny- und ask-Regeln diesen Aufruf nicht ein. Installierte Mods können bestimmte Berechtigungsentscheidungen überschreiben, sofern diese nicht zentral verwaltet werden. Verbindliche Teamvorgaben gehören deshalb in eine zentral verwaltete Richtlinie. Administratoren können Bypass mit "permissions": {"disableBypassPermissionsMode": "disable"} verbieten. Auch eine mit --restricted gestartete Sitzung lässt den Bypass-Modus nicht zu. Rangfolge von Hooks und Regeln, Einstellung zum Abschalten von Bypass

Im Bypass-Modus sind auch geschützte Pfade beschreibbar

Bei .git oder .claude darf man sich nicht auf eine Bestätigungsabfrage verlassen. Im Bypass-Modus sind Schreibzugriffe auf geschützte Pfade erlaubt. Die oben beschriebenen Prüfungen beim Löschen kritischer Verzeichnisse sind davon zu unterscheiden.

Anthropic führt unter anderem folgende geschützte Pfade auf:

Innerhalb von .claude gibt es begrenzte Ausnahmen, darunter Claudes eigene Worktrees, aktuelle Plandateien, temporäre Arbeitsbereiche für Hintergrundsitzungen und bestimmte Memory-Dateien im Markdown-Format. In gewöhnlichen Sitzungen im Modus Manual oder acceptEdits lösen geschützte Schreibzugriffe eine Rückfrage aus. Der Auto-Modus legt sie seinem Klassifikator vor. Eine allow-Regel in einer Einstellungsdatei kann diese Schreibzugriffe nicht vorab freigeben. Geschützte Pfade und Ausnahmen

Vier sicherere Wege zu weniger Unterbrechungen

Die passende Kontrolle hängt davon ab, welche Unterbrechung stört. Für die meisten Entwickler ist eine präzisere Freigaberichtlinie der erste Schritt, bevor Bypass überhaupt nötig wird.

Auto-Modus für die tägliche Programmierarbeit nutzen

Eine Sitzung lässt sich mit claude --permission-mode auto starten. Ein Klassifikator übernimmt die üblichen Freigabeentscheidungen: Ein separates Modell prüft dabei die vorgeschlagenen Aktionen. Soll dies dauerhaft der Standard im Terminal sein, wird "permissions": {"defaultMode": "auto"} in ~/.claude/settings.json ergänzt.

In .claude/settings.json oder .claude/settings.local.json aktiviert dieser Wert den Modus nicht. Zudem hängt der Auto-Modus von unterstützten Modellen und den Einstellungen der Organisation ab. Explizite ask-Regeln lösen weiterhin Rückfragen aus. Der Modus verringert Unterbrechungen, garantiert aber keine Sicherheit. Einstellung für den Standardmodus, Voraussetzungen für den Auto-Modus

Unser Leitfaden zum Auto-Modus von Claude Code erläutert, wann dieses Prüfmodell zum eigenen Arbeitsablauf passt.

Routineaufgaben erlauben und bestimmte Aktionen sperren

permissions.allow eignet sich für geprüfte Befehle, permissions.deny für Vorgänge, die gesperrt bleiben sollen. Claude Code wertet zuerst deny, dann ask und zuletzt allow aus. Auch eine weit gefasste Freigabe kann eine passende Sperre nicht aufheben. Berechtigungsregeln

Das folgende Beispiel für ein vertrauenswürdiges Repository verbindet eng gefasste Freigaben mit einem blockierenden Hook. Es wird in .claude/settings.json eingefügt; vorhandene Schlüssel bleiben erhalten. Terminalsitzungen starten hier bewusst im Modus Manual, damit die aufgeführten Freigaben greifen. Vor ihrer Freigabe sollte geprüft werden, welche Befehle die Test- und Lint-Skripte des Projekts tatsächlich ausführen.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

Für persönliche Projekteinstellungen dient .claude/settings.local.json. Wer die Datei selbst anlegt, sollte sie in .gitignore aufnehmen. Mit /permissions lassen sich die aktiven Regeln und ihre Quelldateien anzeigen. Geltungsbereich der Einstellungen

Solche Muster isolieren weder das Dateisystem noch das Netzwerk. Andere Schreibweisen eines Befehls können ein Bash-Muster umgehen. Beliebige Skripte können Dateien außerdem indirekt lesen, selbst wenn deny-Regeln dies den Datei-Tools verbieten. Geheimnisse gehören deshalb außerhalb der Umgebung. Wo ein Zugriff unmöglich sein muss, braucht es eine durch die Sandbox erzwungene Grenze. Grenzen von Bash-Regeln, Grenzen von Dateiregeln

Größere Änderungen zuerst im Plan-Modus vorbereiten

Der Einstieg erfolgt mit claude --permission-mode plan oder über "permissions": {"defaultMode": "plan"} in den Projekteinstellungen. Claude untersucht das Projekt und schlägt Arbeiten vor, bevor Änderungen am Quellcode freigegeben werden. Die Einstellung "useAutoModeDuringPlan": false auf oberster Ebene schaltet die Freigabe von Planungsbefehlen durch den Klassifikator ab. Befehle außerhalb des eingebauten Satzes rein lesender Befehle benötigen dann eine Bestätigung. Konfiguration des Plan-Modus

Dafür sollte eine neue Plan-Sitzung ohne Flags gestartet werden, die Bypass verfügbar machen. Ist Bypass in einer interaktiven Terminalsitzung verfügbar, setzt der Plan-Modus seine üblichen Sperren für Änderungen und Befehle nicht durch. Das gilt auch bei --allow-dangerously-skip-permissions: Dieses Flag ermöglicht die spätere Auswahl, ohne Bypass sofort zu aktivieren. Plan-Modus bei verfügbarem Bypass

Bestimmte Befehle mit Hooks blockieren

Der Handler hooks.PreToolUse im Beispiel verwendet matcher: "Bash", type: "command" und if: "Bash(rm *)". Trifft die Bedingung zu, gibt sein Shell-Befehl eine Begründung aus und endet mit Status 2. Dadurch wird der Toolaufruf blockiert. Ein separates Skript ist nicht nötig. Der Shell-Befehl ist unser kleines Beispiel auf Grundlage der von Anthropic dokumentierten Hook-Felder und des blockierenden Exit-Status. Hook-Konfiguration, Blockierende Exit-Codes

Damit werden passende rm-Aufrufe blockiert, nicht jede denkbare Möglichkeit, eine Datei zu löschen. Ein Team könnte den Hook durch einen geprüften Validator für seine eigenen Deployment- oder Bereinigungsbefehle ersetzen. Die Prüfungen sollten so eng gefasst bleiben, dass sie verständlich und testbar sind. Unser Artikel zu Claude Code Hooks behandelt Konfiguration und Fehlersuche.

In welchen Umgebungen ist Bypass laut Anthropic vorgesehen?

Anthropics Übersicht gängiger Konfigurationen verlangt einen Container, eine VM oder eine Sandbox-Laufzeitumgebung sowie unter Linux und macOS einen Nutzer ohne Root-Rechte. Der Abschnitt zum Bypass-Modus beschreibt isolierte Umgebungen, die dem Host keinen Schaden zufügen können, und nennt ausdrücklich Umgebungen ohne Internetzugang. Der Devcontainer-Leitfaden zeigt dagegen eine vernetzte Konfiguration, deren ausgehende Verbindungen auf die von Claude benötigten Dienste beschränkt sind. Unbeschränkter Netzwerkzugriff ist als eigenes Risiko zu betrachten. Erforderliche Isolation, Netzwerkbeschränkungen im Devcontainer

Unter Linux und macOS wird der Start von Bypass als root oder über sudo normalerweise verweigert. Die Dokumentation nennt eine automatische Ausnahme innerhalb einer erkannten Sandbox. Der dokumentierte Devcontainer-Ansatz verwendet ein Konto ohne Root-Rechte. Ein Root-Fehler sollte nicht dadurch behoben werden, dass diese Grenze aufgeweicht wird.

Die Referenzkonfiguration für den Devcontainer einrichten

Als Ausgangspunkt dient ein temporärer Checkout eines vertrauenswürdigen Repositorys, der anschließend verworfen werden kann. Wenn Docker, VS Code und die Erweiterung Dev Containers installiert sind, lässt sich Anthropics Referenzprojekt so öffnen:

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. In VS Code Dev Containers: Reopen in Container ausführen. Die Referenz kombiniert die CLI, persistente Volumes und eine Firewall für ausgehende Verbindungen. Prüfen, ob remoteUser ein Konto ohne Root-Rechte angibt.
2. Im Terminal des Containers id -u ausführen und sicherstellen, dass das Ergebnis nicht 0 ist. Zur Anmeldung claude starten und diese Sitzung anschließend beenden.
3. Im selben Container-Terminal claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions ausführen.
4. Für das eigene Projekt das Referenzverzeichnis .devcontainer/ in einen temporären Checkout kopieren, der anschließend verworfen werden kann, und das Dockerfile an dessen Toolchain anpassen. Nach jeder Aufgabe den Diff des Arbeitsbereichs prüfen.

Dieses Vorgehen folgt Anthropics Arbeitsablauf für den Referenzcontainer. Die Referenz ist ein funktionsfähiges Beispiel, kein gepflegtes Basis-Image. Die Beschränkungen für ausgehende Verbindungen sollten erhalten bleiben oder durch gleichwertige Netzwerkkontrollen ersetzt werden.

Der eingebundene Arbeitsbereich bleibt aus dem Container heraus beschreibbar; diese Änderungen wirken sich auf den Host aus. ~/.ssh, Dateien mit Cloud-Zugangsdaten und nicht benötigte Verzeichnisse sollten nicht eingebunden werden. Ein bösartiges Projekt kann weiterhin alles nach außen übertragen, worauf es im Container Zugriff hat, einschließlich der Claude-Zugangsdaten. Deshalb sind vertrauenswürdige Repositorys und die Überwachung der Arbeit weiterhin nötig. Grenzen des Devcontainers

Cloud-Sitzungen ignorieren Bypass als Standardmodus

Cloud-Sitzungen ignorieren die Werte defaultMode: "bypassPermissions" und defaultMode: "dontAsk" in Einstellungsdateien ohne Hinweis. Sie starten in dem Modus, den das Modus-Dropdown der Cloud anzeigt. Eine eingecheckte JSON-Einstellung kann eine Cloud-Sitzung nicht in den Bypass-Modus zwingen. Modusverhalten in der Cloud

Die lokale Datei ~/.claude/settings.json wird nicht in eine von Anthropic gehostete Cloud-Sitzung übertragen. Auch für Repository-Einstellungen gelten Grenzen: Sitzungen über mehrere Repositorys hinweg laden nicht die Berechtigungsregeln und Hooks jedes einzelnen Repositorys. Entscheidend ist deshalb die tatsächlich geltende Richtlinie der Cloud-Umgebung. Die Terminalkonfiguration lässt sich nicht einfach als übernommen voraussetzen. Einstellungen in Cloud-Sitzungen

Welcher Modus passt zu welcher Aufgabe?

Meist bringt es am meisten, wiederkehrende Freigaben aus einem bestehenden Arbeitsablauf zu entfernen. Die folgenden Möglichkeiten stehen in der Reihenfolge, in der ich ansetzen würde:

Für den CI-Fall dokumentiert Anthropic claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" als Ausgangspunkt. Vorgänge, die sonst eine Rückfrage auslösen würden, werden damit verweigert. Gängige Konfigurationen

Unsere Best Practices für Claude Code ergänzen jeden dieser Modi. Berechtigungen steuern die Ausführung. Ob das Ergebnis erhaltenswert ist, entscheidet die anschließende Prüfung.

Zwei nützliche Tools, die ein Team entwickeln könnte

Das größte Potenzial hat ein Prüfwerkzeug für Berechtigungseinstellungen. DataForSEO schätzt für „claude code permissions“ 720 Suchanfragen pro Monat in den USA. Das deutet auf Schwierigkeiten hin, die passenden Informationen zu finden, belegt aber keine Kaufabsicht. Ein Team für Entwicklerplattformen könnte ein kleines Prüfwerkzeug bauen, das den Geltungsbereich von Einstellungen erklärt, auf ignorierte defaultMode-Werte hinweist und weit gefasste Befehlsregeln vor dem Onboarding von Kollegen sichtbar macht. Ein erster sinnvoller Nutzen wäre ein Bericht mit Änderungsvorschlägen. Die Herausforderung liegt darin, das Werkzeug an Änderungen im Konfigurationsverhalten von Claude Code anzupassen.

Ein Startwerkzeug für temporäre Ausführungsumgebungen könnte Teams mit regelmäßig wiederkehrenden unbeaufsichtigten Aufgaben helfen. Dieselbe Nachfrageprüfung schätzt für „claude code docker“ 260 Suchanfragen pro Monat in den USA. Ein MVP könnte eine geprüfte Containervorlage, erlaubte Einbindungen, die Ausführung ohne Root-Rechte und die Richtlinie für ausgehende Verbindungen kontrollieren. Anschließend würde es den entstandenen Diff und die Protokolle für einen Maintainer sammeln. Sein Nutzen wäre eine einheitliche Einrichtung. Seine Grenze: Ein Startwerkzeug kann weder Code aus nicht vertrauenswürdigen Repositorys sicher machen noch allein deshalb Isolation garantieren, weil Docker vorhanden ist.

Beide Ideen eignen sich für interne Werkzeuge, deren Nutzen mit tatsächlichen Anwendern geprüft werden sollte. Keine davon setzt voraus, Bypass auf den Rechnern der Entwickler zum Standard zu machen.

Der nächste Schritt für Montag: einen wiederkehrenden Arbeitsablauf auswählen, seine tatsächlichen Befehle prüfen und die kleinstmögliche Freigaberichtlinie einrichten, mit der er vollständig durchlaufen kann. Ein temporärer Container wird erst dann nötig, wenn die Aufgabe darüber hinaus unbeaufsichtigte Ausführung verlangt.

Wenn Ihr Team Unterstützung beim Aufbau und Betrieb dieses Arbeitsablaufs braucht, helfen wir mit KI-Produktionssystemen.