Claude Code Berechtigungen

Problem: Claude Code, das bei jeder Dateibearbeitung und jedem Befehl nach Erlaubnis fragt, ruiniert deinen Flow und kostet Zeit.

Quick Win: Drücke Shift+Tab, um im Handumdrehen zwischen Berechtigungsmodi zu wechseln:

# Press Shift+Tab to cycle:
normal → auto-accept edits → plan mode → normal

Du kannst das neu belegen, wenn Shift+Tab in deinem Terminal Konflikte verursacht. Jetzt steuerst du den Flow, ohne eine Config-Datei anzufassen. Pass den Modus an die Aufgabe an, und der Unterbrechungszyklus hört auf.

Alle Berechtigungsmodi

Claude Code hat fünf Berechtigungsmodi, jeder für eine andere Art von Arbeit gebaut. Drei Kernmodi wechselst du per Shift+Tab, zwei weitere leben in der Config.

Normalmodus (default)

Der Normalmodus fragt vor jeder potenziell gefährlichen Operation nach. Du siehst Bestätigungsdialoge für:

• Dateibearbeitungen und Änderungen
• Ausführung von Terminal-Befehlen
• Systemoperationen
• Verzeichniswechsel

Sicherheit vor Geschwindigkeit. Nutze ihn für:

• Produktionscode
• Codebases, die du nicht gut kennst
• Neue Techniken erlernen
• Hochriskante Operationen

Auto-Accept-Modus (acceptEdits)

Der Auto-Accept-Modus lässt die Berechtigungsabfragen für Dateibearbeitungen für den Rest der Session weg. Claude führt genehmigte Operationen direkt aus.

Aktiviere ihn, indem du Shift+Tab drückst, bis die UI "auto-accept edit on" zeigt.

Am besten geeignet für:

• Große Refactoring-Sessions
• Arbeit nach einem klar definierten Plan
• Recherche und Dokumentationsarbeit
• Wiederholte Bearbeitungen über viele Dateien hinweg

Plan-Modus (plan)

Der Plan-Modus sperrt Claude auf reine Leseoperationen. Claude kann frei analysieren, aber nichts auf der Festplatte ändert sich.

Ideal für:

• Erste Erkundung einer Codebase
• Architekturanalyse
• Planung komplexer Features
• Code-Review-Sessions

Don't-Ask-Modus (dontAsk)

Der Don't-Ask-Modus lehnt jede Tool-Nutzung automatisch ab, außer das Tool ist bereits via /permissions oder einer permissions.allow-Regel vorab genehmigt. Keine Abfragen. Alles, was nicht auf der Allow-Liste steht, wird still abgelehnt.

Am besten geeignet für:

• CI/CD-Pipelines ohne Menschen zur Bestätigung
• Gesicherte Umgebungen mit einem bekannten Set erlaubter Operationen
• Claude gegen eine strikte, vorab erstellte Berechtigungsrichtlinie laufen lassen

Bypass-Permissions-Modus (bypassPermissions)

Der Bypass-Modus überspringt jede Berechtigungsprüfung. Claude führt jedes Tool ohne Nachfrage aus.

# CLI flag equivalent:
claude --dangerously-skip-permissions

Aktiviere das nur in vollständig isolierten Umgebungen wie Containern, VMs oder kurzlebigen CI-Runnern, wo Claude keinen dauerhaften Schaden anrichten kann. Der Sinn des Modus ist Automatisierung an Orten, wo die Umgebung selbst die Sicherheitsgrenze ist.

Warnung: Admins können diesen Modus komplett deaktivieren, indem sie disableBypassPermissionsMode in den verwalteten Einstellungen auf "disable" setzen. Wenn deine Organisation das blockiert, funktioniert weder die Einstellung noch das CLI-Flag.

Einen dauerhaften Standardmodus festlegen

Statt bei jeder Session Modus zu wechseln, pinne deinen bevorzugten Standard in settings.json:

{
  "defaultMode": "acceptEdits"
}

Gültige Werte: default, acceptEdits, plan, dontAsk, bypassPermissions. Die Einstellung bleibt über Sessions hinweg erhalten, sodass du immer dort startest, wo du willst.

Berechtigungen mit /permissions verwalten

Statt JSON-Dateien manuell zu bearbeiten, öffnet der eingebaute /permissions-Befehl eine interaktive Ansicht:

# Launch the interactive permissions UI
/permissions

Von dort kannst du:

