Schluss mit –dangerously-skip-permissions – so geht es richtig

Verfasst von

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:*) → Alle npm-Befehle dürfen ohne Nachfrage ausgeführt werden
Bash(git:*) → Alle git-Befehle sind freigeschaltet
Edit(.claude) → Claude darf den .claude/-Ordner eigenständig bearbeiten
Read → 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
bypassPermissions im 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.

Ralph

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.