Claude Code Berechtigungen — Vollständige Referenz

Claude Code verwendet ein feines Berechtigungssystem um zu kontrollieren, welche Aktionen Claude durchführen kann. Diese Referenz behandelt alle Berechtigungsmodi, Regeltypen, Tool-spezifische Muster und Konfigurationsoptionen.

Berechtigungssystem Übersicht

Claude Code balanciert Flexibilität und Sicherheit mit einem gestuften Berechtigungssystem:

Berechtigungsmodi

Der defaultMode-Einstellung in Konfigurationsdateien bestimmt wie Claude Code Berechtigungen bewertet:

Geschützte Verzeichnisse im bypassPermissions-Modus

Auch im bypassPermissions-Modus erfordern Schreibvorgänge in diese Verzeichnisse Bestätigung:

• .git/ — Repository-Metadaten
• .claude/ — Claude Code-Konfiguration
• .vscode/ — VS Code-Einstellungen
• .idea/ — IntelliJ-Einstellungen

Ausnahme: Schreibvorgänge zu .claude/commands, .claude/agents und .claude/skills benötigen keine Bestätigung.

Regel-Syntax für Berechtigungen

Berechtigungsregeln folgen dem Format Tool oder Tool(specifier) und werden in Reihenfolge bewertet: deny → ask → allow (erste Übereinstimmung gewinnt).

Basis-Regeltypen

Alle Verwendungen eines Tools abgleichen

Ohne Klammern wird alle Verwendungen abgeglichen:

{
  "permissions": {
    "allow": ["Bash", "Read", "WebFetch"]
  }
}

Gleichwertig zu:

{
  "permissions": {
    "allow": ["Bash(*)", "Read(*)", "WebFetch(*)"]
  }
}

Feinkörnige Regeln mit Specifiern

Specifier in Klammern hinzufügen zur spezifischen Abgleichung:

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Read(./.env)",
      "WebFetch(domain:example.com)"
    ]
  }
}

Wildcard-Muster in Bash-Regeln

Bash-Regeln unterstützen Glob-Muster mit *. Wildcards können überall erscheinen:

Wort-Grenzregeln

Leerzeichen vor * ist wichtig — erzwingt Wortgrenzen:

Das Leerzeichen erstellt eine Wortgrenzanforderung.

Tool-spezifische Berechtigungsregeln

Bash

Vollständige Wildcard-Unterstützung mit Regeln bewertet vor Befehlsausführung.

Bash Wildcard-Muster

Alle Positionen-Muster:

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

Netzwerk-Befehle blockieren

Netzwerk-Befehle sind anfällig für Pattern-Constraints. Besserer Ansatz:

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "WebFetch(domain:github.com)",
      "WebFetch(domain:api.example.com)"
    ]
  }
}

Das:

1. Blockiert rohe curl/wget in Bash (deny hat Vorrang)
2. Erlaubt spezifische Domains über WebFetch-Berechtigung
3. Zuverlässiger als URL-Pattern-Matching in Bash

Read und Edit

Regeln folgen gitignore-Spezifikation für Datei-Pfad-Abgleichung.

Pfad-Muster-Typen

Wichtige Pfad-Klarstellungen

Absolute Pfade müssen doppelten Schrägstrich verwenden:

// FALSCH — das ist relativ zu Projekt-Root
"Read(/Users/alice/file)"

// RICHTIG — das ist absolut
"Read(//Users/alice/file)"

Windows-Pfade werden zu POSIX normalisiert:

C:\Users\alice → /c/Users/alice

// Abgleich aller .env auf C: Laufwerk
"Read(//c/**/.env)"

WebFetch

Kontrolle welche Domains zugänglich sind:

{
  "permissions": {
    "allow": [
      "WebFetch(domain:github.com)",
      "WebFetch(domain:api.example.com)"
    ],
    "deny": [
      "WebFetch(domain:internal-only.local)"
    ]
  }
}

Domain-Pattern-Abgleichung:

• domain:example.com — passt zu example.com und *.example.com
• Subdomains automatisch einbezogen

MCP (Model Context Protocol)

Kontrolle welche MCP-Server und Tools zugänglich sind:

Server-Level-Regeln

{
  "permissions": {
    "allow": [
      "mcp__puppeteer",
      "mcp__github",
      "mcp__puppeteer__*"
    ],
    "deny": [
      "mcp__untrusted-server"
    ]
  }
}

Tool-Level-Regeln

{
  "permissions": {
    "allow": [
      "mcp__puppeteer__puppeteer_navigate",
      "mcp__github__github_search_issues"
    ]
  }
}

Agent (Subagenten)

Kontrolle welche Agenten Claude spawnen kann:

{
  "permissions": {
    "allow": [
      "Agent(Explore)",
      "Agent(Plan)",
      "Agent(my-custom-agent)"
    ],
    "deny": [
      "Agent(dangerous-agent)"
    ]
  }
}

Berechtigungsvorrang und Bewertung

Regeln werden bewertet in Reihenfolge: deny → ask → allow. Erste Übereinstimmung gewinnt.

Vorrang-Beispiele

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

Bewertung für rm -rf /:

1. Deny-Regeln zuerst prüfen: passt zu Bash(rm *) → BLOCKIERT
2. Erreicht niemals ask/allow-Regeln

Bewertung für npm run build:

1. Deny-Regeln prüfen: keine Übereinstimmung
2. Ask-Regeln prüfen: passt zu Bash(*) → PROMPT
3. Erreicht niemals allow-Regeln

Berechtigungen mit Hooks erweitern

Custom Shell-Befehle (Hooks) können Laufzeit-Berechtigungsbewertung durchführen.

