Claude Code --dangerously-skip-permissions: Nutzung und Grenzen

claude --dangerously-skip-permissions startet Claude Code im bypassPermissions-Modus. Das entfernt die üblichen Bestätigungsaufforderungen für Dateiänderungen, Shell-Befehle und Tool-Aufrufe. Nutzen Sie diese Funktion für begrenzte Aufgaben in einer Einweg-Umgebung. Sie müssen Dateien, Anmeldeinformationen und Netzwerkzugriff im Vorfeld einschränken. Das Flag selbst erstellt keine Sandbox.

claude --dangerously-skip-permissions

Das ist der Befehl. Prüfen Sie vor dem Einsatz in einem unbeaufsichtigten Job genau, worauf der Prozess zugreifen kann. Eine fehlende Bestätigung in einem Wegwerf-Checkout hat völlig andere Konsequenzen als auf einem Laptop mit Produktions-Anmeldeinformationen.

Dieser Text behandelt den Befehl, seine Alternativen und einen konkreten Run-and-Review-Workflow. Wir haben die Dokumentation von Anthropic am 6. Oktober 2026 geprüft. Die Beispiele beschreiben ein mögliches Setup und sind keine Ergebnisse eines Live-Sicherheitstests von Claude Code.

Was macht dangerously-skip-permissions?

Das Flag wählt denselben Berechtigungsmodus wie claude --permission-mode bypassPermissions. Claude arbeitet dadurch ohne die üblichen Unterbrechungen weiter. Das Programm behält die Betriebssystem-Identität und den Zugriff des gestarteten Prozesses. Es gewährt keine Root-Rechte, erzeugt keine neuen Anmeldeinformationen und umgeht keine Netzwerkblockaden. Claude Code Berechtigungsmodi.

Es gibt jedoch Ausnahmen. Aktuelle Versionen behalten explizite Verweigerungs- und Nachfrageregeln bei. Sie prüfen bestimmte kritische Löschungen und Aktionen, die eine Benutzerinteraktion erfordern. Verlassen Sie sich nicht auf diese Ausnahmen als Schutz für beliebige Dateien oder Cloud-Ressourcen. Ein Befehl kann ein Projekt ruinieren, ohne gleich das Dateisystem-Root zu löschen.

Insbesondere kann der Bypass-Modus ohne die Protected-Path-Eingabeaufforderung in .git und .claude schreiben. Einige Suchzusammenfassungen behaupten, dass diese Ordner immer geschützt bleiben. Das widerspricht der aktuellen Dokumentation. Berechtigungsreferenz.

Nehmen wir eine Routineanfrage wie "Behebe die fehlschlagenden Tests." Claude könnte einen Test bearbeiten, ein Paket installieren oder die Konfiguration ändern. Wenn derselbe Prozess auch einen Cloud-Schlüssel lesen und dessen API aufrufen kann, blockiert ein lokaler Einweg-Ordner diese Remote-Aktionen nicht. Ihr Setup muss diesen Zugriff vor dem Start begrenzen.

Befehle für interaktive und unbeaufsichtigte Nutzung

Eine interaktive Sitzung starten

Öffnen Sie ein Terminal in Ihrer vorbereiteten Umgebung und führen Sie aus:

claude --dangerously-skip-permissions

Prüfen Sie den angezeigten Berechtigungsmodus, bevor Sie Aufgaben vergeben. Beim ersten interaktiven Start zeigt Claude Code oft eine Warnung an, die Sie akzeptieren müssen. Bei einem Root- oder Sudo-Fehler sollten Sie ein Non-Root-Konto in der Umgebung verwenden. Ändern Sie nicht die Schutzmechanismen des Hosts. Modus-Setup und Root-Einschränkungen.

Eine Aufgabe ausführen und das Ergebnis erfassen

Für eine aktuelle Claude Code Version mit API-Key-Authentifizierung:

claude --bare -p \
  "Fix the failing unit test in this checkout. Run the relevant tests. Report changed files and failures. Do not commit or push." \
  --dangerously-skip-permissions \
  --max-turns 12 \
  --output-format json > /tmp/claude-result.json

Hier führt -p eine nicht-interaktive Aufgabe aus. --output-format json macht die Antwort für einen Runner leichter lesbar. --max-turns begrenzt die Agenten-Schleife. Es erzwingt jedoch kein striktes Zeitlimit für den gesamten Job. Konfigurieren Sie dieses Limit separat in Ihrem Runner. CLI-Flag-Referenz.

