Zum Hauptinhalt springen

Berechtigungen & Berechtigungsmodi

Fortgeschritten
What you'll learn
  • Was die drei Berechtigungsentscheide (allow / ask / deny) bedeuten
  • Wie Berechtigungsregeln ein Tool plus ein Muster zuordnen
  • Die sechs Berechtigungsmodi und wann du welchen nutzt
  • Wie der auto-Modus Rückfragen durch einen Sicherheits-Klassifikator ersetzt
  • Wie du eine vernünftige Start-Allowlist baust, die Rückfragen reduziert ohne Sicherheitsverlust
  • Wo du Projekt- vs. persönliche Berechtigungsregeln speicherst

Berechtigungen entscheiden, was Claude Code tun darf, ohne dich zu fragen. Stell sie gut ein und du bekommst Flow ohne Kontrollverlust; stell sie schlecht ein und du winkst entweder alles durch oder ertrinkst in Rückfragen.

Die drei Entscheide​

Jede mögliche Aktion löst sich in einen von ihnen auf:

Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 3

Regeln ordnen typischerweise ein Tool plus ein Muster zu, z. B. allow Bash(npm run test:*) oder deny Read(./.env).

Ein Tool + Muster erlauben

Bash(npm run test:*)

Ein Tool + Muster verweigern

Read(./.env)

Berechtigungsmodi​

Ein Modus setzt die Gesamthaltung für eine Sitzung. Es gibt sechs davon. Wechsle die gängigen mit Shift+Tab durch oder setze permissions.defaultMode in den Einstellungen.

ModusLäuft ohne RückfrageVerwende, wenn
default (angezeigt als Manual)Nur LesevorgängeTägliche Arbeit, sensible Änderungen
acceptEditsLesevorgänge, Dateibearbeitungen, gängige DateisystembefehleEine vertrauenswürdige, gut umrissene Bearbeitungssitzung
planNur Lesevorgänge; schlägt vor, bearbeitet nieGroße/riskante Aufgaben — siehe Plan-Modus
autoAlles, geprüft von einem Sicherheits-KlassifikatorLange Aufgaben, bei denen die Ermüdung durch Rückfragen das eigentliche Risiko ist
dontAskNur vorab genehmigte Tools; alles andere wird verweigertAbgeschottete CI und Skripte
bypassPermissionsAlles, ohne PrüfungenNur Sandboxes/Container — niemals auf einer Maschine mit Geheimnissen

Auto-Modus​

auto ist der Mittelweg zwischen „bei allem nachfragen" und „Sicherheit abschalten". Statt dich zu fragen, prüft ein separates Klassifikator-Modell jede Aktion vor der Ausführung und blockiert alles, was über das hinausgeht, worum du gebeten hast, was Infrastruktur berührt, die es nicht kennt, oder was von feindseligen Inhalten getrieben scheint, die Claude gerade gelesen hat. Ausdrückliche ask-Regeln halten weiterhin an und fragen dich.

Er blockiert Dinge wie curl | bash, Force-Pushes, Produktions-Deployments und -Migrationen sowie das Senden von Geheimnissen an externe Endpunkte — während er Routinearbeit (lokale Bearbeitungen, Installation deklarierter Abhängigkeiten, lesende HTTP-Aufrufe, Push auf deinen eigenen Branch) direkt durchlaufen lässt. Blockiert er dieselbe Aktion wiederholt, pausiert der auto-Modus und übergibt die Rückfragen wieder an dich.

Der auto-Modus ist keine Sicherheitsgarantie — er reduziert Rückfragen, macht aber die Prüfung sensibler Vorgänge nicht überflüssig. Die Verfügbarkeit hängt von deinem Tarif, deinem Modell und (bei Team/Enterprise) einem Admin-Schalter ab.

Watch out
  • bypassPermissions gehört in eine Sandbox. Mit allen Rückfragen aus auf deiner echten Maschine zu laufen, ist der Weg, wie ein Agent etwas anfasst, das er nicht sollte. Reserviere es für wegwerfbare Umgebungen — wenn du eigentlich nur weniger Rückfragen willst, nutze stattdessen den auto-Modus. Siehe Autonome Läufe absichern unter /docs/security/hardening-autonomous-runs.

Eine vernünftige Start-Allowlist​

Das Ziel: die sicheren, wiederkehrenden Dinge vorab erlauben; destruktive Dinge auf ask oder deny halten.

Guided walkthrough1 of 3
  1. Dateien lesen, deine Test-/Lint-/Build-Befehle ausführen, git status/diff.

Speicher Projektregeln in settings.json (geteilt) und persönliche Überschreibungen in settings.local.json.

Pro tip
  • Lass es aus deinen Rückfragen lernen: genehmige denselben sicheren Befehl ein paar Mal und du weißt genau, was du zu deiner Allowlist hinzufügen sollst — so werden wiederkehrende Rückfragen zu einer einmaligen Regel.
Key takeaways
  • Drei Entscheide: allow (keine Rückfrage), ask (Standard — pausieren und bestätigen), deny (niemals).
  • Regeln ordnen ein Tool plus ein Muster zu, wie Bash(npm run test:*) oder Read(./.env).
  • Sechs Modi setzen die Sitzungshaltung: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Der auto-Modus prüft jede Aktion über einen Sicherheits-Klassifikator, statt dich zu fragen — das ist das Mittel gegen Ermüdung durch Rückfragen, nicht bypassPermissions.
  • Bau eine Allowlist: erlaube Sicheres + Wiederkehrendes, frag bei mittlerem Risiko, verweigere Destruktives.
  • Geteilte Regeln gehören in settings.json; persönliche Überschreibungen in settings.local.json.

Teste dich selbst

0/5
  1. Was macht der Standard-Entscheid 'ask' bei einer Aktion, die nicht ausdrücklich erlaubt oder verweigert ist?
  2. Welcher Berechtigungsmodus ist NUR in Sandboxes oder Containern sicher, niemals auf einer Maschine mit Geheimnissen?
  3. Du willst bei einer langen Aufgabe deutlich weniger Berechtigungs-Rückfragen, aber trotzdem ein Sicherheitsnetz. Welcher Modus?
  4. Wo solltest du geteilte Projekt-Berechtigungsregeln gegenüber persönlichen Überschreibungen speichern?
  5. Welches davon gehört in einer vernünftigen Start-Allowlist auf die 'deny'-Liste?

Weiter​