Zum Hauptinhalt springen

Berechtigungen und Berechtigungsmodi

Fortgeschritten
What you'll learn
  • Was die drei Berechtigungsurteile (allow / ask / deny) bedeuten
  • Wie Berechtigungsregeln ein Tool mit einem Muster abgleichen
  • Die sechs Berechtigungsmodi und wann man welchen nutzt
  • Warum der auto-Modus jetzt der Startmodus für interaktive Sitzungen ist — und wie man ihn abwählt
  • Wie der auto-Modus Rückfragen durch einen Sicherheitsklassifikator ersetzt
  • Wie man eine vernünftige Start-Allowlist aufbaut, die Rückfragen reduziert, ohne Sicherheit zu verlieren
  • Wo Projekt- und persönliche Berechtigungsregeln gespeichert werden

Berechtigungen legen fest, was Claude Code tun darf, ohne bei dir nachzufragen. Gut eingestellt bekommst du Flow ohne Kontrollverlust; schlecht eingestellt winkst du entweder alles durch oder ertrinkst in Rückfragen.

Die drei Urteile​

Jede mögliche Aktion führt zu einem von diesen:

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 gleichen in der Regel ein Tool mit einem Muster ab, z. B. allow Bash(npm run test:*) oder deny Read(./.env).

Ein Tool + Muster erlauben

Bash(npm run test:*)

Ein Tool + Muster verbieten

Read(./.env)

Berechtigungsmodi​

Ein Modus legt die Grundhaltung einer Sitzung fest. Es gibt sechs. Die gängigen schaltest du mit Shift+Tab durch, oder du setzt permissions.defaultMode in den Einstellungen.

ModusLäuft ohne RückfrageEinsatz
default (angezeigt als Manual)Nur LesezugriffeAlltagsarbeit, sensible Änderungen
acceptEditsLesen, Dateibearbeitungen, gängige DateisystembefehleEine vertrauenswürdige, klar abgegrenzte Bearbeitungssitzung
planLesen sowie vom Klassifikator genehmigte Befehle, wenn der auto-Modus verfügbar ist; ändert nie deinen QuellcodeGroße/riskante Aufgaben — siehe Plan Mode
auto (seit v2.1.283 der Startmodus für interaktive Sitzungen)Alles, geprüft von einem SicherheitsklassifikatorLange Aufgaben, bei denen Rückfrage-Müdigkeit das eigentliche Risiko ist
dontAskDateilesezugriffe in deinen Arbeitsverzeichnissen und vorab genehmigte Tools; alles, was eine Rückfrage auslösen würde, wird verweigertAbgeriegelte CI und Skripte
bypassPermissionsAlles, ohne PrüfungenNur Sandboxes/Container — niemals auf einem Rechner mit Geheimnissen

Der auto-Modus ist jetzt der Standard von Claude Code​

Seit Claude Code v2.1.283 ist auto bei allen Tarifen und Anbietern der eingebaute Startmodus für interaktive Terminal- und VS-Code-Sitzungen. In früheren Versionen war er ab dem 14. August 2026 nur bei Pro-, Max- und Team-Tarifen der Standard für neue Sitzungen. Anthropics Begründung (aus eigenen Tests mit über 1.000 zahlenden Nutzern): Der Klassifikator erkannte 89 % der schädlichen Aktionen gegenüber 13,6 % bei manueller Prüfung — weil sich die Nutzer daran gewöhnt hatten und etwa 97 % der manuellen Rückfragen ungelesen bestätigten.

Zwei Ausnahmen wahren die Absicht:

  • Wenn du permissions.defaultMode in deinen Benutzereinstellungen gesetzt hast, bleibt es bestehen, es sei denn, du akzeptierst eine einmalige Umschaltaufforderung in der App.
  • Wenn deine Organisation den Standard verwaltet (verwaltete Einstellungen bei Team/Enterprise), ändert sich nichts automatisch.

Du kannst die Modi jederzeit mitten in der Sitzung mit Shift+Tab durchschalten. Eine verwandte Änderung, die bei diesen Tarifen bereits gilt: Die Klassifikator-Aufrufe des auto-Modus zählen nicht mehr auf deine Nutzungslimits.

Früh umsteigen (vor dem 14. Aug.) — auto als Standard setzen

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

Nach dem 14. Aug. beim alten Rückfrageverhalten bleiben

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

Wie der auto-Modus tatsächlich funktioniert​

