Wie in Kapitel 1 beschrieben, durchläuft Claude Code bei jedem Werkzeugaufruf eine Rechte-Schranke. Wer das für einen einzigen Drehknopf hält, dreht ihn ganz nach links, sobald es lästig wird. Tatsächlich sind es drei Dinge mit verschiedenen Rollen: die Häufigkeit der Rückfragen, die Freigabe je Werkzeug und die Isolierung auf Ebene des Betriebssystems. Ziehen Sie das eine an, dürfen Sie das andere lockern – „sicher oder schnell“ ist keine Wahl zwischen zweien.

Delegieren ist kein Entweder-oder

Der Ausgangspunkt ist nicht der Name eines Modus, sondern die Frage: „Wo wird es bei dieser Arbeit unwiederbringlich?“ Es gibt drei Anhaltspunkte.

  • Lässt es sich zurücknehmen – bei einer Änderung, die Git zurücknehmen kann, ist der Verlust klein. Endgültiges Löschen, ein erzwungener Push und die Zerstörung einer Datenbank lassen sich nicht zurücknehmen
  • Wie weit reicht es – bleibt es im Arbeitsverzeichnis, oder reicht es bis in die Produktion, in einen geteilten Branch oder in fremde Umgebungen
  • Berührt es Geheimnisse – ein Abfluss entsteht, sobald lesen können und nach außen senden können gleichzeitig gegeben sind

Lästig sind die Operationen, die auf allen drei Achsen ungefährlich sind (Tests, Formatieren, lokales Bearbeiten), und gefährlich sind die, die selten vorkommen. Wer pauschal lockert, öffnet auch die gefährliche Seite. Das Gerüst lautet: nach Häufigkeit lockern, nach Wesensart anziehen.

Rechtemodi – was sich wirklich ändert

Der größte Drehknopf ist der Rechtemodus, er legt den groben Rahmen für die Häufigkeit der Rückfragen fest. Umgeschaltet wird mit Shift+Tab (die Erläuterung steht unter Die Rechtemodi von Claude Code).

Rechte abfragen (default)

Lesen läuft automatisch, Änderungen und Befehlsausführung werden jedes Mal abgefragt. Die Voreinstellung für ein Repository, das Sie zum ersten Mal anfassen.

Änderungen bestätigen (acceptEdits)

Bestätigt Änderungen im Arbeitsordner automatisch. Alles außerhalb, geschützte Pfade und andere Befehle werden abgefragt.

Planmodus (plan)

Es untersucht, ändert aber keinen Quellcode. Erst nach Zustimmung zum Plan geht es an die Ausführung.

Automatikmodus (auto)

Ein separates Bewertungsmodell sieht sich jede Operation vor der Ausführung an und hält nur die gefährlichen auf. An Nutzungsbedingungen geknüpft.

Rechte umgehen (bypassPermissions)

Weder Rückfragen noch Sicherheitsprüfungen werden durchlaufen. Nur für isolierte Umgebungen. Nur wirksam, wenn mit dem dafür vorgesehenen Schalter gestartet wurde.

Es gibt außerdem das reine Konfigurationsmittel dontAsk (führt nur die Erlaubnisliste und schreibgeschützte Befehle aus und verweigert alles Übrige).

Achten Sie auch auf die geschützten Pfade. Schreibzugriffe auf .git, .claude und Ihre Shell-Konfiguration werden in den gewöhnlichen Modi nicht automatisch bestätigt. Den Standardmodus können Sie in der Konfiguration hinterlegen, aber allein der Automatikmodus wird in Projekteinstellungen ignoriert – eine Linie, die verhindert, dass ein Repository ihn von sich aus einschalten kann.

Der Automatikmodus ist kein „schnellerer Standard“

