Wer Claude Code regelmässig nutzt, kennt den Reflex: Das Projekt ist vertraut, die Bestätigungsdialoge nerven, also greift man zum grossen Hammer: --dangerously-skip-permissions. Schnell gestartet, Problem gelöst – bis es das nicht mehr ist.
Dieser Post zeigt, warum es bessere Alternativen gibt und wie man Claude Code mit einem einzigen JSON-File so konfiguriert, dass man gar nicht mehr auf den Flag angewiesen ist.
Was --dangerously-skip-permissions eigentlich macht
Der Flag schaltet das gesamte Berechtigungssystem von Claude Code ab. Claude darf damit:
- Jede Datei lesen und schreiben – ohne Nachfrage
- Jeden Bash-Befehl ausführen – ohne Bestätigung
- Auf alle Verzeichnisse zugreifen – keine Grenzen
Das klingt nach Produktivität. In Wirklichkeit ist es ein Sicherheitsnetz, das man einfach wegwirft und das für jede Session, in der man ihn einsetzt.
Das eigentliche Problem
Der Flag ist eine Globallösung für ein Spezifitätsproblem. Man will eigentlich nur, dass Claude npm run build ohne Nachfrage ausführen kann und deaktiviert dafür das gesamte Berechtigungssystem. Das ist wie das Haustürschloss entfernen, weil man seinen Hausschlüssel nicht finden will.
Dazu kommt: Der Flag gilt nur für diese eine Terminal-Session. Wer ihn vergisst, kämpft wieder mit Bestätigungsdialogen. Wer ihn standardmässig setzt (z.B. im Shell-Alias), trainiert sich selbst darauf, nie mehr über Berechtigungen nachzudenken.
Die saubere Alternative: settings.json
Claude Code hat ein vollständiges Berechtigungssystem über settings.json. Es existiert auf drei Ebenen:
| Datei | Scope | Versioniert? | Wofür |
|---|---|---|---|
~/.claude/settings.json | Global – alle Projekte | Nein | Persönliche Defaults |
.claude/settings.json | Projekt – geteilt im Team | Ja | Team-Permissions |
.claude/settings.local.json | Projekt – lokal | Nein (gitignore) | Persönliche Projekt-Overrides |
Schritt 1: Die richtigen Befehle explizit erlauben
Statt alles zu erlauben, erlaubt man nur das, was man wirklich braucht:
{
"permissions": {
"allow": [
"Bash(npm:*)",
"Bash(git:*)",
"Bash(npx:*)",
"Bash(pnpm:*)",
"Edit(.claude)",
"Read"
]
}
}
Was das bedeutet:
Bash(npm:*)→ Allenpm-Befehle dürfen ohne Nachfrage ausgeführt werdenBash(git:*)→ Allegit-Befehle sind freigeschaltetEdit(.claude)→ Claude darf den.claude/-Ordner eigenständig bearbeitenRead→ Alle Lesezugriffe sind erlaubt (kein Risiko)
Schritt 2: Gefährliche Befehle explizit sperren
Gleichzeitig kann man kritische Befehle dauerhaft sperren, unabhängig vom Modus:
{
"permissions": {
"allow": ["Bash(npm:*)", "Bash(git:*)"],
"deny": [
"Bash(rm -rf:*)",
"Bash(curl * | bash:*)",
"Bash(sudo:*)"
]
}
}
deny hat immer Vorrang vor allow. Selbst wenn man später aus Versehen einen zu breiten allow-Eintrag setzt, blockiert deny gezielt.
Der neue auto-Modus: Kontrolliertes Vertrauen
Mit dem neuen Auto-Modus von Claude geht das noch weiter. Statt statischer Listen entscheidet Claude selbst, basierend auf dem Kontext – ob eine Aktion sicher ist:
{
"permissions": {
"defaultMode": "auto"
}
}
Was der Auto-Modus macht:
- Sichere Aktionen (Dateien lesen, bekannte CLI-Tools) → direkt ausführen
- Potenziell riskante Aktionen → Nachfragen
- Klar destruktive Aktionen → Immer blockieren
Man kann den Auto-Modus mit eigenen Regeln kalibrieren:
{
"permissions": {
"defaultMode": "auto",
"allow": ["Bash(git:*)", "Bash(npm:*)"],
"deny": ["Bash(sudo:*)", "Bash(rm -rf:*)"]
},
"autoMode": {
"allow": [
"Datenbankoperationen auf lokaler Dev-DB sind erlaubt",
"Test-Runner (jest, vitest, pytest) dürfen direkt starten"
],
"soft_deny": [
"Keine Änderungen an Deployment-Konfigurationen ohne Nachfrage"
],
"environment": [
"Dies ist ein lokales Entwicklungs-Setup",
"Keine Produktionssysteme erreichbar"
]
}
}
Das ist ein fundamental anderer Ansatz: kein blindes Vertrauen, sondern kontextuelles Vertrauen.
Für Projekte mit hohem Vertrauen: bypassPermissions
Wer ein Projekt hat, das er vollständig kontrolliert und wo er wirklich keine Bestätigungen mehr will, zum Beispiel ein privates Skript-Repository, kann bypassPermissions als Projekt-Default setzen:
// .claude/settings.local.json (nicht committen!)
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
Wichtige Unterschiede zu --dangerously-skip-permissions:
--dangerously-skip-permissions | bypassPermissions in settings | |
|---|---|---|
| Scope | Einmalige Terminal-Session | Persistent für dieses Projekt |
| Einstellbar | Nein | Mit deny-Regeln kombinierbar |
| Bewusste Entscheidung | Jedes Mal neu nötig | Einmalig, dokumentiert |
| Team-sichtbar | Nein | Optional via settings.json |
Kombination mit deny | Nein | Ja – deny gilt immer |
Ein empfohlenes Setup
Als Basis für meine lokalen Lab-Projekte nutze ich folgendes Setup in ~/.claude/settings.json (global):
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(git:*)",
"Bash(npm:*)",
"Bash(npx:*)",
"Bash(pnpm:*)",
"Bash(node:*)",
"Bash(python:*)",
"Bash(ls:*)",
"Bash(cat:*)",
"Bash(echo:*)",
"Read"
],
"deny": [
"Bash(sudo:*)",
"Bash(rm -rf /)",
"Bash(curl * | sh:*)",
"Bash(wget * | sh:*)"
]
}
}
Für spezifische Projekte mit höherem Automatisierungsbedarf (z.B. Build-Pipelines) kommt lokal ein .claude/settings.local.json dazu, das den Scope erweitert; nie aber global.
Fazit
--dangerously-skip-permissions ist der Notausgang, nicht die Lösung. Wer ihn regelmässig benutzt, hat ein Konfigurationsproblem – kein Berechtigungsproblem.
Die settings.json erlaubt genau das, was man tatsächlich braucht:
- Spezifische Befehle freischalten statt alles erlauben
- Gefährliche Befehle sperren als permanente Guardrail
- Auto-Modus nutzen für kontextuelles, intelligentes Vertrauen
bypassPermissionsim Projekt für vollständig vertraute Umgebungen
Die zehn Minuten, die man einmalig in die Konfiguration investiert, sparen hunderte Bestätigungsklicks und lassen das Sicherheitsnetz dort, wo es hingehört: im Hintergrund, nicht im Papierkorb.
Hello, my name is Ralph. I am a Digital Stuntman. Ecosystem Manager. and Director of Studies at the University of Applied Sciences HWZ, Zurich. This is my Digital Playground especially for topics from my lectures in the Master of Advanced Studies in Digital Business.