--bare verhindert das Laden der üblichen Hooks, Plugins, Speicher und Repository-Anweisungen. Für die API von Anthropic ist ANTHROPIC_API_KEY erforderlich. Es nutzt nicht den OAuth-Login Ihres Abonnements. Stellen Sie diesen Schlüssel über die Secret-Einstellungen des Runners bereit. Prüfen Sie bei älteren Versionen die Kompatibilität, bevor Sie dieses Beispiel kopieren. Programmatische Läufe und Bare-Modus.

Der Hinweis "Do not commit or push" im Prompt beschreibt lediglich die Aufgabe. Erzwingen Sie diese Einschränkung technisch, indem Sie den Schreibzugriff auf das Remote-Repository verweigern. Ein Satz in einem Prompt ersetzt keine echten Netzwerkrichtlinien oder Zugriffsrechte.

Weitere Informationen zum Erfassen von Ergebnissen und zum Umgang mit fehlgeschlagenen Jobs finden Sie in unserem Anleitung für Claude Code ohne interaktive Eingaben.

Bypass für später in der Sitzung aktivieren

Das ähnlich benannte Flag hat eine andere Wirkung:

claude --permission-mode default --allow-dangerously-skip-permissions

--allow-dangerously-skip-permissions macht den Bypass für einen späteren Zeitpunkt auswählbar. Es startet das Programm nicht direkt im Bypass-Modus. Nutzen Sie den Shift+Tab-Moduszyklus des Terminals, um zu wechseln. Wenn die Sitzung den Bypass beim Start nicht aktiviert hat, müssen Sie mit dem entsprechenden Flag neu starten. CLI-Referenz.

Auto-Modus vs. dangerously-skip-permissions

Wählen Sie den am wenigsten freizügigen Modus, der die Aufgabe abschließen lässt:

Die Modusnamen und das Verhalten stammen aus der Berechtigungsreferenz.

Der Auto-Modus nutzt einen separaten Klassifikator zur Überprüfung von Aktionen wie Shell-Befehlen und externen Tool-Aufrufen. Er kann eine Aktion blockieren und Claude zwingen, einen anderen Ansatz zu versuchen. Er macht dabei gelegentlich Fehler. Anthropic beschreibt ihn als Möglichkeit, den Bestätigungsaufwand zu reduzieren. Das bringt Kompromisse mit sich, die bei einer manuellen Überprüfung oder im Bypass-Modus nicht existieren. Wie Anthropic den Auto-Modus baute.

Wenn wiederholte Eingabeaufforderungen Ihr Hauptproblem sind, probieren Sie zuerst den Auto-Modus aus, sofern Ihr Konto dies unterstützt:

claude --permission-mode auto

Wenn Ihr Job nur bekannte Tools benötigt, ist dontAsk mit engen Erlaubnisregeln oft die bessere Wahl. Das hat einen großen Vorteil für die Automatisierung: Fehlende Berechtigungen lassen die Aktion sofort fehlschlagen, anstatt den Job auf eine manuelle Eingabe warten zu lassen. Untersuchen Sie verweigerte Aktionen, bevor Sie die Regeln lockern.

Macht die Sandbox von Claude Code den Bypass sicher?

Die integrierte Bash-Sandbox von Claude Code beschränkt den Shell-Zugriff auf Dateien und das Netzwerk. Die Auto-Allow-Option kann Sandbox-Befehle ohne Eingabeaufforderung bestätigen. Diese Einstellung arbeitet unabhängig vom Klassifikator des Auto-Modus. Bash-Sandbox-Konfiguration.

Die integrierte Bash-Sandbox kapselt nicht die gesamte Anwendung. Datei-Tools, MCP-Server und Hooks benötigen eigene Grenzen. Alternativ brauchen sie eine äußere Umgebung, die den gesamten Claude Code Prozess einschließt. VMs und Container bieten hier unterschiedliche Isolierungsgrade. Wählen Sie die Umgebung basierend auf dem auszuführenden Code und dem tolerierbaren Fehlerfall. Vergleich von Sandbox-Umgebungen.

Prüfen Sie auch das Wiederholungsverhalten. Bei aktiviertem Bypass kann ein Wiederholungsversuch außerhalb der Sandbox ohne Nachfrage ausgeführt werden. Bei unterstützten Setups verhindern die folgenden Sandbox-Einstellungen diesen Versuch und erzwingen den Start der Sandbox:

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