Die Rückfragen verschwinden fast ganz, aber nichts läuft frei herum: Das Bewertungsmodell hält Operationen auf, die über den Umfang Ihres Auftrags hinausgehen, Operationen, die ihm unbekannte Infrastruktur berühren, und Operationen, die von gelesenen Inhalten gesteuert werden. Leicht durch kommen Dateiarbeiten innerhalb des Arbeitsordners und schreibgeschütztes HTTP. Aufgehalten werden das Versenden vertraulicher Daten nach außen, Deployments in die Produktion und zerstörerische Git-Operationen.

Im Gespräch genannte Grenzen werden nicht gespeichert. „Nicht pushen“ kann die Grundlage für eine Blockade sein, aber es wird jedes Mal aus dem aktuellen Gespräch neu gelesen – fällt es bei einer Verdichtung heraus, verschwindet die Grenze mit ihm. Hinzu kommt, dass der Automatikmodus eine Research Preview ist und Anthropic selbst sagt, dass er die Rückfragen verringert, ohne Sicherheit zu garantieren. Er ist kein Ersatz für ein Review.

Warum Sie auch im Umgehungsmodus gefragt werden

Sie haben --dangerously-skip-permissions übergeben, das die Rückfragen eigentlich überspringen sollte, und Claude fragt trotzdem „darf ich das ausführen?“ Es ist nichts kaputt. Die Rechte haben zwei voneinander unabhängige Schichten, und das Umgehen kann nur eine davon entfernen (warum Claude auch im Umgehungsmodus nach Erlaubnis fragt).

Schicht 1: die Oberfläche der Werkzeugrechte (entfernbar)

„Darf ich diese Datei ändern?“ – der interaktive Dialog, der unmittelbar vor einem Werkzeugaufruf erscheint. Etwas, das das Programm Claude Code anzeigt.

Schicht 2: Claudes eigenes Sicherheitsurteil (nicht entfernbar)

„Das ändert die Produktionsdatenbank, soll ich fortfahren?“ – eine Rückfrage, die als Gesprächstext zurückkommt. Sie entspringt den Handlungsgrundsätzen des Modells, also hält kein Schalter sie auf.

Unterscheiden können Sie beides daran, ob es Oberfläche oder Antworttext ist. Was Schicht 2 auslöst, liegt nahe an den drei Achsen von oben – unumkehrbar, weitreichend, hohes Sicherheitsrisiko. Bei einer endgültigen Löschung, einem erzwungenen Push oder einer Migration gegen die Produktion hält Claude auch dann inne, wenn die Rechte weit offen stehen.

Das ist Entwurf, kein Defekt. Was das Umgehen aushändigt, ist der Schlüssel zur Benutzung der Werkzeuge, kein Schlüssel, der Claudes Urteil abschaltet. Schicht 2 lässt sich nicht auf null bringen.

Die Häufigkeit können Sie senken. Schreiben Sie in die CLAUDE.md nur Voraussetzungen, die Sie als Tatsache formulieren können, und formulieren Sie Aufträge konkret – „lösche die .log-Dateien in /tmp/“ zieht weniger Rückfragen nach sich als „räum das auf“. Aber das Umgehen ist nicht die Antwort auf „die Rückfragen nerven“ (die Risiken des Umgehungsmodus und wie man ihn sicher einsetzt).

Regeln in der settings.json – dieselbe Rückfrage nie zweimal beantworten

Wenn ein Modus die Gesamthäufigkeit ist, dann sind die Rechteregeln die Ausnahmen je Werkzeug und je Befehl. Sie schreiben allow (keine Rückfrage) / ask (jedes Mal eine Rückfrage) / deny (verboten) in die settings.json und können sie so teilen (Rechteregeln (allow/ask/deny) einrichten).

Ausgewertet wird in der Reihenfolge deny → ask → allow, und die erste Übereinstimmung gewinnt; höhere Genauigkeit ändert die Reihenfolge nicht – ein breites deny auf Bash(aws *) schlägt ein konkretes allow auf Bash(aws s3 ls). Ein deny kann keine Ausnahmen tragen. „Ich habe es erlaubt und werde trotzdem gefragt“ heißt meistens nur, dass ein anderes ask zuerst greift. Weil ask auch im Automatikmodus eine Rückfrage erzwingt, gehören Operationen, die Sie nicht rückgängig machen können, genau dorthin.

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