• Sehen, welche Tools aktuell erlaubt und abgelehnt sind
• Zugriff auf bestimmte Tools oder Muster gewähren
• Tools blockieren, die du nicht willst
• Sehen, aus welcher Settings-Datei jede Regel stammt
• Änderungen vornehmen, ohne Claude Code neu zu starten

Berechtigungsregel-Syntax

Regeln folgen dem Format Tool oder Tool(specifier). Sie leben im permissions-Objekt deiner settings.json:

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "deny": ["Bash(rm *)"],
    "ask": ["Bash(git push *)"]
  }
}

Drei Regeltypen steuern das Verhalten:

• Allow-Regeln lassen Claude das Tool ohne Nachfrage ausführen
• Ask-Regeln fragen bei jeder Nutzung nach Bestätigung
• Deny-Regeln blockieren das Tool vollständig

Regeln werden in Reihenfolge ausgewertet: erst deny, dann ask, dann allow. Die erste passende Regel gewinnt, also schlägt ein Deny immer ein Allow.

Alle Nutzungen eines Tools erfassen

Nur den Tool-Namen verwenden, um jede Ausführung abzudecken:

Bash(*) ist dasselbe wie Bash und erfasst alle Bash-Befehle.

Bash-Wildcard-Muster

Bash-Regeln nehmen Glob-Muster mit *. Wildcards können überall in der Regel stehen:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": ["Bash(git push *)"]
  }
}

Wortgrenze-Semantik: Das Leerzeichen vor * ist wichtig. Bash(ls *) passt auf ls -la, aber nicht auf lsof. Bash(ls*) passt auf beide.

Shell-Operator-Bewusstsein: Claude Code kennt Shell-Operatoren. Eine Regel wie Bash(safe-cmd *) passt nicht auf safe-cmd && malicious-cmd. Das stoppt Chained-Command-Exploits.

