Claude Code fragt ständig nach Berechtigungen? So löst du das ohne --dangerously-skip-permissions

npm test zum vierzigsten Mal zu bestätigen, ist nur Rauschen. Claude Code bringt alles mit, um die langweiligen Abfragen stummzuschalten und die gefährlichen zu behalten. Es ist nur auf drei Dateien und sechs Modi verteilt.

Von Aslan, Pet-Island-Team · Aktualisiert am 26. Okt. 2026 · 5 Min. Lesezeit

KURZE ANTWORT

Trag die Befehle, die du immer erlaubst, in permissions.allow ein (zum Beispiel Bash(npm run *)), die, die immer anhalten sollen, in ask oder deny, und wähle einen Berechtigungsmodus, der zur Aufgabe passt: acceptEdits für viele Änderungen, auto für Routinearbeit, plan zum Lesen. Regeln werden in der Reihenfolge deny → ask → allow geprüft, ein Deny lässt sich also nie aushebeln. Mit /permissions siehst du, woher jede Regel stammt. --dangerously-skip-permissions hebst du dir für Wegwerf-Container auf.

Warum Claude Code so oft fragt

Im Standardmodus (in der CLI als Manual bezeichnet) fragt Claude Code bei der ersten Verwendung jedes Tools nach und fragt erneut bei jedem Shell-Befehl, der noch nicht erlaubt wurde. Die Abfrage ist der Moment, in dem du ein falsches rm oder ein versehentliches git push stoppen kannst, deshalb lohnt es sich, sie zu behalten. Das Problem: Sie erscheint auch bei den hundert harmlosen Dingen, die ein Agent in einer Sitzung erledigt.

Drei Dinge entscheiden, ob du eine Abfrage siehst: die Regeln in deinen Einstellungsdateien, der Berechtigungsmodus, in dem du dich befindest, und die Antworten, die du früher mit „Yes, and don’t ask again“ gegeben hast. Um das Rauschen loszuwerden, musst du alle drei anpassen.

Claude Code ab v2.1.283 startet interaktive Terminal- und VS-Code-Sitzungen im auto-Modus, in jedem Plan und bei jedem Anbieter. Im auto-Modus prüft ein Klassifikator im Hintergrund Befehle und Netzwerkanfragen gegen das, worum du gebeten hast, statt bei Routineaktionen nachzufragen. Wenn du trotzdem bei allem eine Abfrage siehst, schau in die Statusleiste: „⏸ manual mode on“ bedeutet, dass du im Standardmodus bist.

Allow-, Ask- und Deny-Regeln

Regeln stehen in einer Einstellungsdatei unter permissions. Dieses Beispiel stammt direkt aus Anthropics Einstellungsreferenz:

~/.claude/settings.jsonKopieren