Auch der Ablageort hat eine Rangfolge. Vom Stärksten an: verwaltete Einstellungen (nicht überschreibbar) → CLI → settings.local.json → settings.json → ~/.claude/settings.json. Aber ein deny auf irgendeiner Ebene schlägt immer ein allow auf jeder anderen Ebene. In den Angaben gilt ein Leerzeichen plus * als Wortgrenze (Bash(ls *) trifft auf ls -la zu, auf lsof aber nicht).

Wovor die Regeln Sie nicht schützen

Eine Regel sieht ausschließlich den Text des Befehls, der ausgeführt werden soll, und jeder Weg, der aus diesem Text heraustritt, zieht ungehindert daran vorbei.

  • Indirekter Zugriff lässt sich nicht verhindern – ein deny auf Read(.env) wirkt gegen die eingebauten Dateiwerkzeuge und gegen cat, aber es wirkt nicht gegen ein Skript, das die Datei öffnet
  • Umgebungs-Runner verbergen ihren Inhalt – devbox run * und docker exec führen ihre Argumente wortwörtlich aus, ein allow auf Bash(devbox run *) erlaubt also auch devbox run rm -rf .
  • URLs über Argumente einzuschränken ist brüchig – Umsortieren oder das Auflösen von Variablen schlüpft hindurch. curl und wget rundheraus zu verbieten und die erlaubten Ziele mit WebFetch(domain:) zu benennen, ist stabiler

„Lies die .env nicht“ in die CLAUDE.md zu schreiben, ist keine Regel. Die CLAUDE.md ändert, was Claude zu tun versucht; sie ändert nicht, was ihm erlaubt ist. Das ändern Regeln, Modi und der PreToolUse-Hook aus Kapitel 6 (deny und ask werden unabhängig davon ausgewertet, was der Hook zurückgibt).

Die Sandbox – was sie einzäunen kann und was nicht

Was die Wege verschließt, welche die Regeln nicht erreichen, ist die Sandbox – statt zu fragen „was soll ich bestätigen?“, zäunt sie vorab ein, „wie weit darf überhaupt etwas reichen?“. Durchgesetzt wird das nicht von Claude, sondern vom Betriebssystem (dem Kernel), die Grenze verschiebt sich also auch dann nicht, wenn ein bereits erlaubter Befehl mehr tut, als sein Name vermuten lässt (der vollständige Leitfaden zur Sandbox von Claude Code).

1. Isolierung des Dateisystems

Geschrieben werden darf nur im Arbeitsverzeichnis und in einem temporären Ordner (Anfangswert). ~/.bashrc und Systembereiche lassen sich nicht umschreiben.

2. Isolierung des Netzwerks

Der Anfangszustand ist grundsätzliche Verweigerung mit null Zielen. Beim Verbinden zu einer neuen Domain kommt eine Rückfrage, und wer sie in allowedDomains einträgt, wird nicht mehr gefragt.

Diese beiden gehören immer zusammen – mit nur einer davon gelangt ein Geheimnis, das gelesen werden konnte, nach draußen. Es gibt zwei Wege der Zustimmung. Der Modus der automatischen Freigabe führt das Bash im Inneren ohne Rückfrage aus, der gewöhnliche Rechtemodus isoliert und lässt die Rückfragen trotzdem durchlaufen. Auch bei automatischer Freigabe gilt: deny hat immer Vorrang, ein rm, das auf einen wichtigen Pfad zielt, wird bestätigt, und ein inhaltlich bestimmtes ask erzwingt weiterhin eine Rückfrage.

Achtung, es gibt zwei Dinge, die „automatisch“ heißen. Der Modus der automatischen Freigabe der Sandbox bedeutet „durchlassen, weil die Grenze des Betriebssystems es einschließt“, der Automatikmodus (auto) der Rechte bedeutet „durchlassen, weil das Bewertungsmodell es geprüft hat“.