Warnung: Bash-Muster, die versuchen, Befehlsargumente einzuschränken, sind fragil. Eine Regel wie Bash(curl http://github.com/ *) soll curl auf GitHub-URLs beschränken, aber sie erfasst keine Variationen (Optionen vor der URL, andere Protokolle, Variablenexpansion). Für echte URL-Filterung: Bash-Netzwerk-Tools blockieren und stattdessen WebFetch mit Domain-Regeln nutzen.

Read- und Edit-Muster

Read- und Edit-Regeln verwenden gitignore-ähnliche Pfadmuster, vier Arten:

Wichtig: Ein Muster wie /Users/alice/file ist kein absoluter Pfad. Es wird relativ zu deiner Settings-Datei aufgelöst. Nutze //Users/alice/file für einen echten absoluten Pfad.

In Gitignore-Mustern passt * auf Dateien in einem einzigen Verzeichnis, während ** rekursiv passt. Um Zugriff auf alle Dateien zu erlauben, lass die Klammern weg: Read, Edit oder Write.

WebFetch-Domain-Regeln

Steuere, von welchen Domains Claude Inhalte abrufen kann:

{
  "permissions": {
    "allow": ["WebFetch(domain:docs.anthropic.com)"],
    "deny": ["WebFetch(domain:internal.company.com)"]
  }
}

MCP-Tool-Muster

Steuere MCP-Server-Zugriff auf Server- oder Tool-Ebene:

Task-(Subagent-)Regeln

Steuere, welche Subagents Claude über Task(AgentName) starten kann:

{
  "permissions": {
    "deny": ["Task(Explore)"]
  }
}

Agent-Namen umfassen Explore, Plan und Verify. Das --disallowedTools-CLI-Flag kann bestimmte Agents auch beim Start deaktivieren.

Berechtigungen mit Hooks erweitern

PreToolUse-Hooks laufen vor dem Berechtigungssystem und können Tool-Aufrufe zur Laufzeit genehmigen, ablehnen oder umschreiben. Das gibt dir programmatische Kontrolle zusätzlich zu statischen Regeln.

Wie Berechtigungen mit Sandboxing zusammenarbeiten

Berechtigungen und Sandboxing stapeln sich als zwei ergänzende Sicherheitsebenen (Defense-in-Depth):

• Berechtigungen steuern, welche Tools Claude nutzen kann und auf welche Dateien oder Domains sie zugreifen darf. Sie gelten für jedes Tool (Bash, Read, Edit, WebFetch, MCP und den Rest).
• Sandboxing fügt OS-Ebenen-Durchsetzung obendrauf hinzu und begrenzt, was Bash-Befehle auf Dateisystem- und Netzwerkebene erreichen können. Es gilt nur für Bash-Befehle und deren Kindprozesse.

Beides zusammen für die stärkste Absicherung nutzen:

• Permission-Deny-Regeln verhindern, dass Claude überhaupt versucht, auf eingeschränkte Ressourcen zuzugreifen
• Sandbox-Einschränkungen halten Bash-Befehle innerhalb definierter Grenzen, auch wenn ein Prompt-Injection Claudes Entscheidungsfindung umgeht
• Dateisystemeinschränkungen in der Sandbox nutzen Read- und Edit-Deny-Regeln (keine separate Sandbox-Konfiguration)
• Netzwerkeinschränkungen kombinieren WebFetch-Berechtigungsregeln mit der allowedDomains-Liste der Sandbox

Aktiviere Sandboxing mit dem /sandbox-Befehl. Auf macOS funktioniert es direkt mit Seatbelt. Auf Linux und WSL2 installiere zuerst bubblewrap und socat.

Verwaltete Berechtigungseinstellungen

Für Organisationen, die zentrale Kontrolle brauchen, können Admins verwaltete Settings-Dateien bereitstellen, die Nutzer und Projekte nicht überschreiben können:

Speicherorte verwalteter Einstellungsdateien:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux/WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Das sind systemweite Pfade (nicht Nutzer-Home-Verzeichnisse) und erfordern Admin-Rechte. Sie verwenden dasselbe Format wie normale Settings-Dateien, haben aber die höchste Priorität in der Settings-Hierarchie.

Strategien für Entwicklungsszenarien

Frühe Entwicklung (Normalmodus nutzen)

Du startest ein neues Projekt oder erkundest unbekannten Code:

• Jede Berechtigung manuell halten
• Jeden vorgeschlagenen Change prüfen
• Beobachten, wie Claude das Problem angeht
• Vertrauen in die KI-Entscheidungen aufbauen

Aktive Entwicklung (Auto-Accept nutzen)

Mitten in einer intensiven Coding-Session:

• Auto-Accept für vertrauenswürdige Dateitypen aktivieren
• Gängige Befehle erlauben (npm, git status)
• Abfragen für Systemoperationen beibehalten
• Unterbrechungsfreien Workflow genießen

Code Review (Plan-Modus nutzen)

Wenn du eine bestehende Codebase analysierst:

• Auf Plan-Modus wechseln für Sicherheit
• Claude erkunden lassen, ohne Dateien anzufassen
• Analysen und Empfehlungen erstellen lassen
• Modus nur wechseln, wenn du bereit zur Implementierung bist

Häufige Berechtigungs-Fehler

Zu viele Berechtigungen: Vermeide den bypassPermissions-Modus, außer du bist in einem vollständig isolierten Container oder einer VM. Der dontAsk-Modus mit expliziten Allow-Regeln ist die sicherere "Hands-off"-Option.

Zu wenige Berechtigungen: Das hundertste Mal auf "Allow" klicken macht den Sinn zunichte. Nutze /permissions, um wiederkehrende Operationen vorab zu genehmigen, oder wechsle während der aktiven Entwicklung auf acceptEdits.

Modus-Verwirrung: Prüfe deinen aktuellen Modus, bevor du mit der Arbeit anfängst. Der Indikator liegt in der UI. Setze defaultMode in settings.json, wenn du immer den gleichen Startmodus willst.

Pauschale Berechtigungen: Erlaube nicht alle Bash-Befehle. Nutze spezifische Muster wie Bash(npm run *), um den Scope eng zu halten. Und denk dran: Deny-Regeln schlagen immer Allow-Regeln.

Fragile Argument-Muster: Verlasse dich nicht auf Bash-Regeln, um Befehlsargumente einzuschränken (wie curl auf bestimmte URLs zu pinnen). Nutze WebFetch-Domain-Regeln für echte URL-Filterung.

Was als nächstes kommt

Fünf Berechtigungsmodi für fünf Arten von Arbeit. default für Sicherheit, acceptEdits für Produktivität, plan für Erkundung, dontAsk für Automatisierung und bypassPermissions für isolierte Umgebungen. Wähle den Modus, der zur Aufgabe passt, und schichte Sandboxing obendrauf für Defense-in-Depth.

Weiterführende Lektüre:

• Berechtigungsaufrufe mit Hooks und dem Permission Hook automatisieren
• Benutzerdefinierte Tastenbelegungen für schnelleres Moduswechseln
• Feedback-Loops für schnellere Iteration
• Todo-Workflows für Aufgabenverfolgung
• Git-Integration für Versionskontrolle
• Konfigurationsgrundlagen für settings.json und tieferes Setup