auto ist der Mittelweg zwischen „bei allem nachfragen“ und „Sicherheit abschalten“. Statt dich zu fragen, prüft ein separates Klassifikatormodell jede Aktion vor der Ausführung und blockiert alles, was über das Erbetene hinaus eskaliert, Infrastruktur berührt, die es nicht kennt, oder von feindlichen Inhalten getrieben scheint, die Claude gerade gelesen hat. Ausdrückliche ask-Regeln halten weiterhin an und fragen dich.

Blockiert werden etwa curl | bash, Force-Pushes, Produktions-Deployments und -Migrationen, rm -rf auf nicht aufgelösten Variablen, Manipulationen am Transkript, destruktive Git-Befehle, die nicht committete Arbeit verwerfen, und das Senden von Geheimnissen an externe Endpunkte — Routinearbeit (lokale Änderungen, Installation deklarierter Abhängigkeiten, schreibgeschütztes HTTP, Push auf deinen eigenen Branch) läuft dagegen direkt durch. Wird dieselbe Aktion wiederholt blockiert, pausiert der auto-Modus und gibt die Rückfragen an dich zurück.

Der auto-Modus ist keine Sicherheitsgarantie — er reduziert Rückfragen, ersetzt aber nicht die Prüfung sensibler Vorgänge. Die Verfügbarkeit hängt von Tarif, Modell und (bei Team/Enterprise) einem Admin-Schalter ab. Wenn du wirklich unbeaufsichtigt arbeitest (Cron, Cloud-Sitzungen, CI), kombiniere ihn mit Hardening Autonomous Runs — auto ist trotzdem nicht bypassPermissions.

Watch out
  • bypassPermissions gehört in eine Sandbox. Mit abgeschalteten Rückfragen auf deinem echten Rechner zu arbeiten, ist der Weg, auf dem ein Agent etwas anfasst, was er nicht sollte. Reserviere es für Wegwerf-Umgebungen — wenn du eigentlich nur weniger Rückfragen willst, nutze stattdessen den auto-Modus. Siehe Hardening Autonomous Runs unter /docs/security/hardening-autonomous-runs.

Eine vernünftige Start-Allowlist​

Das Ziel: das Sichere und Wiederkehrende vorab erlauben; Destruktives auf ask oder deny lassen.

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

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

Pro tip
  • Lass es aus deinen Rückfragen lernen: Bestätige denselben sicheren Befehl ein paar Mal, und du weißt genau, was in deine Allowlist gehört — so werden wiederholte Rückfragen zu einer einmaligen Regel.
Key takeaways
  • Drei Urteile: allow (keine Rückfrage), ask (Standard — anhalten und bestätigen), deny (niemals).
  • Regeln gleichen ein Tool mit einem Muster ab, etwa Bash(npm run test:*) oder Read(./.env).
  • Sechs Modi legen die Sitzungshaltung fest: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Seit v2.1.283 ist auto bei allen Tarifen der Startmodus für interaktive Terminal- und VS-Code-Sitzungen; ein selbst gesetzter defaultMode bleibt bestehen, und von der Organisation verwaltete Standards bleiben unberührt.
  • Der auto-Modus prüft jede Aktion mit einem Sicherheitsklassifikator, statt dich zu fragen — das ist das Mittel gegen Rückfrage-Müdigkeit, nicht bypassPermissions.
  • Baue eine Allowlist: Sicheres und Wiederkehrendes erlauben, bei mittlerem Risiko fragen, Destruktives verbieten.
  • Geteilte Regeln gehören in settings.json; persönliche Überschreibungen in settings.local.json.

Teste dich selbst

0/6
  1. Was bewirkt das Standardurteil 'ask' bei einer Aktion, die weder ausdrücklich erlaubt noch verboten ist?
  2. Welcher Berechtigungsmodus ist NUR in Sandboxes oder Containern sicher, niemals auf einem Rechner mit Geheimnissen?
  3. Du willst bei einer langen Aufgabe deutlich weniger Berechtigungsrückfragen, aber trotzdem ein Sicherheitsnetz. Welcher Modus?
  4. Wo speicherst du geteilte Projekt-Berechtigungsregeln und wo persönliche Überschreibungen?
  5. Was davon gehört in einer vernünftigen Start-Allowlist auf die 'deny'-Liste?
  6. Was passiert am 14. August 2026 bei einem Pro-Tarif, wenn du permissions.defaultMode in deinen Benutzereinstellungen bereits auf 'default' gesetzt hattest?

Weiter​