{

"permissions": {

"allow": ["Bash(npm run *)"],

"ask": ["Bash(git push *)"],

"deny": ["Read(./.env)"],

"defaultMode": "acceptEdits"

}

allow: läuft ohne Nachfrage.
ask: fragt immer, auch in Modi, die sonst automatisch zustimmen würden.
deny: läuft nie.

Entscheidend ist die Reihenfolge: erst deny, dann ask, dann allow. Der erste Treffer gewinnt, und eine spezifischere Regel ändert nichts an der Reihenfolge. Eine Allow-Regel kann keine Ausnahme von einer Deny-Regel schaffen, und wenn ein Tool auf irgendeiner Ebene verweigert wird, kann keine andere Ebene es erlauben. Regeln werden von Claude Code selbst durchgesetzt, nicht vom Modell. „Niemals pushen“ in CLAUDE.md zu schreiben, bewirkt also nicht dasselbe wie eine Deny-Regel.

So schreibst du eine Regel

Regel	Was sie erfasst
`Bash(npm run *)`	`npm run build`, `npm run test --watch`, aber nicht `npm install`
`Bash(git log *)`	Nur `git log …`. Zum Vergleich: `Bash(git *)` erlaubt jeden git-Befehl.
`Bash(ls:*)`	Wie `Bash(ls )`: `:` ist eine andere Schreibweise für einen abschließenden Platzhalter
`Read(./.env)`	Das Lesen dieser Datei. Read- und Edit-Regeln verwenden gitignore-Muster
`Edit(//Users/alice/notes/**)`	Ein absoluter Pfad. Ein einzelnes führendes `/` ist relativ zur Einstellungsdatei, absolute Pfade brauchen daher `//`
`WebFetch(domain:example.com)`	Nur `example.com`. Für Subdomains `WebFetch(domain:*.example.com)` hinzufügen
`mcp__github__*`	Jedes Tool des MCP-Servers `github`. Regeln mit Klammern nach `mcp__` werden übersprungen

Unter Windows haben PowerShell-Regeln dieselbe Form wie Bash-Regeln.

Welche Einstellungsdatei du verwenden solltest

Bereich	Datei	Wofür
Benutzer	`~/.claude/settings.json` (Windows: `%USERPROFILE%\.claude\settings.json`)	Deine eigenen Gewohnheiten, in jedem Projekt
Projekt, geteilt	`.claude/settings.json`	Regeln, die das ganze Team bekommen soll (committen)
Projekt, lokal	`.claude/settings.local.json`	Deine persönlichen Regeln für ein Repo (nicht committet)
Verwaltet	`managed-settings.json` und andere verwaltete Quellen	Unternehmensrichtlinie; nichts kann sie überschreiben

Vorrang, höchster zuerst: verwaltet, Befehlszeile, lokales Projekt, geteiltes Projekt, Benutzer. Listenschlüssel wie permissions.allow werden über Dateien hinweg zusammengeführt, nicht ersetzt. Zwei Details sorgen oft für Verwirrung:

Einstellungsdateien sind striktes JSON: Ein //-Kommentar oder ein abschließendes Komma ist ein Syntaxfehler, und die ganze Datei wird ignoriert.
Allow-Regeln in einer geteilten Projektdatei gelten erst, nachdem jedes Teammitglied dem Ordner vertraut. Deny- und Ask-Regeln gelten sofort.

Die meisten Änderungen wirken ohne Neustart auf die laufende Sitzung, auch permissions und hooks. Um zu sehen, was tatsächlich geladen wurde, führ /status aus (Zeile Setting sources) oder /permissions, das jede Regel samt Herkunftsdatei auflistet.

Was „Yes, and don’t ask again“ wirklich speichert

Wenn du eine Abfrage mit „don’t ask again“ beantwortest, schreibt Claude Code eine Regel für dich in .claude/settings.local.json im Stammverzeichnis des Git-Repositorys. Wie lange sie gilt, hängt vom Tool ab:

Tool	Gemerkt
Bash-Befehle	Dauerhaft, pro Repository und Befehl
Dateiänderungen	Bis zum Ende der Sitzung
WebFetch	Dauerhaft, pro Repository und Domain

Wenn Claude also in jeder neuen Sitzung wieder fragt, ob es Dateien bearbeiten darf, ist das so gewollt: Freigaben für Dateiänderungen gelten pro Sitzung. Verwende stattdessen den Modus acceptEdits oder eine Allow-Regel Edit(...). Und wenn ein Befehl auch nach „don’t ask again“ weiter fragt, such nach einer ask-Regel in einer Projekt- oder verwalteten Datei. Eine Allow-Regel in deiner lokalen Datei hat keinen Vorrang davor.

Berechtigungsmodi und wann du welchen verwendest

Modus	Was er macht	Geeignet für
`default` (Manual)	Fragt bei der ersten Verwendung jedes Tools	Unbekannte Repos, riskante Arbeit
`acceptEdits`	Akzeptiert Dateiänderungen ohne Nachfrage	Lange Refactorings, die du in Git prüfst
`plan`	Liest und plant, ändert nichts	Eine Codebasis erkunden, eine Änderung entwerfen
`auto`	Keine Routineabfragen; ein Klassifikator prüft Befehle und Netzwerkanfragen vorab	Alltägliche Arbeit
`dontAsk`	Fragt nicht	Skripte und Automatisierung
`bypassPermissions`	Überspringt Abfragen, auch für Schreibzugriffe auf `.git` und `.claude`	Nur isolierte Container oder VMs

Mit Shift+Tab wechselst du durch die Modi. Im auto-Modus springt der erste Tastendruck zu default, danach default → acceptEdits → plan. Einen Startmodus legst du mit permissions.defaultMode fest; beachte, dass auto und bypassPermissions nur aus Benutzer- oder verwalteten Einstellungen wirken, nicht aus einer Projektdatei.

Manche Dinge fragen immer, in jedem Modus einschließlich bypass: unter anderem explizite ask-Regeln, Fragen, die Claude dir stellt, und rm auf kritischen Pfaden. Admins können die riskanten Modi abschalten, indem sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode auf "disable" setzen.

Zu --dangerously-skip-permissions

--dangerously-skip-permissions ist dasselbe wie --permission-mode bypassPermissions. Anthropics Doku ist da deutlich: nur in isolierten Umgebungen wie Containern, VMs oder Dev-Containern ohne Internetzugang verwenden. Unter Linux und macOS verweigert es den Start als root, und sobald du die Warnung akzeptierst, setzt es skipDangerousModePermissionPrompt in deinen Benutzereinstellungen.

Wenn du eigentlich nur willst, dass langweilige Dinge nicht mehr abgefragt werden, kommst du mit auto-Modus plus ein paar Allow-Regeln ans Ziel, ohne die wichtigen Abfragen aufzugeben.

Die Sandbox: weniger Abfragen mit Sicherheitsnetz

Claude Code kann Shell-Befehle in einer Sandbox ausführen. Sie ist standardmäßig aus; du schaltest sie mit /sandbox oder sandbox.enabled: true ein. Ein Sandbox-Modus genehmigt Befehle in der Sandbox automatisch, der andere fragt weiterhin. Die Sandbox deckt nur Shell-Befehle ab: Datei-Tools, MCP-Server und Hooks laufen außerhalb.

Sie läuft unter macOS, Linux und WSL2. Unter nativem Windows läuft die Sandbox nicht, und Befehle laufen ohne Sandbox. Ein weiterer Grund, dort eine kurze Ask-Liste zu pflegen.

Ein Setup, das funktioniert

Das ist ein sinnvoller Ausgangspunkt für ein JavaScript-Projekt. Passe die Befehle an deinen Stack an:

~/.claude/settings.jsonKopieren

{

"permissions": {

"allow": [

"Bash(npm run *)",

"Bash(npx tsc *)",

"Bash(git status)",

"Bash(git diff *)",

"Bash(git log *)"

"ask": [

"Bash(git push *)",

"Bash(npm publish *)"

"deny": [

"Read(./.env)",

"Read(./.env.*)"

]

}

Beginne mit einer Allowlist aus lesenden Befehlen und Testbefehlen.
Alles, was deinen Rechner verlässt (push, publish, deploy), kommt in ask.
Secrets verweigerst du komplett.
Arbeite in auto oder acceptEdits und wechsle in den plan-Modus, wenn du erkundest.
Öffne alle paar Tage .claude/settings.local.json und miste die Regeln aus, die „don’t ask again“ hinzugefügt hat.

Wenn die verbleibenden Abfragen am falschen Ort auftauchen

Nach dem Feintuning solltest du nur noch zu Dingen gefragt werden, die eine Entscheidung verdienen. Bleibt das Problem, wo die Frage erscheint: in einem Terminal-Tab hinter deinem Browser, wo der Agent zwanzig Minuten warten kann, bevor du es merkst.

Pet Island holt diese Fragen auf eine kleine Insel oben auf deinem Bildschirm. Wenn Claude Code eine Berechtigung braucht, erscheint die Anfrage dort mit dem Befehl oder dem Diff, und du erlaubst, verweigerst oder erlaubst sie dauerhaft, ohne das Fenster zu wechseln. Auch Fragen und Pläne von Claude Code funktionieren über die Insel, und wenn die Insel geschlossen ist, fragt Claude Code einfach wieder im Terminal.

FAQ

Wie verhindere ich, dass Claude Code bei jedem Befehl um Erlaubnis fragt?

Trag die Befehle, denen du vertraust, in permissions.allow in ~/.claude/settings.json ein, zum Beispiel "Bash(npm run *)", und nutze den Modus auto oder acceptEdits. Riskante Befehle lässt du in permissions.ask, damit sie weiterhin anhalten.

Warum fragt Claude Code bei Dateiänderungen erneut, obwohl ich „don’t ask again“ gewählt habe?

Freigaben für Dateiänderungen gelten nur bis zum Ende der Sitzung. Nutze den Modus acceptEdits oder eine Allow-Regel Edit(...), wenn Änderungen sitzungsübergreifend freigegeben sein sollen.

Kann eine Allow-Regel eine Deny-Regel überschreiben?

Nein. Regeln werden in der Reihenfolge deny, ask, allow geprüft, und der erste Treffer gewinnt. Ein Tool, das auf irgendeiner Ebene verweigert wird, kann anderswo nicht erlaubt werden.

Ist --dangerously-skip-permissions sicher?

Anthropic empfiehlt es nur in isolierten Umgebungen wie Containern oder VMs ohne Internetzugang. Es überspringt außerdem Abfragen für Schreibzugriffe auf .git und .claude.

Wo speichert „Yes, and don’t ask again“ die Regel?

In .claude/settings.local.json im Stammverzeichnis des Git-Repositorys.

Funktioniert die Sandbox von Claude Code unter Windows?

Nicht unter nativem Windows; Befehle laufen dort ohne Sandbox. Sie läuft unter macOS, Linux und WSL2.

Quellen

Jede Einstellung und jedes Verhalten auf dieser Seite wurde am 26. Oktober 2026 mit diesen Seiten abgeglichen. Agenten ändern sich schnell; wenn etwas nicht mehr passt, gilt die offizielle Seite.

WEITERLESEN

Claude Code