Vollständiger Leitfaden zu Claude Code Berechtigungen | settings.json, Hooks & Allowlist erklärt

Claude Code besitzt äußerst leistungsstarke Dateioperations- und Befehlsausführungsfähigkeiten. Berechtigungen (permissions) ermöglichen es, diese Kraft sicher zu kontrollieren. Gehen Sie über den „irgendwie funktioniert es schon”-Zustand hinaus und entwerfen Sie einen Claude Code, der genau wie beabsichtigt arbeitet.

Dieser Artikel erklärt alle Einstellungsoptionen in .claude/settings.json, Hook-Implementierungsmuster und umgebungsspezifisches Berechtigungsdesign anhand von funktionierendem Code.

Überblick über Berechtigungen

Claude Code-Berechtigungen werden auf 3 Ebenen gesteuert.

Ebene	Schlüssel	Verhalten
Erlauben	allow	Wird automatisch ohne Bestätigungsdialog ausgeführt
Fragen	ask	Erfordert jedes Mal eine Benutzergenehmigung
Verweigern	deny	Kann überhaupt nicht ausgeführt werden (wird mit Fehler abgewiesen)

Einstellungen werden in .claude/settings.json geschrieben. Im Projektstamm abgelegt, kann das Team es über git teilen; in ~/.claude.json abgelegt, wird es zur globalen Einstellung.

Priorität (höchste zuerst):
Projekt .claude/settings.json
    > Global ~/.claude.json
        > Standard (alles ist ask)

Grundstruktur von settings.json

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)"
    ]
  },
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

Toolnamen und Mustersyntax

Berechtigungen werden im Format „Toolname(Argumentmuster)” geschrieben.

Wichtigste Tool-Liste

Toolname	Beschreibung
Read	Datei lesen
Write	Neue Dateien erstellen
Edit	Teilweise Änderung bestehender Dateien
Bash	Shell-Befehlsausführung
Glob	Dateimustersuche
Grep	Inhaltssuche
WebFetch	URL abrufen
Agent	Sub-Agenten starten

Mustersyntax

"Read(**)"          // Lesen aller Dateien erlauben
"Read(src/**)"      // Nur unter src/ erlauben
"Read(*.md)"        // Nur .md-Dateien erlauben
"Bash(npm run *)"   // Nur Befehle erlauben, die mit npm run beginnen
"Bash(git *)"       // Alle git-Befehle erlauben
"Bash(rm -rf *)"    // rm -rf verweigern

** passt auf alle Pfade einschließlich Verzeichnisse; * passt auf ein einzelnes Segment.

Praktische Muster

Muster 1: Solo-Entwicklung (relativ freizügig)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm *)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git add*)",
      "Bash(node *)",
      "Bash(echo *)",
      "Bash(cat *)",
      "Bash(ls *)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~*)",
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(rm *)"
    ]
  }
}

Muster 2: Team-Entwicklung (sicherheitsorientiert)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run typecheck)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase *main*)",
      "Bash(git rebase *master*)",
      "Bash(DROP *)",
      "Bash(TRUNCATE *)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(git add*)",
      "Bash(npm install*)",
      "Bash(*deploy*)"
    ]
  }
}

Muster 3: Produktionsumgebung (nur lesen)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git show*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(ps *)",
      "Bash(df *)",
      "Bash(top *)"
    ],
    "deny": [
      "Write(**)",
      "Edit(**)",
      "Bash(git push*)",
      "Bash(git commit*)",
      "Bash(git reset*)",
      "Bash(rm *)",
      "Bash(mv *)",
      "Bash(*deploy*)",
      "Bash(*restart*)",
      "Bash(*kill *)"
    ],
    "ask": []
  }
}

In der Produktion wird dies mit CLAUDE_SETTINGS=.claude/settings.production.json claude angegeben.

