Claude Code täglich sicher fahren: Wo du bei Approval und Sandbox die Linie ziehst

„Es kommt ja jedes Mal ein Bestätigungsdialog, also wird schon nichts passieren.”

In den ersten Wochen mit Claude Code habe ich genau so gedacht. Jedes Mal, wenn das Tool etwas tat, kam eine Rückfrage. Ich las sie, drückte OK. Ich hatte das Gefühl, vorsichtig zu fahren.

Zwei Wochen später wurde mir beim Blick auf meine eigenen Finger ganz anders. Ich las den Bestätigungstext gar nicht mehr, ich drückte reflexartig Enter. Was einmal „der gewohnte Ablauf” geworden ist, prüft man nicht mehr. git push, Schreibzugriffe auf externe APIs, alles winkte ich durch, ohne hinzusehen. Dass nichts passiert ist, war reines Glück.

Ein Approval-Dialog macht dich nicht sicherer, nur weil es mehr davon gibt. Zu viele, und der Mensch liest sie nicht mehr. Zu wenige, und sogar unwiderrufliche Aktionen rutschen durch. Heute geht es um genau diese Linie, und zwar nicht um die Feinheiten der Konfiguration, sondern um die Frage, wie du jeden Tag entscheidest.

Das Wichtigste in Kürze

• Approval ist weder „alles stoppen” noch „alles durchlassen”. Der Leitsatz lautet: Umkehrbares schnell, Unumkehrbares bewusst langsam. Die Linie ziehst du danach, ob du es per undo zurückholen kannst.
• Den Permission Mode (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) schaltest du je nach Arbeitsphase um. Zum Erkunden plan, zum Korrigieren mit Review acceptEdits.
• --dangerously-skip-permissions (also bypassPermissions) gehört nicht in den Alltag. Nimm stattdessen den auto Mode oder die Sandbox.
• Die Sandbox engt den Bereich, den die Bash anfassen darf, auf OS-Ebene ein. Sie läuft unter macOS, Linux und WSL2, unter nativem Windows aber nicht.
• Im Team verankerst du den „Ort der Bestätigung” nicht im guten Willen der Leute, sondern physisch über deny-Regeln und Hooks.

Die Syntax der Konfigurationsdateien selbst steht im Schwesterartikel Claude Code Permissions Guide, und die konkreten Rezepte, um CLAUDE.md mit Berechtigungen zu kombinieren, findest du unter CLAUDE.md × Permission-Rezepte. Dieser Artikel hält sich an die Betriebsfrage: Wo stoppst du?

Die Linie ziehst du danach, ob es umkehrbar ist

Wenn du bei der Abgrenzung ins Grübeln kommst, stell dir vor der Frage nach dem technischen Risiko zuerst eine einzige andere Frage:

„Kann ich das in fünf Minuten wieder rückgängig machen?”

Eine Datei lesen, ein grep, ein Diff ansehen, npm run build laufen lassen. Das kannst du beliebig oft wiederholen. Im schlimmsten Fall holt dich git checkout zurück. Genau deshalb willst du es schnell durchlaufen. Umgekehrt verändern git push, ein Produktions-Deploy, ein versendeter Newsletter oder ein Schreibzugriff auf eine externe Datenbank die Außenwelt in dem Moment, in dem du drückst. Es ist nicht rücknehmbar. Also machst du es bewusst langsam.

Meine bewährte Dreiteilung sieht so aus.

Aktion	Entscheidung	Grund
Lesen, grep, Diff, build, test, lint	allow	Umkehrbar. Tempo soll nicht leiden
Code-Änderungen auf einem Branch	ask oder acceptEdits	Hängt vom Reifegrad des Repos ab
push, deploy, publish, Mailversand, Schreibzugriff externe API	ask	Wirkt nach außen. Nicht rücknehmbar
.env lesen, rm -rf, git reset --hard, curl | sh	deny	Der Schaden im Ernstfall ist zu groß

