Wie man verhindert, dass Claude Code für alles um Erlaubnis fragt

Nichts bringt einen proaktiven Arbeitsablauf schneller zum Erliegen als eine Berechtigungsabfrage alle elf Sekunden.

Je weiter man von der Tastatur entfernt ist, desto schlimmer wird es. Eine Claude-Code-Sitzung von deinem Handy aus zu beaufsichtigen ist angenehm, bis zum zwanzigsten Tippen auf Allow - woraufhin du wieder an deinem Schreibtisch sitzt, was du eigentlich vermeiden wolltest.

Die übliche Lösung, auf die man meist zurückgreift, ist --dangerously-skip-permissions. Der Flag-Name ist treffend gewählt, und auf einem Rechner, auf dem Ihre Anmeldedaten gespeichert sind, ist dies die falsche Antwort.

Hier ist der Mittelweg: eine echte Zulassungsliste, die man einfügen kann, und die Regeln, die so aussehen, als würden sie funktionieren, es aber insgeheim doch nicht tun.

Entscheiden Sie zunächst, welchen Hebel Sie betätigen möchten

Es gibt zwei voneinander unabhängige Steuerelemente, und wenn man diese miteinander verwechselt, führt das dazu, dass die Konfiguration letztendlich keine Wirkung zeigt.

Berechtigungsmodi legen die Basis für die Sitzung fest: was ganz ohne Abfrage läuft.

Berechtigungsregeln legen sich darüber und benennen bestimmte Tools und Befehle, die vorab genehmigt oder blockiert werden.

Die Interaktion ist der Teil, den man sich merken sollte: Verweigerungsregeln (deny) blockieren in jedem Modus, einschließlich bypassPermissions. Erlaubnisregeln (allow) haben in bypassPermissions keine Wirkung. Eine Sitzung, die mit dem Flag „dangerous“ läuft, ignoriert also alles, was Sie sorgfältig zugelassen haben, und berücksichtigt dennoch alles, was Sie abgelehnt haben.

Bei den Tarifen Pro, Max und Team ist auto der eingebaute Startmodus. Wenn die Abfragen weiterhin ständig erscheinen, befinden Sie sich wahrscheinlich im manuellen Modus, weil eine Einstellungsdatei Sie dorthin versetzt hat.

Eine vorgefertigte Zulassungsliste, die Sie einfügen können

Füge dies in die .claude/settings.json deines Projekts ein. Sie ist bewusst konservativ gehalten: Die Befehle sind solche, deren schlimmste Folge ein erneuter Durchlauf ist, und die Sperrliste deckt das ab, was du nicht möchtest, während du im Zug sitzt.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(npm ci)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git checkout -b *)",
      "Edit(src/**)",
      "Edit(tests/**)",
      "Read(**)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(npm publish *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "ask": ["Bash(git rebase *)", "Bash(git reset --hard *)"]
  }
}

Was die einzelnen Blöcke bewirken:

• allow entfernt die Eingabeaufforderungen, die Sie ohnehin genehmigt hätten. Bash(npm run *) umfasst jedes Skript in Ihrem package.json ohne sie aufzuzählen.
• deny ist die eigentliche Sicherheitsarbeit. Beachte curl und wget: Ohne sie kann Bash keine beliebigen URLs erreichen, und genau diese Lücke macht eine WebFetch-Domain-Zulassungsliste überhaupt sinnvoll. In der Dokumentation von Anthropic heißt es ausdrücklich: „Die alleinige Verwendung von WebFetch verhindert den Netzwerkzugriff nicht. Wenn Bash zugelassen ist, kann Claude weiterhin curl, wget oder andere Tools verwenden, um eine beliebige URL zu erreichen.“
• ask erzwingt eine Abfrage, selbst wenn eine Zulassungsregel ansonsten zutreffen würde. Verwende diese Option für Operationen, die du zwar sehen, aber nicht verbieten möchtest.

Du brauchst kein Bash(ls *), Bash(cat *) oder Bash(grep *). Claude Code kennt eine eingebaute Menge schreibgeschützter Befehle, die in jedem Modus ohne Abfrage laufen: ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd sowie die schreibgeschützten Formen von git. Regeln dafür hinzuzufügen ist nur Rauschen.