Muster 4: Nur Inhaltserstellung (das auf dieser Website verwendete Muster)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Write(site/src/content/**)",
      "Write(content/**)",
      "Edit(site/src/content/**)",
      "Edit(content/**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(node scripts/*)",
      "Bash(QIITA_TOKEN=* node scripts/qiita-publish.mjs)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Edit(.env*)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(bash scripts/deploy.sh*)"
    ]
  }
}

Der Schlüssel ist, Schreibzugriffe auf ein bestimmtes Verzeichnis zu beschränken, wie bei Write(site/src/content/**).

Hooks: Prozesse vor und nach Berechtigungen ausführen

Hooks sind ein Mechanismus, der vor und nach der Tool-Ausführung automatisch Befehle ausführt. Sie können für Sicherheitsprüfungen und automatische Formatierung verwendet werden.

PreToolUse: Hook vor der Ausführung

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo '🚨 .env-Hinzufügung erkannt!' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "node scripts/secret-scan.mjs"
        }]
      },
      {
        "matcher": "Bash(rm*)",
        "hooks": [{
          "type": "command",
          "command": "echo '⚠️ Löschbefehl erkannt. Ausführung in 5 Sekunden. Ctrl+C zum Abbrechen.' && sleep 5"
        }]
      }
    ]
  }
}

Wenn ein Hook-Befehl Exit-Code 1 zurückgibt, wird die Tool-Ausführung blockiert. Das ist der wichtigste Punkt.

PostToolUse: Hook nach der Ausführung

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit 2>&1 | head -20 || true"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git log --oneline -3"
        }]
      }
    ]
  }
}

PostToolUse wird für Prüfungen nach der Ausführung und Nebeneffekte verwendet – zum Beispiel automatische Typprüfung nach Dateibearbeitungen oder Anzeige der letzten 3 Log-Einträge nach einem Commit.

Praktische Hooks-Rezeptsammlung

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "hooks": [{
          "type": "command",
          "command": "echo '📦 Paket wird hinzugefügt. Bitte package.json prüfen.'"
        }]
      },
      {
        "matcher": "Bash(*deploy*)",
        "hooks": [{
          "type": "command",
          "command": "read -p '🚀 Deployment wird gestartet. Fortfahren? [y/N] ' ans && [ \"$ans\" = 'y' ] || exit 1"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write(*.ts)|Edit(*.ts)",
        "hooks": [{
          "type": "command",
          "command": "npx eslint --fix $CLAUDE_TOOL_INPUT_FILE_PATH 2>/dev/null || true"
        }]
      }
    ]
  }
}

Berechtigungsmodi: Berechtigungsebene beim Start

Sie können den Modus auch beim Starten des claude-Befehls angeben.

# Normaler Modus (folgt settings.json)
claude

# Alle Operationen automatisch genehmigen (gefährlich! nur für vertrauenswürdige Umgebungen)
claude --dangerously-skip-permissions

# Nur bestimmte Operationen überspringen
claude --allowedTools "Read,Grep,Glob"

# Nicht-interaktiver Modus (in CI/CD verwendet)
claude -p "Tests ausführen und Ergebnisse melden" --dangerously-skip-permissions

--dangerously-skip-permissions sollte nur für CI/CD-Automatisierung oder vollständig verstandene Automatisierungsskripte verwendet werden und in der täglichen interaktiven Nutzung vermieden werden.

Priorität und Überschreibung von Konfigurationsdateien

Wenn mehrere Konfigurationsdateien vorhanden sind:

~/.claude.json              ← Global (für alle Projekte gemeinsam)
    +
.claude/settings.json       ← Projekt (git-verwaltet)
    +
.claude/settings.local.json ← Persönliche Überschreibungen (gitignore empfohlen)
    =
Zusammengeführte Einstellungen werden angewendet

Schreiben Sie persönliche Zusatzeinstellungen in .claude/settings.local.json und fügen Sie es zu gitignore hinzu. Um zu verhindern, dass Team-Deny-Listen durch persönliche Einstellungen überschrieben werden, ist es sicheres Design, Deny-Regeln nur in settings.json zu schreiben.

# Zu .gitignore hinzufügen
.claude/settings.local.json

Die 5 häufigsten Fallstricke

1. Platzhaltermuster falsch verwenden

// ❌ Dies passt nur auf den einzelnen Befehl "git"
"Bash(git)"

// ✅ Passt auch auf git gefolgt von Argumenten
"Bash(git *)"
"Bash(git*)"  // Funktioniert auch ohne Leerzeichen, aber explizites * ist sicherer

2. Vergessen, dass deny Vorrang vor ask hat

// Mit dieser Konfiguration wird Bash(rm -rf /tmp/test) von deny abgefangen und blockiert
// Es erreicht ask nie
{
  "deny": ["Bash(rm -rf*)"],
  "ask": ["Bash(rm*)"]  // ← rm -rf wird von deny behandelt
}

3. Exit-Codes von Hooks nicht beachten

# Wenn der PreToolUse-Hook-Befehl immer exit 0 zurückgibt,
# blockieren Scan-Fehler die Ausführung nicht

# ❌ Läuft auch bei Fehler durch
"command": "node scan.mjs"

# ✅ Exit-Code explizit steuern
"command": "node scan.mjs || exit 1"

4. settings.json versehentlich in .gitignore aufnehmen

Manche Teams fügen settings.json—das sie teilen möchten—versehentlich zu .gitignore hinzu. Der richtige Ansatz ist Projekteinstellungen unter git, nur settings.local.json in gitignore.

5. Vergessen, die Produktionskonfiguration manuell zu wechseln

# ❌ In der Produktion mit Alltagseinstellungen arbeiten

# ✅ Einstellungen vor der Produktionsarbeit explizit wechseln
CLAUDE_SETTINGS=.claude/settings.production.json claude

Ein Alias macht es schwerer zu vergessen:

# ~/.bashrc or ~/.zshrc
alias claude-prod='CLAUDE_SETTINGS=.claude/settings.production.json claude'

Konfiguration debuggen

Wenn unklar ist, „warum wird dieser Befehl blockiert”:

# Aktuelle Einstellungen prüfen
claude --print-settings 2>/dev/null || cat .claude/settings.json

# Prüfen, welche Regel übereinstimmt (ausführlicher Modus)
claude --verbose -p "git push ausführen"

Zusammenfassung: Best Practices für das Berechtigungsdesign

1. Zuerst deny festlegen
   → Befehle auflisten, die niemals ausgeführt werden sollen
   → rm -rf, git push --force, DROP TABLE sind unverzichtbar

2. Dann ask konfigurieren
   → Schreib- und Deploy-Operationen, die Bestätigung erfordern

3. Den Rest allow geben
   → Lese- und CI-Operationen: alles allow für Effizienz

4. Sicherheit mit Hooks automatisieren
   → Pre-Commit-Scanning, automatische Typprüfung nach Bearbeitungen

5. Umgebungsspezifische Konfigurationsdateien vorbereiten
   → settings.json (Entwicklung), settings.production.json (Produktion)

Mit richtigen Berechtigungseinstellungen werden Sie aufhören, mechanisch auf Genehmigungsschaltflächen zu klicken, und sich nur noch auf Operationen konzentrieren können, die wirklich überprüft werden müssen. 30 Minuten Design im Voraus machen Hunderte zukünftiger Arbeitsstunden sicherer.

Verwandte Artikel

• Vollständiger Sicherheitsleitfaden für Claude Code
• 7 Claude Code Sicherheitsfehler-Fallstudien
• CLAUDE.md Best Practices

Referenzen

• Claude Code Berechtigungen Offizielle Dokumentation
• Claude Code Hooks Offizielle Dokumentation