Am meisten ringt man hier mit dem „Bearbeiten”. Bearbeiten ist nicht pauschal gefährlich. In einem privaten Repo mit ordentlicher Testabdeckung kannst du Edits ruhig schnell durchlaufen lassen. Wirklich heikel ist eher, Edits in einem produktionsnahen Repo mit schwachen Tests freizugeben. Das Kriterium lautet also nicht „erlaube ich Edits?”, sondern womit verifiziere ich nach dem Edit?. Sind die Prüf-Kommandos da, darfst du Edits beschleunigen. Fehlen sie, lass sie auf ask.

Bei deny darf man ruhig „sicherheitshalber” großzügig sein, das schadet nie. .env lesen oder destruktive Befehle blockierst du von Anfang an, in der Annahme, dass nie ein Tag kommt, an dem du sie auf allow hochstufst. Anweisungen vom Schlag „überspring die permissions und gib Vollgas”, wie ich sie in Gefährliche Prompts gesammelt habe, reißen genau diese Grenze mutwillig ein. Steht es auf deny, stoppt der Kern, egal was die Prompt-Seite verlangt.

Den Permission Mode wechselst du nach Phase

Wenn allow/ask/deny einstellt, was gestoppt wird, dann ist der Permission Mode die Gangwahl dafür, wie stark gerade gestoppt wird. Mit Shift+Tab schaltest du zwischen default → acceptEdits → plan durch. In den offiziellen Permission Modes sind alle Modi aufgeführt, aber für den Alltag musst du dir diese Zuordnung merken.

Modus	Was ohne Rückfrage läuft	Wann du ihn nimmst
default	Nur Lesen	Neues Repo, Arbeit, bei der du vorsichtig vorgehen willst
plan	Nur Lesen (kein Edit, nur Plan)	Erst die Codebasis verstehen, dann handeln
acceptEdits	Lesen + Edits im Arbeitsordner	Selbst mit Review korrigieren
auto	Fast alles (ein Klassifikator prüft im Hintergrund)	Lange Arbeit, weniger Bestätigungsmüdigkeit
dontAsk	Nur vorab per allow Freigegebenes	CI oder abgeschottete Skript-Umgebungen
bypassPermissions	Alles (keine Prüfung)	Nur im isolierten Container oder in der VM

Meine Aufteilung ist schlicht. Der Einstieg in eine neue Aufgabe ist plan. Claude liest zuerst, legt einen Ablauf vor, und sobald ich bestätigt habe, dass die Richtung stimmt, geht es los. Steht die Richtung, lasse ich es im acceptEdits Mode in einem Zug durcharbeiten und sehe mir das Ergebnis gesammelt per git diff an. Statt jede Zeile einzeln abzunicken, liest man hinterher konzentrierter, wenn man alles auf einmal liest. Das ist im Grunde „am Ende sehe ich garantiert hin”, als System gebaut, und liegt direkt neben dem Gedanken „den Türsteher der Maschine überlassen” aus Harness Engineering.

Ein Hinweis noch. In jedem Modus außer bypassPermissions werden Schreibzugriffe auf protected paths nicht automatisch bestätigt. Das sind Orte wie .git, .claude, .bashrc oder .npmrc, deren Beschädigung das Repo oder die Konfiguration selbst lahmlegt. Auch wenn du mit acceptEdits munter editierst, kommt hier eine Rückfrage. Das ist keine Schikane, sondern das letzte Sicherheitsnetz.

Wie du ohne --dangerously-skip-permissions auskommst

Um „zu viele Rückfragen, das nervt” zu lösen, greifen viele zu --dangerously-skip-permissions (also dem bypassPermissions Mode). Wie der Name sagt, ist das die Flagge, die alle Prüfungen abschaltet.

Wer das im täglichen Dialog dauerhaft nutzt, hat keinen „beaufsichtigten Agenten” mehr. Es ist nur noch nicht schiefgegangen. Auch die offizielle Doku schreibt ausdrücklich, dieser Modus gehöre „nur in den isolierten Container oder die VM”: außer in den schlimmsten Fällen wie rm -rf / oder rm -rf ~ kommt überhaupt keine Rückfrage. Schutz gegen Prompt Injection ist gleich null.