Führen Sie /permissions aus, um alle aktiven Regeln zu sehen und aus welcher Einstellungsdatei die jeweilige Regel stammt. Sie können es öffnen, während Claude arbeitet, und eine Änderung wird ab dem nächsten Tool-Aufruf in derselben Runde wirksam.

Die fünf Regeln, die so aussehen, als würden sie funktionieren, es aber nicht tun

Das ist der Teil, der zwar in der Referenzdokumentation steht, den aber niemand zusammenstellt – und genau daran vergeht ein ganzer Nachmittag.

1. Bash(git * main) ist keine Git-Regel, sondern fast eine Shell

Der Platzhalter steht für den Text, der an seiner Stelle steht. In Bash(git * main) ist das der Unterbefehl, daher passt die Regel auf git merge main und auf git push origin main.

Es passt auch zu git -c core.fsmonitor=<script> diff main, und -c core.fsmonitor bewirkt, dass Git ein von dir benanntes Programm ausführt. Eine Regel, die sich wie „Git-Operationen auf main“ liest, kommt eher dem Ausführen eines beliebigen Programms nahe.

Die Regel: setze das * nach dem Unterbefehl. Bash(git log *) erlaubt nur git log. Claude Code gibt beim Start eine Warnung bezüglich einer Zulassungsregel mit einem * vor dem Unterbefehl.

Dieselbe Form beißt auch anderswo. Bash(* --version) setzt den Platzhalter an die Stelle, an der das Programm steht, also passt auch bash -c 'echo hi' --version.

2. Pfadregeln für Write(...) und Glob(...) werden stillschweigend nie herangezogen

Claude Code prüft Dateiberechtigungen ausschließlich gegen Edit(path)- und Read(path)-Regeln.

Schreibe eine Pfadregel für Write, NotebookEdit, Glob oder das veraltete MultiEdit, und Claude Code akzeptiert sie, warnt beim Start und zieht sie danach nie heran. Die Regel steht in deiner Einstellungsdatei und sieht aus, als würde sie schützen.