Erst lernen, was sie nicht schützt

Die Sandbox ist keine vollständige Isolierung. Das im Vagen zu lassen und die automatische Freigabe dauerhaft eingeschaltet zu halten, ist der gefährlichste Zustand überhaupt.

  • Sie erfasst nur Bash und dessen Kindprozesse – die eingebauten Read, Edit und Write, MCP-Server und Hooks liegen außerhalb (die steuern Sie über Rechteregeln). Wollen Sie den gesamten Prozess umschließen, nehmen Sie @anthropic-ai/sandbox-runtime
  • Der Standard für das Lesen ist weit – eingezäunt wird vor allem das Schreiben, und ~/.ssh sowie ~/.aws/credentials sind so, wie es steht, lesbar. Schließen Sie sie mit denyRead
  • Zu viel zu erlauben wird zum Loch – der Verkehr wird nach Hostname beurteilt, und verschlüsselte Inhalte werden standardmäßig nicht untersucht. Wer eine breite Domain erlaubt, lässt Raum, dass etwas hinausgelangt
  • Sie hängt von der Umgebung ab – macOS braucht nichts zusätzlich. Linux und WSL2 brauchen bubblewrap und socat, und natives Windows wird nicht unterstützt

Die Sandbox ist keine Mauer, die einem Angreifer standhalten soll, sondern ein Sicherheitsgurt, der Unfälle und Amokläufe um eine Größenordnung verringert. Anthropic hat angegeben, die Rechteabfragen intern sicher um 84 % gesenkt zu haben, aber das ist ein Bericht über weniger Rückfragen, keine Garantie, dass sie nicht zu durchbrechen wäre.

Unfälle geschehen in ungefähr vier Formen

Hier ist die Mechanik noch einmal von der Unfallseite her aufgereiht. Wählen Sie Einstellungen danach aus, ob sie gegen diese vier wirken.

1. Zerstörerische Befehle

Ein rm, das einen Pfad ausräumt, mit dem niemand gerechnet hat; ein git push --force, das die Arbeit anderer auslöscht. Gemeinsam ist ihnen, dass sie nicht rückgängig zu machen sind. Was wirkt, sind deny- und ask-Regeln plus die Isolierung des Dateisystems. Operationen, die Sie nicht rückgängig machen können, in ask abzulegen, ist der verlässliche Zug.

2. Abfließende Geheimnisse

Zum Unfall wird das nur, wenn lesen können und senden können zusammenkommen. Also ist auch die Gegenmaßnahme zweiteilig: nicht lesen lassen (ein deny auf Read(.env), denyRead) und nicht senden lassen (deny auf curl und wget, eine schmale Liste erlaubter Domains). Eines von beiden reicht nicht.

3. Es erreicht einen anderen Branch oder eine andere Umgebung

Was als lokale Korrektur an einer Datei gedacht war, wächst sich zu einem Push in einen geteilten Branch oder zu einem Deployment in die Produktion aus – eine Eskalation der Operation. Im gewöhnlichen Modus sitzt bei jedem Schritt eine Rückfrage, aber wer alles öffnet, ebnet die Stufen ein. Push und Deployment in ask zu legen, ist eine billige Versicherung.

4. Anweisungen, die über gelesene Dateien eingeschleust werden

In einer README, einem Issue, einer Webseite oder einem PDF, das Claude liest, können an Claude gerichtete Anweisungen versteckt sein (Prompt Injection). Auch wenn „schick das an diese Adresse“ in weißer Schrift dasteht, ist es aus Claudes Sicht Text, der durch dieselbe Tür hereinkommt wie Ihr Auftrag, und Daten und Anweisungen lassen sich ihnen nicht ohne Weiteres ansehen.