PreToolUse Hook für Berechtigungskontrolle

Hooks laufen vor Berechtigungsprompts. Output kann:

• "deny" — Tool-Aufruf blockieren
• "prompt" — Berechtigungsprompt erzwingen
• "allow" — Erlauben (aber Deny-Regeln gelten noch)

Hook-Vorrang:

• Hook gibt "deny" zurück → Blockiert
• Hook gibt "prompt" zurück → Benutzer-Prompt zeigen
• Hook gibt "allow" zurück → Berechtigungsregeln prüfen (Deny-Regeln gelten noch)

Beispiel: URLs vor Curl validieren

{
  "hooks": {
    "PreToolUse": [
      {
        "tool": "Bash",
        "matcher": "curl.*https://trusted-domain\\.com",
        "script": "echo allow"
      },
      {
        "tool": "Bash",
        "matcher": "curl",
        "script": "echo deny"
      }
    ]
  }
}

Das:

1. Erlaubt curl zu https://trusted-domain.com
2. Blockiert alle anderen curl-Befehle

Arbeitsverzeichnisse und Dateizugriff

Standard-Arbeitsverzeichnis

Claude Code kann auf Dateien im Verzeichnis wo es gestartet wurde (cwd) zugreifen.

Zugriff mit zusätzlichen Verzeichnissen erweitern

Via CLI-Start

claude code --add-dir /path/to/project --add-dir ~/Documents

Während Session

/add-dir /path/to/another/project

Beständige Konfiguration

In Konfigurationsdateien:

{
  "additionalDirectories": [
    "/full/path/to/project1",
    "~/Documents/project2"
  ]
}

Wie Berechtigungen mit Sandboxing interagieren

Berechtigungen und Sandboxing sind komplementäre Sicherheitsebenen:

Berechtigungen

• Kontrolle welche Tools Claude Code verwenden kann
• Bestimmung welche Dateien und Domains zugänglich sind
• Gelten für alle Tools (Bash, Read, Edit, WebFetch, MCP, Agent)

Sandboxing

• Bietet OS-Level-Durchsetzung
• Beschränkt Bash-Tool Filesystem und Netzwerk-Zugriff
• Gilt nur für Bash-Befehle und ihre Child-Prozesse

Kombinierte Verteidigung

{
  "permissions": {
    "deny": ["Bash(curl *)"],
    "allow": ["WebFetch(domain:github.com)"]
  },
  "sandbox": {
    "network": {
      "allowedDomains": ["github.com"]
    }
  }
}

Das:

1. Berechtigungs-Layer blockiert rohe curl-Versuche
2. Sandbox blockiert jeden Bash-Netzwerk-Zugriff außerhalb erlaubter Domains
3. WebFetch zu GitHub erlaubt über Berechtigungsregel

Managed Settings

Organisationen können Berechtigungen über alle Maschinen durchsetzen:

Managed-Only-Einstellungen

Diese Einstellungen können NUR in Managed-Konfiguration gesetzt werden:

Konfiguration mit Managed-Regeln nur

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "allow": [
      "Read",
      "WebFetch(domain:company.com)",
      "Bash(git *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(sudo *)"
    ]
  }
}

Wenn allowManagedPermissionRulesOnly: true:

• Benutzer und Projekt-Settings können keine allow, ask oder deny Regeln hinzufügen
• Nur Managed-Settings-Regeln gelten
• Bietet Organisations-breite Sicherheitsrichtlinie

Beispiele

Beispiel 1: Strikte Sicherheitskonfiguration

Für vertrauenswürdiges Code-Review:

{
  "defaultMode": "plan",
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash",
      "Edit",
      "WebFetch"
    ]
  }
}

Claude kann:

• Dateien lesen
• Mit Grep suchen
• Dateien auflisten mit Glob

Claude kann nicht:

• Befehle ausführen
• Dateien ändern
• Externe URLs zugänglich

Beispiel 2: Vertrauenswürdige Entwicklung

Für lokale Entwicklung:

{
  "defaultMode": "acceptEdits",
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Bash(git *)",
      "Edit",
      "Read",
      "WebFetch"
    ],
    "deny": [
      "Bash(sudo *)",
      "Bash(rm *)"
    ]
  }
}

Claude kann:

• npm und git-Befehle ausführen
• Dateien frei bearbeiten
• Alles lesen
• Web-Ressourcen zugänglich

Claude kann nicht:

• Mit sudo ausführen
• Dateien löschen

Beispiel 3: Enterprise-Deployment

Managed Settings für Organisation:

{
  "allowManagedPermissionRulesOnly": true,
  "disableBypassPermissionsMode": "disable",
  "permissions": {
    "allow": [
      "Read",
      "WebFetch(domain:github.com)",
      "WebFetch(domain:company.com)",
      "Bash(npm *)",
      "Bash(git *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(sudo *)",
      "Edit(/etc/**)"
    ]
  }
}

Durchsetzt:

• Benutzer kann Berechtigungsregeln nicht überschreiben
• Netzwerk-Zugriff auf genehmigte Domains beschränkt
• System-Dateien geschützt
• Kein bypassPermissions-Modus verfügbar

Siehe auch

• Settings-Referenz: Komplette Konfigurationsreferenz
• Sandboxing: OS-Level Filesystem und Netzwerk-Isolation
• Hooks-Anleitung: Custom Permission-Scripts
• MCP: Model Context Protocol Konfiguration
• Sicherheit: Sicherheits-Best Practices

Quellen und Links

• Permissions
• Sandboxing
• Official Claude Code Documentation
• CLI Reference
• GitHub (Anthropic)
• Anthropic SDK Python
• Anthropic SDK TypeScript
• Claude Code Docs Index