Überprüfen Sie zudem alle excludedCommands-Einträge. Diese können weiterhin außerhalb der Bash-Sandbox ausgeführt werden. Nutzen Sie für zentral erzwungene Einstellungen eine verwaltete Richtlinie, die der Agent nicht selbst bearbeiten kann. Strenge Sandbox-Einstellungen.

Ein praktischer Workflow für einen unbeaufsichtigten Lauf

Nehmen Sie eine kleine Aufgabe mit fehlschlagenden Tests als Beispiel. Die gewünschte Ausgabe ist ein Patch und ein Testbericht. Es gibt keinen Grund, dass dieser Job Bereitstellungszugriff hat.

1. Einen separaten Checkout vorbereiten

Erstellen Sie einen frischen Container oder eine VM. Kopieren Sie das Repository bei einem bekannten Commit hinein. Eine echte Kopie ist sicherer als ein beschreibbarer Mount Ihres Hauptarbeitsverzeichnisses. Ein Worktree hilft zwar bei der Trennung von Änderungen, isoliert aber weder das Betriebssystem noch die Anmeldeinformationen.

Installieren Sie die erforderliche Laufzeitumgebung und Pakete direkt beim Setup. Notieren Sie den Start-Commit und die Tool-Versionen. Nutzen Sie ein Non-Root-Konto für den Agenten. Wenn Sie mit einem Dev-Container arbeiten, prüfen Sie dessen Mounts. Ein beschreibbares Host-Verzeichnis setzt diese Dateien Bearbeitungen aus dem Container heraus aus. Der Anleitung für Dev-Container von Anthropic erklärt das Setup und seine Grenzen.

2. Dem Job nur den nötigen Zugriff geben

Übergeben Sie die Modell-Anmeldeinformationen separat. Wenn das Repository privat ist, nutzen Sie einen schreibgeschützten Zugriff für den Checkout. Halten Sie Bereitstellungsschlüssel, Ihren SSH-Agenten, den Docker-Socket und unbeteiligte Dateien aus dem Home-Verzeichnis strikt außerhalb der Umgebung.

Erlauben Sie den Modell-Endpunkt und die Paket- oder Quell-Hosts, die für die Aufgabe zwingend nötig sind. Beschränken Sie allen anderen ausgehenden Zugriff über die Netzwerkkontrollen der Umgebung. Wenn ein Abhängigkeits-Download fehlschlägt, identifizieren Sie den exakten Host, bevor Sie weitere Ziele freigeben.

An dieser Stelle entscheiden Sie auch, welche MCP-Server die Aufgabe benötigt. Eine Datenbank- oder Cloud-MCP-Verbindung fügt Remote-Fähigkeiten hinzu, selbst wenn das lokale Dateisystem nur ein Wegwerf-System ist.

3. Eine Aufgabe mit klarer Endbedingung ausführen

Nutzen Sie den obigen Headless-Befehl, sobald Authentifizierung und Abhängigkeiten bereitstehen. Setzen Sie ein Runner-Timeout für den Job. Erfassen Sie den Exit-Status, stdout und stderr. Behalten Sie den Testbefehl unter Ihrer eigenen Kontrolle. So hängt das Ergebnis nicht allein von der Zusammenfassung des Agenten ab.

Beginnen Sie mit einer kleinen Änderung, etwa einem fehlschlagenden Test oder einem dokumentierten Bug. Eine Anweisung wie "Räume das gesamte Repository auf" lässt zu viel Raum für Bearbeitungen, die Sie später kaum überprüfen können.

4. Die tatsächlichen Dateien überprüfen

Untersuchen Sie den Checkout nach Ende des Jobs:

git status --short
git diff --stat
git diff --check
git diff
git ls-files --others --exclude-standard

Der letzte Befehl listet ungetrackte Dateien auf, die ein einfaches Diff übersieht. Untersuchen Sie diese Dateien ebenfalls. Vergleichen Sie den finalen Commit mit dem Start-Commit. Das verhindert, dass ein unerwarteter Commit Änderungen aus dem Working-Tree-Diff verbirgt. Führen Sie die relevanten Tests von Ihrem vertrauenswürdigen Runner erneut aus und überprüfen Sie den Patch vor dem Mergen.