Aber das Gefühl, dass es „nervt”, ist berechtigt. Deshalb gilt: Was weg muss, ist die Zahl der Rückfragen, nicht das Sicherheitsnetz. Es gibt zwei Alternativen.

Die eine ist der auto Mode. Er nimmt die Rückfragen weg, aber im Hintergrund schaut ein separates Klassifikatormodell jede Aktion an und blockiert riskante Dinge wie curl | bash, einen Produktions-Deploy, einen direkten Push auf main oder einen Force Push. Sagst du im Gespräch „nicht pushen”, wirkt das ebenfalls als zeitweiliges Blockiersignal. Die Rückfragen werden weniger, gefährliche Aktionen werden trotzdem gestoppt. Das ist etwas anderes als bypassPermissions. Allerdings ist der auto Mode eine Research Preview, also kein Werkzeug, um die Review heikler Aktionen komplett auszulassen, sondern eines für „Arbeit, deren Richtung vertrauenswürdig ist”.

Die andere ist die Sandbox. Dazu mehr im nächsten Kapitel.

Willst du Rückfragen reduzieren, dann zuerst acceptEdits oder auto, und reicht das nicht, die Sandbox. bypassPermissions betrachtest du als reine Container-Sache. Denkst du in dieser Reihenfolge, gibt es kaum noch einen Grund, das ganze Sicherheitsnetz abzunehmen.

Die Sandbox bindet den „erreichbaren Bereich” ans OS

Wenn Approval fragt, „darf diese Aktion ausgeführt werden?”, dann ist die Sandbox der Mechanismus, der den Bereich der Dateien und des Netzwerks, den die Bash überhaupt erreicht, auf OS-Ebene verengt. Approval ist die „Prüfung vor der Ausführung”, die Sandbox die „Wand während der Ausführung”. Das sind verschiedene Ebenen.

Stark ist sie, weil sie die Schwäche von Approval ausgleicht. Approval entscheidet anhand des Befehlstextes, also fällt es nicht auf, wenn npm run build im Hintergrund etwas Unerwartetes tut. Mit Sandbox aber kann dieser Befehl standardmäßig nur in den Arbeitsordner schreiben. Selbst wenn er sich nicht so verhält, wie sein Name verspricht, stoppt ihn das OS physisch.

Führst du /sandbox aus, öffnet sich ein Konfigurationspanel mit zwei Modi.

• auto-allow: Innerhalb der Sandbox läuft Bash ohne Rückfrage (weil der Bereich eingegrenzt ist, ist es sicher). Nur Aktionen, die den Bereich verlassen, fallen auf das übliche Approval zurück.
• regular permissions: Auch in der Sandbox kommt wie gewohnt eine Rückfrage. Starke Kontrolle, aber viele Bestätigungen.

Für Leute, die sagen „Rückfragen will ich reduzieren, aber dass alles einfach ausgeführt wird, macht mir Angst”, passt das genau. Weil der Bereich schützt, musst du nicht ständig nachfragen.

Es gibt allerdings eine wichtige Einschränkung. Die Sandbox läuft nur unter macOS, Linux und WSL2, unter nativem Windows nicht. Windows-Nutzer müssen Claude Code innerhalb von WSL2 betreiben. Wer WSL nicht nutzen kann oder auf blankem Windows arbeitet, sollte nicht auf die Sandbox setzen, sondern die Aufteilung von allow/ask/deny strenger wählen. Vor allem deploy, publish und alles rund um Secrets schiebst du Richtung ask. Das ist der realistische Kompromiss unter Windows.

So sieht eine Sandbox-Konfiguration aus. Nur für Tools, die außerhalb des Arbeitsordners schreiben müssen (etwa kubectl, das ~/.kube anfasst), öffnest du gezielt ein Loch.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false bedeutet „läuft die Sandbox in der Umgebung nicht, gib nur eine Warnung aus und falle auf normale Ausführung zurück”. Willst du im Unternehmen die Sandbox dagegen verpflichtend machen, setzt du es auf true und stoppst den Start selbst. Unscheinbar, aber wichtig ist außerdem denyRead. Standardmäßig kann die Sandbox fast alle Dateien lesen, also schließt du Secrets wie ~/.aws oder ~/.ssh lieber ausdrücklich ab.