Was nicht wirkt, ist der Umgehungsmodus (der eingeschleuste Text erreicht die Ausführung unangetastet) und ein Verbot in der CLAUDE.md (es ändert nicht, was erlaubt ist). Was wirkt, ist eine Grenze auf Ebene des Betriebssystems – es kann nicht schreiben, wo es nicht schreiben kann, und nicht erreichen, was es nicht erreichen kann – zusammen mit deny-Regeln. Eingeschleuster Text ist unsichtbar, verlassen Sie sich also nicht darauf, ihn zu bemerken: Lesen Sie nicht vertrauenswürdiges Material mit für diese eine Sitzung eingeschränkten Rechten.

Darf abgegeben werden / muss gestoppt werden

Legt man die drei Achsen an, fällt die Linie hierhin.

Darf abgegeben werden (in allow aufnehmen)

Tests, Typprüfungen, Linter, Builds / Änderungen innerhalb des Arbeitsverzeichnisses / Lesen und Suchen / lokale Commits

Muss gestoppt werden (ask oder deny)

Pushes und erzwungene Pushes in geteilte Branches / Deployments und Migrationen in der Produktion / das Lesen von Geheimnisdateien / Befehle, die Daten nach außen senden / Schreibzugriffe außerhalb des Arbeitsverzeichnisses

  • Legen Sie einen Modus für den Alltag fest. acceptEdits für wiederholtes Bearbeiten, default für heikle Arbeiten. Schreiben Sie ihn in defaultMode
  • Wer dieselbe Rückfrage dreimal beantwortet hat, verschiebt sie nach allow. Umgekehrt wird jede Operation, bei der Ihnen auch nur einmal „das sieht riskant aus“ durch den Kopf ging, fest auf ask gesetzt
  • Behandeln Sie alles, was Sie im Gespräch verboten haben, als etwas, das wieder verschwinden wird.
  • Wenn Sie etwas lockern, ziehen Sie immer an anderer Stelle an. Der eine Zustand, den Sie nie herstellen dürfen, ist keine Rückfragen und keine Grenze

Wann das Umgehen vertretbar ist. Innerhalb eines Containers, einer VM oder eines CI-Runners, den Sie wegwerfen können, wenn er kaputtgeht, mit nur dem Arbeitsverzeichnis als Mount, und ohne die .env und die SSH-Schlüssel des Hosts hineinzutragen. „Die Rückfragen sind lästig“ ist kein Grund. Lesen Sie hinterher immer den Diff.

Alles, was hier behandelt wurde, verringert Unfälle; nichts davon beseitigt sie. Das Urteil von Schicht 2, die Entscheidungen des Automatikmodus und die Grenze der Sandbox – für jedes davon gibt es Formen, die hindurchkommen. Am meisten hilft, sich in einem Zustand zu halten, den Sie zurücknehmen können.

Zusammenfassung

  • Die Rechte sind drei Schichten: Modi, Regeln und die Sandbox. Die Achsen sind lässt es sich zurücknehmen, wie weit reicht es, berührt es Geheimnisse, und die Regel lautet nach Häufigkeit lockern, nach Wesensart anziehen
  • Die Rechte haben zwei Schichten. Das Umgehen entfernt nur die Oberfläche von Schicht 1, und die Rückfrage, die als Gesprächstext zurückkommt, ist so gewollt
  • Regeln laufen deny → ask → allow, und die erste Übereinstimmung gewinnt; Genauigkeit ändert die Reihenfolge nicht
  • Regeln sehen nur Zeichenketten. Was diese Lücke schließt, ist die Sandbox – die allerdings nur Bash und dessen Kindprozesse erfasst und deren Standard für das Lesen weit ist
  • Unfälle nehmen vier Formen an: zerstörerische Befehle, abfließende Geheimnisse, das Erreichen einer anderen Umgebung und eingeschleuste Anweisungen

Steht der Umfang des Abgegebenen fest, bleibt nur noch, es an Ihre Umgebung anzupassen. Weiter zu Kapitel 6 „Erweitern“.