Die Regel: Verwende Edit(docs/**) anstelle von Write(docs/**) und Read(docs/**) anstelle von Glob(docs/**).

3. Pfadregeln werden an einer Stelle verankert, mit der man nicht gerechnet hat

Read- und Edit-Regeln verwenden die gitignore-Mustersyntax, mit vier unterschiedlichen Formen:

Der dritte Punkt ist die Falle. Eine Deny-Regel Read(/secrets/**) in deinen Benutzereinstellungen (~/.claude/settings.json) wird an dieser Einstellungsquelle verankert und blockiert damit ~/.claude/secrets/** und nicht das Verzeichnis secrets in deinem Projekt.

Die Regel: Für eine Regel auf Benutzerebene, die in jedem Projekt gelten soll, verwende einen absoluten Pfad mit // oder einen zum Home-Verzeichnis relativen Pfad mit ~/. /path ist für Projekteinstellungen gedacht.

4. Bash-Regeln, die die Argumente einschränken, sind von ihrer Konzeption her anfällig.

Anthropic warnt direkt davor. Eine Regel wie Bash(curl http://github.com/ *) beabsichtigt, curl auf GitHub zu beschränken, und übersieht dabei:

• Optionen vor der URL: curl -X GET http://github.com/...
• Ein anderes Protokoll: curl https://github.com/...
• Eine Weiterleitung: curl -L http://short.example.com/xyz Auf GitHub landen
• Eine Variable: URL=http://github.com && curl $URL
• Ein zusätzliches Leerzeichen: curl http://github.com

Die Regel: Versuche nicht, Argumente mit einem Bash-Muster einzuschränken. Verbiete die Netzwerk-Tools vollständig und lasse einzelne Domains über WebFetch(domain:github.com) zu, oder erzwinge es in einem PreToolUse-Hook.

5. Umgebungs-Runner geben den Platzhalter direkt weiter

Vor dem Abgleich entfernt Claude Code eine feste Menge von Wrappern, sodass Bash(npm test *) auch auf timeout 30 npm test passt. Entfernt werden timeout, time, nice, nohup, stdbuf, die Shell-Builtins command und builtin, zshs noglob und ein blankes xargs.

Runner für Entwicklungsumgebungen stehen nicht auf dieser Liste, und sie führen ihre Argumente aus. Eine Regel Bash(devbox run *) passt auf devbox run rm -rf .. Dasselbe gilt für npx, mise exec, direnv exec und docker exec.

Die Regel: Schreibe für jeden gewünschten inneren Befehl eine eigene Regel, zum Beispiel Bash(devbox run npm test). Exec-Wrapper wie watch, setsid, ionice, und flock können überhaupt nicht als Präfix zugelassen werden und erfordern stets eine Eingabe im manuellen Modus, ebenso wie find -exec und find -delete.

Zwei weitere Dinge, die dich glauben lassen, dass deine Konfiguration fehlerhaft ist

defaultMode: "auto" in den Projekteinstellungen bewirkt nichts

Du kannst permissions.defaultMode in einer Einstellungsdatei setzen, um den Startmodus zu wählen. Setzt du jedoch "auto" in .claude/settings.json oder .claude/settings.local.json, wird der Wert nicht übernommen, und Claude Code verwendet dann die eingebaute Standardeinstellung statt eines defaultMode aus ~/.claude/settings.json. Setzt du "bypassPermissions" in diesen beiden Dateien, startet die Sitzung stattdessen im manuellen Modus.

Dies ist beabsichtigt: Eine in ein Repository eingecheckte Datei darf nicht dazu führen, dass die Berechtigungen für alle Benutzer, die sie klonen, erweitert werden. Die übrigen Werte gelten unabhängig von der jeweiligen Einstellungsdatei.

Projekt-Zulassungsregeln warten auf die Vertrauensstellung des Arbeitsbereichs

permissions.allow-Regeln und permissions.additionalDirectories in der .claude/settings.json eines Projekts erteilen Berechtigungen, daher wendet Claude Code sie erst an, nachdem du den Workspace-trust-Dialog für diesen Ordner akzeptiert hast. Der Dialog listet auf, was der Ordner erteilen würde, sodass du es vorher lesen kannst. deny- und ask-Regeln bleiben davon unberührt, da sie nur einschränken.

Wenn Ihre sorgfältig erstellte Projekt-Allowlist auf einem neuen Klon nicht zu funktionieren scheint, liegt das daran.

Priorität – in einem Absatz

Berechtigungsregeln folgen der üblichen Prioritätsreihenfolge der Einstellungen, wobei verwaltete Einstellungen die höchste Priorität haben: Nichts, auch keine Befehlszeilenargumente, hat Vorrang vor einer verwalteten Regel.

Darüber hinaus entscheidet eine einzige Asymmetrie über den Ausgang der meisten Konflikte. Wird ein Werkzeug auf einer beliebigen Ebene abgelehnt, kann es auf keiner anderen Ebene zugelassen werden. Eine Verweigerungsregel auf Benutzerebene blockiert eine Zulassungsregel auf Projektebene und umgekehrt, da Verweigerungsregeln aus jedem Geltungsbereich vor Zulassungsregeln ausgewertet werden. Das Gleiche gilt zwischen ask und allow: Eine passende „ask“-Regel wird auch dann ausgelöst, wenn eine spezifischere „allow“-Regel ebenfalls zutrifft.

Eine praktische Konsequenz: Eine pauschale Ablehnung wie Bash(aws *) kann keine Ausnahmen von der Zulassungsliste berücksichtigen. Bash(aws s3 ls) in allow wird es nicht retten.

Noch eine Unterscheidung, die man kennen sollte. Eine „deny“-Regel, die nur aus einem reinen Werkzeugnamen besteht, wie zum Beispiel Bash, entfernt das Werkzeug vollständig aus Claudes Kontext, sodass Claude es nie sieht. Eine Regel mit Geltungsbereich wie Bash(rm *) lässt das Tool verfügbar und blockiert entsprechende Aufrufe, wenn Claude sie versucht.

Die Wahl der Vorgehensweise

Zulassungslisten sind nicht die einzige Möglichkeit, Abfragen zu reduzieren, und sie sind auch nicht immer die beste.

Die Sandbox-Zeile verdient eine Anmerkung, denn sie ist die am wenigsten bekannte Option und oft die richtige. Aktiviere die Bash-Sandbox (/sandbox oder sandbox.enabled in den Einstellungen) und belasse autoAllowBashIfSandboxed auf dem Standardwert true: Dann laufen Bash-Befehle in der Sandbox ohne Abfrage, selbst gegen eine reine Bash-ask-Regel, weil die Isolationsgrenze die Abfrage ersetzt. deny-Regeln gelten weiterhin, und inhaltsbezogene ask-Regeln wie Bash(git push *) fragen weiterhin nach. Verfügbar ist sie unter macOS, Linux und WSL2.

Wo die Schutzschalter angeschlossen bleiben

Selbst wenn alles oben Genannte aufgedreht ist, wird eine kurze Liste in keinem Modus automatisch genehmigt, bypassPermissions eingeschlossen:

• Tools, auf die eine explizite ask-Regel passt
• Tools, die eine Benutzerinteraktion erfordern, darunter AskUserQuestion
• rm und rmdir, die auf einen kritischen Pfad zielen; das kann weder eine allow-Regel noch ein PreToolUse-Hook mit der Rückgabe "allow" genehmigen
• Schreibvorgänge auf geschützte Pfade wie .git und .claude außerhalb von bypassPermissions

Beim letzten Punkt gibt es einen wichtigen Aspekt: permissions.allow-Regeln genehmigen Schreibvorgänge auf geschützte Pfade überhaupt nicht vorab. Die Sicherheitsprüfung läuft vor der Auswertung der Zulassungsregeln, sodass ein Eintrag wie Edit(.claude/**) nichts ändert. In Modi, die nachfragen, bietet die .claude/-Abfrage Yes, and allow Claude to edit its own settings for this session an, und das ist der vorgesehene Weg.

Weiterleitungen werden separat geprüft

Ein subtiler Fall, der verwirrende Abfragen erzeugt. Wenn ein Befehl die Ausgabe umleitet, prüft Claude Code das Ziel gegen deine Dateiregeln, als hätte Claude diese Datei direkt geschrieben.

So erlaubt Bash(git commit *) den Befehl, nicht aber das Ziel: git commit -m x > /tmp/out.txt löst eine zusätzliche Prüfung von /tmp/out.txt gegen deine Edit-Regeln, geschützte Pfade und Arbeitsverzeichnisse aus. Ein Ziel, das mit ~ beginnt oder einen Glob enthält, muss immer genehmigt werden.

Ziele, denen keine Datei zugrunde liegt, werden nicht geprüft: /dev/null, Dateideskriptor-Formen wie 2>&1, und Here-Docs.

Wenn Sie immer wieder zu einem Befehl aufgefordert werden, den Sie bereits zugelassen haben, prüfen Sie, wohin er schreibt.

Das Ganze zusammenfügen

Beginnen Sie mit drei Zügen in dieser Reihenfolge.

1. Führe /permissions aus und lies nach, was bereits aktiv ist und woher es stammt. In der Hälfte der Fälle ist die überraschende Regel eine, die du vor Monaten mit „Yes, and don’t ask again“ genehmigt hast.
2. Fügen Sie die obige Zulassungsliste ein in .claude/settings.json, dann passe es an dein Projekt an. Jede Regel, die du nicht laut begründen kannst, fällt weg.
3. Füge die Sperrliste hinzu, bevor du sie brauchst. git push, npm publish, curl, wget und deine Secrets-Pfade. Das ist der Block, der es dir erlaubt, zu allem anderen Ja zu sagen.

Wenn du dann Sitzungen fernab deines Schreibtischs beaufsichtigst, sollten die verbleibenden Abfragen solche sein, die du wirklich auf einem Handybildschirm sehen willst. Darum geht es.

Sie überlegen, wie viel Autonomie Sie einem Agenten in Ihrem Stack einräumen sollen? Vereinbaren Sie eine kostenlose Beratung bei Evalics und wir werden uns damit befassen, wo die Grenzen liegen.

Weiterführende Ressourcen

• So nutzen Sie Claude Code auf dem Handy mit Remote Control - warum die „Genehmigungsmüdigkeit“ die eigentliche Grenze der Fernüberwachung darstellt
• So führen Sie Claude-Code auf einem Remote-Server aus und halten ihn am Laufen - warum eine Produktionsbox der falsche Ort für --dangerously-skip-permissions
• Einführung in Claude Code: Das agentische CLI-Tool von Anthropic im Detail
• So automatisieren Sie die Qualitätssicherung von Webanwendungen mit Claude Desktop

Offizielle Quellen

• Claude Code: Berechtigungen konfigurieren
• Claude Code: Berechtigungsmodi
• Claude-Code: Sandboxing
• Claude Code: Referenz zu den Einstellungen
• Format für `.gitignore`-Muster

Von Kevin Michael Schindler, Experte für KI-Automatisierung bei Evalics