Exportieren Sie die benötigten Dateien, bevor Sie die Umgebung stoppen. Halten Sie Anmeldeinformationen aus Logs und Artefakten fern. Lassen Sie die temporären Anmeldeinformationen der Aufgabe ablaufen. Zerstören Sie den Einweg-Workspace, sobald das Überprüfungsmaterial sicher gespeichert ist.

Wann Lizard Sandboxes passen

Sandboxes auf Lizard können den Remote-Workspace für dieses Muster bereitstellen. Sie erstellen eine Umgebung, führen eine Aufgabe aus, sammeln die Dateien und stoppen das System wieder. Legen Sie eine explizite Lebensdauer fest. Das verhindert, dass ein fehlgeschlagener Runner die Umgebung auf unbestimmte Zeit laufen lässt. Beginnen Sie mit dem Schnellstart für Sandboxes.

Prüfen Sie die Laufzeitumgebung, bevor Sie sie für Ihr Bedrohungsmodell auswählen. Sandboxes laufen als Firecracker-microVMs, jeweils mit eigenem Kernel. Eine Sandbox, die ein bestehendes Pod-basiertes Persistent Volume einbindet oder einen älteren Pod-Snapshot wiederherstellt, läuft als Kubernetes-Pod (runc) und teilt den Host-Kernel. Im Lizard SDK zeigt getInfo().runtime an, welche Variante Sie erhalten haben. Halten Sie Anmeldeinformationen in beiden Fällen entsprechend eingegrenzt. Siehe die Laufzeit-Dokumentation.

Remote-Ausführung hilft, wenn Sie einen frischen Workspace für jeden Job oder viele Jobs gleichzeitig benötigen. Sie erfordert aber weiterhin eine Netzwerkrichtlinie und einen Überprüfungsschritt. Eine Sandbox mit einem Produktions-Datenbank-Token kann diese Datenbank erreichen, völlig unabhängig davon, wo die Sandbox läuft.

Häufig gestellte Fragen

Kann ich dangerously-skip-permissions standardmäßig nutzen?

Ja. Ergänzen Sie für einen dedizierten Worker in einem Container oder einer VM die Datei ~/.claude/settings.json des Worker-Benutzers um diese Einstellung:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

Neue Terminalsitzungen starten dann im Bypass-Modus. Beschränken Sie diesen Standard auf den temporären Worker; für einzelne Jobs verwenden Sie das explizite Start-Flag. In aktuellen Versionen aktiviert dieser Wert den Bypass nicht, wenn er in der Datei .claude/settings.json oder .claude/settings.local.json des Repositorys steht. Eine verwaltete Richtlinie kann den Modus ebenfalls deaktivieren. Geltungsbereich und Rangfolge der Einstellungen.

Erben Subagenten Bypass-Berechtigungen?

Ja. Im aktuell dokumentierten Verhalten zwingt eine Hauptkonversation im Bypass-Modus ihre Subagenten in denselben Modus. Das überschreibt deren eigene Berechtigungsmodus-Einstellung. Ein Subagent ist keine separate Sicherheitsgrenze. Subagenten-Berechtigungen.

Warum stellt Claude immer noch eine Frage?

Eine Bestätigungsaufforderung und eine inhaltliche Frage zur Aufgabe sind zwei verschiedene Dinge. Einige Aktionen erfordern auch im Bypass-Modus eine Interaktion. Konfigurierte Nachfrageregeln können weiterhin greifen. Lesen Sie den tatsächlichen Prompt, bevor Sie davon ausgehen, dass das Flag ignoriert wurde. Legen Sie bei unbeaufsichtigten Jobs die erwartete Ausgabe und das Fehlerverhalten im Voraus fest.

Macht das Flag Claude Code kostenlos oder entfernt es Ratenlimits?

Nein. Es ändert lediglich die Berechtigungsbehandlung. Ihr Modellanbieter kontrolliert weiterhin die Authentifizierung, Nutzungsgebühren und Ratenlimits. Wiederholte Versuche können mehr Token verbrauchen, selbst wenn keine Bestätigungsaufforderung auf dem Bildschirm erscheint.

Probieren Sie für die tägliche Arbeit zuerst den Auto-Modus oder die Auto-Allow-Option der Bash-Sandbox aus. Machen Sie die Umgebung für unbeaufsichtigte Bypass-Läufe zu einem strikten Einweg-System. Beschränken Sie den Zugriff auf das Nötigste. Überprüfen Sie die resultierenden Dateien immer, bevor sie Ihr Hauptprojekt beeinflussen.