Ein Startpunkt, der in den „täglichen Betrieb” passt

Gießt man alle bisherigen Entscheidungen in eine Datei, reicht als Ausgangspunkt für den Alltag etwa so viel. Die feinen Bedeutungen der Syntax (etwa der Unterschied zwischen Bash(npm run build) und Bash(npm*)) überlasse ich dem Permissions Guide.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Es passieren nur drei Dinge. Lesen und Verifizieren laufen schnell. Was nach außen wirkt, wird immer gestoppt. Was offensichtlich gefährlich ist, ist von Anfang an verboten. defaultMode: "plan" ist drin, weil ich jede neue Session mit „erst lesen und planen” beginnen will. Danach stufst du beim Arbeiten per Shift+Tab auf acceptEdits hoch.

Dass Edits (Edit / Write) weder unter allow noch unter ask stehen, ist Absicht. Weil ich sie über den Mode (acceptEdits) steuern will. Bändigst du Edits über Regel und Mode, weißt du nicht mehr, welche von beiden greift. Edits über den Mode, externe Seiteneffekte über Regeln — teilst du die Rollen so auf, wird der Kopf frei.

Im Team verankerst du den „Ort der Bestätigung” physisch

Bis hierher ging es ums Einzelne. Im Team kommt ein Problem dazu: Die Linie liegt von Person zu Person woanders. Manche sind vorsichtig, andere wollen mit bypassPermissions durchfahren. Verlässt du dich auf guten Willen und Vernunft, wird der Betrieb des laxesten Mitglieds zur faktischen Linie des Teams.

Deshalb überlässt du den Ort, an dem du stoppen willst, nicht dem Urteil der Leute, sondern verankerst ihn physisch. Drei konkrete Beispiele.

1. Vor dem Commit Secret-Lecks stoppen. Ein PreToolUse-Hook prüft vor git add maschinell, ob .env gestaged ist. Bevor ein Mensch „ach, das durfte ja nicht rein” merkt, stoppt der Commit.

2. Vor dem Deploy den Build erzwingen. Glaub nicht dem „ich hab lokal gebuildet, glaube ich”. Ein Hook lässt vor dem Deploy-Befehl immer npm run build laufen.

3. Nach dem Edit automatisch verifizieren. Nach Edit / Write läuft npm run test. Auch bei kleinen Korrekturen läuft die Prüfung, also kommst du nicht kaputt weiter.

So viel ist die Minimalkonfiguration. Mehr Hooks sind nicht besser, eher hält der Betrieb mit einem Stopp-Hook und einem Prüf-Hook am stabilsten.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Unter Windows läuft es, wenn du den grep-Teil durch findstr oder ein kleines Node-Skript ersetzt. Entscheidend ist nicht der Befehl selbst, sondern die drei Formen „vor dem Commit stoppen / vor dem Deploy builden / nach dem Edit verifizieren”. Willst du auf Organisationsebene festziehen, kannst du in den Managed Settings bypassPermissions auf disable setzen und die Sandbox verpflichtend machen. Ab Teamgröße ist es am Ende am schnellsten, über die Beratungsseite gleich die Betriebsregeln mitzudesignen.

Häufige Fehler

Alle drei haben ich oder Leute in meinem Umfeld wirklich verbockt.

Alles auf ask setzen und zufrieden sein

Am ersten Tag sieht es sicher aus. Aber eine Woche später drückst du OK, ohne den Bestätigungstext zu lesen. Das ist gefährlicher als ein Zustand mit schwachem deny, weil die Illusion „ich hab’s ja geprüft” zurückbleibt. Bevor du ask-Einträge aneinanderreihst, festige zuerst deny.

--dangerously-skip-permissions wird zum Standardspruch

Hast du einmal „das ist ja schnell” Blut geleckt, kommst du nicht mehr zurück. Aber das heißt nur, du hast die Aufsicht abgeworfen. Nervt die Rückfrage, nimm den auto Mode oder das auto-allow der Sandbox. Es gibt keinen Grund, gleich das ganze Sicherheitsnetz mit abzunehmen.

Build-Erfolg mit Release-Erfolg verwechseln

Das kommt im Content-Betrieb wie in der Entwicklung ständig vor. Der lokale Build lief durch, aber die öffentliche URL ist alt, eine Sprache ist nicht aktualisiert, oder der CTA bricht auf dem Smartphone um. Approval und Sandbox verhindern diesen Fehler nicht. Was du brauchst, ist die Prüfung nach der Veröffentlichung. Mit diesem „ich dachte, ich hätte’s rausgebracht” bin ich oft genug auf die Nase gefallen.

Häufige Fragen

F. Was unterscheidet den auto Mode vom auto-allow der Sandbox? A. Die Art des Schutzes. Der auto Mode lässt ein Klassifikatormodell entscheiden, „ist diese Aktion gefährlich?”, und blockiert. Das auto-allow der Sandbox sichert nicht über den Inhalt der Aktion, sondern über den „erreichbaren Bereich”, den das OS einengt. Ersteres schützt über das Urteil, Letzteres über den Bereich. Du kannst beide auch kombinieren.

F. Kann ich die Sandbox unter Windows nutzen? A. Unter nativem Windows nicht. Betreibst du Claude Code innerhalb von WSL2, geht es. Nutzt du blankes Windows, verlass dich nicht auf die Sandbox, sondern schiebe deploy, publish und alles rund um Secrets Richtung ask und mach deny strenger.

F. Wie unterscheide ich plan Mode und acceptEdits Mode? A. plan ist „nur lesen, nicht editieren”, für die Phase, in der du die Codebasis verstehst und den Ablauf planst. acceptEdits ist „Edits im Arbeitsordner ohne Rückfrage durchlassen”, für die Phase, in der die Richtung steht und du in einem Zug korrigierst. Ich starte mit plan und falle nach der Einigung auf acceptEdits.

F. Was, wenn ich eine auf deny gesetzte Aktion partout ein einziges Mal ausführen will? A. deny erzwingt der Kern von Claude Code, also lässt es sich per Prompt nicht lockern (genau das ist der Wert von deny). Brauchst du es wirklich, nimm es an Ort und Stelle aus den Settings, führe es aus und setze es danach zurück. Allein der Aufwand des „vorübergehend entfernt” wirkt als Bremse für gefährliche Aktionen.

F. Überschneiden sich Hooks und Permissions nicht in der Rolle? A. Nein. Permissions steuern, „darf diese Aktion ausgeführt werden?”, Hooks steuern, „was läuft vor und nach der Ausführung garantiert?”. Deterministische Prüfungen wie Secret-Lecks stoppen oder vor dem Deploy builden sind Sache der Hooks.

Was dabei herauskam

Ich habe genau dieses Denken eins zu eins wieder in die Daily Automation dieser Seite eingebaut. Am stärksten verändert hat sich nicht die Ausgabequalität der KI selbst, sondern dass klar geworden ist, zu welchem Zeitpunkt der Mensch stoppt.

Früher war es ein vager Betrieb von „irgendwas eins voranbringen”, und manchmal endete ein Run damit, dass ein bestehender Artikel nur ein bisschen korrigiert wurde. Heute steht der Ablauf fest: mit plan den Ablauf → mit acceptEdits editieren → vor dem Deploy per Hook builden → nach der Veröffentlichung alle Sprachen auf dem Smartphone prüfen. Seit ich aufgehört habe, bypassPermissions zu nutzen, und auf acceptEdits + Sandbox umgestiegen bin, ist dieses „huch, ich hab gerade ungewollt nach außen etwas getan” verschwunden.

Statt alles der schlauen KI zu überlassen, setze ich vor unwiderrufliche Aktionen ein Durchatmen. Was wie ein Umweg aussieht, war der Weg, den ich jeden Tag beruhigt fahren kann. Leg dir zum Start das kostenlose Cheatsheet daneben und fang damit an, deine deny-Liste Zeile für Zeile zu füllen.