Inhaltsverzeichnis
- 1. Was ist „Bypass“ überhaupt?
- 2. Der eigentliche Grund: Das 2-Schichten-Berechtigungssystem
- 3. Schicht 1: Tool-Berechtigungs-UI (durch Bypass steuerbar)
- 4. Schicht 2: KI-Sicherheitsurteil (nicht durch Bypass steuerbar)
- 5. Operationen, bei denen Claude von sich aus fragt
- 6. Warum zwei Schichten? Die Designphilosophie
- 7. Praktische Wege zur Reduzierung von Bestätigungsanfragen
- 8. Zusammenfassung
- FAQ
Sie haben das Flag --dangerously-skip-permissions in Claude Code gesetzt, aber Claude schickt trotzdem eine Nachricht im Chat und fragt: „Darf ich diesen Vorgang ausführen?“ Kommt Ihnen das bekannt vor?
Der Instinkt ist zu denken „der Bypass funktioniert nicht“ — aber das stimmt nicht. Das Berechtigungssystem von Claude Code hat zwei unabhängige Schichten, und der Bypass-Modus steuert nur eine davon.
Dieser Artikel deckt alles ab: von „was Bypass wirklich ist“ bis zum Unterschied zwischen beiden Berechtigungsschichten, den Typen von Operationen, bei denen Claude von sich aus fragt, und praktischen Wegen zur Reduzierung von Bestätigungsanfragen bei der Automatisierung.
1. Was ist „Bypass“ überhaupt?
Im Software-Bereich bedeutet „Bypass“ das Überspringen des normalen Bestätigungs- oder Genehmigungsablaufs, um direkt fortzufahren. Denken Sie an den „Jetzt kaufen“-Button eines Online-Shops, der den Überprüfungsbildschirm überspringt — das ist ein Bypass des Bestätigungsablaufs.
Im Modus „Manuell“ von Claude Code (Konfigurationswert default) erscheint vor jeder Dateibearbeitung oder Shell-Befehlsausführung ein Bestätigungsdialog. Ab Claude Code v2.1.283 starten Terminal- und VS-Code-Sitzungen allerdings in jedem Tarif und bei jedem Anbieter standardmäßig im Auto-Modus, in dem ein Klassifikator die meisten Aktionen prüft, statt Sie zu fragen (in älteren Versionen nur in den Tarifen Pro, Max und Team; hat ein Administrator den Auto-Modus abgeschaltet oder unterstützt das Modell ihn nicht, startet die Sitzung im Modus „Manuell“).
# Modus „Manuell“: Bestätigung vor jeder Aktion
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / NoDer Berechtigungs-Bypass-Modus überspringt (bypassed) diesen Bestätigungsablauf.
# Bypass-Modus: fast keine Bestätigungsdialoge
$ claude --dangerously-skip-permissions
# oder
$ claude --permission-mode bypassPermissionsBeachten Sie, dass das Flag das Wort dangerously enthält. Anthropic positioniert diesen Modus als ausschließlich für Container oder isolierte Umgebungen gedacht — er wird für die alltägliche lokale Entwicklung nicht empfohlen. Eine vollständige Analyse der Bypass-Modus-Risiken finden Sie unter Claude Code Bypass-Modus: Risiken und sichere Nutzung.
Wenn trotzdem häufig Bestätigungsdialoge erscheinen, prüfen Sie zuerst, ob Sie überhaupt im Bypass-Modus arbeiten. Solange er aktiv ist, zeigt die Statusleiste im Terminal ⏵⏵ bypass permissions on. Fehlt die Anzeige, gibt es zwei häufige Ursachen.
- Sie haben ihn in den Projekteinstellungen eingetragen:
bypassPermissionsalsdefaultModein.claude/settings.jsonoder.claude/settings.local.jsonwirkt nicht, und die Sitzung startet im Modus „Manuell“ (ab v2.1.257). Tragen Sie ihn in Ihre Benutzereinstellungen (~/.claude/settings.json) oder die verwalteten Einstellungen ein, oder übergeben Sie das Flag beim Start - Sie wollten mitten in der Sitzung wechseln: Bypass lässt sich nur in einer Sitzung auswählen, in der er beim Start aktiviert wurde. In einer Sitzung, die ohne ihn gestartet wurde, erreicht Shift+Tab den Bypass-Modus nie
Außerdem zeigt Claude Code beim ersten Start einer interaktiven Sitzung im Bypass-Modus einmalig eine Warnung, in der Sie die Verantwortung für Aktionen ohne Berechtigungsprüfung übernehmen sollen (Ihre Zustimmung wird in den Benutzereinstellungen gespeichert).
2. Der eigentliche Grund: Das 2-Schichten-Berechtigungssystem
Die Antwort auf „Warum erscheint die Bestätigung trotz aktiviertem Bypass?“ lautet: Das Berechtigungssystem von Claude Code basiert auf zwei unabhängigen Schichten.
Claude Code Berechtigungssystem: 2-Schichten-Architektur
Der Bypass-Modus deaktiviert nur „Schicht 1“ (und selbst dort bleiben einige Rückfragen)
--dangerously-skip-permissions deaktiviert fast die gesamte Schicht 1 (es bleiben ask-Regeln, das Löschen kritischer Pfade und wenige weitere Fälle). Schicht 2 kann nicht umgangen werden.
Die Verwechslung dieser beiden Schichten ist die Hauptursache für das Missverständnis „Bypass funktioniert nicht“. Schauen wir uns jede im Detail an.
3. Schicht 1: Tool-Berechtigungs-UI (durch Bypass steuerbar)
Die erste Schicht ist der Bestätigungsdialog, der vor der Tool-Ausführung angezeigt wird — die interaktive Benutzeroberfläche, die erscheint, wenn Claude Code dabei ist, eine Datei zu bearbeiten oder einen Shell-Befehl auszuführen.
| Tool | Beispiel-Bestätigungsdialog |
|---|---|
| Dateibearbeitung | „Darf ich index.js ändern?“ |
| Bash-Ausführung | „Darf ich npm install ausführen?“ |
| Webzugriff | „Darf ich auf https://... zugreifen?“ |
Genau diese Schicht deaktiviert der Bypass-Modus. Mit --dangerously-skip-permissions erscheinen solche Dialoge fast nie, und Claude kann Tools frei ausführen. Selbst Schreibzugriffe auf geschützte Pfade wie .git und .claude laufen im Bypass-Modus ohne Rückfrage durch. In diesem Sinne funktioniert der Bypass-Modus korrekt.
Rückfragen, die auch im Bypass-Modus erscheinen (Ausnahmen von Schicht 1)
Das entscheidende Wort ist „fast“. Laut offizieller Dokumentation genehmigt Claude Code Folgendes in keinem Modus automatisch, auch nicht im Bypass-Modus (Quelle: offizielle Claude-Code-Seite „Choose a permission mode“, Stand 22. September 2026).
- Aktionen, die zu einer ask-Regel passen: Was Sie in den Einstellungen unter
permissions.askeingetragen haben (etwaBash(git push *)), fragt jedes Mal nach, auch im Bypass-Modus - Tools, die Ihre Mitwirkung brauchen:
AskUserQuestion, mit dem Claude Ihnen eine Frage mit Auswahlmöglichkeiten stellt, MCP-Tools, die als interaktionspflichtig markiert sind, und Connector-Tools, die Ihre Organisation auf ask gesetzt hat rmundrmdirauf kritische Pfade: Löschvorgänge, die das Wurzelverzeichnis und seine Verzeichnisse der obersten Ebene (etwa/usr), Ihr Home-Verzeichnis oder Ihr Arbeitsverzeichnis samt übergeordneten Verzeichnissen treffen. Die Dokumentation nennt das einen Schutzschalter (circuit breaker) gegen Modellfehler, den keine allow-Regel und kein Hook freigeben kann. Allerdings wird in der Desktop-App und in VS Code ab v2.1.309 ein solcher Befehl ohne Rückfrage sofort abgelehnt, und die Ablehnung enthält einen Hinweis zum Umschreiben des Befehls, damit Sitzungen ohne anwesende Person nicht hängen bleiben (offizielle Änderungsliste).- Sonstiges: die Schutzmechanismen für sitzungsübergreifende Nachrichten sowie Bash-Befehle, die außerhalb Ihrer Arbeitsverzeichnisse lesen, solange
permissions.blockReadsOutsideWorkingDirectoriesaktiviert ist
Auch die Regeln spielen eine Rolle. deny-Regeln gelten auch im Bypass-Modus und blockieren passende Aktionen. allow-Regeln dagegen haben im Bypass-Modus keine Wirkung (es geht ohnehin alles durch). In nicht-interaktiven Läufen mit -p werden diese wenigen Rückfragen abgelehnt, statt auf eine Eingabe zu warten.
Hinweis: Es gibt 6 Berechtigungsmodi
Claude Code hat sechs Berechtigungsmodi: Manuell (default), Bearbeitungen akzeptieren (acceptEdits), Plan (plan), Auto (auto) und Berechtigungen umgehen (bypassPermissions), dazu dontAsk, das nie im Shift+Tab-Durchschalten erscheint und alles automatisch ablehnt, wofür nachgefragt würde (für CI gedacht). Bypass (bypassPermissions) ist der am wenigsten restriktive. Details zu jedem Modus finden Sie im Artikel zu den Berechtigungsmodi.
4. Schicht 2: KI-Sicherheitsurteil (nicht durch Bypass steuerbar)
Die zweite Schicht ist Claudes autonomes Sicherheitsurteil. Diese ist völlig unabhängig von der Tool-Bestätigungs-UI.
Wenn Claude feststellt, dass eine Operation erhebliche Konsequenzen haben könnte, sendet es eine Bestätigungsnachricht im Chat als einfachen Text. Das ist kein Tool-Ausführungsmechanismus — es ist Claudes Gesprächsverhalten als KI.
--dangerously-skip-permissions überspringt die UI-Dialoge der Schicht 1, hat aber keinen Einfluss auf dieses Urteil der Schicht 2 — weil Schicht 2 ein Verhaltensprinzip ist, das im Modell von Claude selbst verankert ist.
Häufiges Missverständnis
„Ich habe den Bypass-Modus gesetzt, aber Claude hat angehalten → Bypass funktioniert nicht“
→ Genauer gesagt: Unterscheiden Sie danach, wie Claude angehalten hat. Hat Claude per Chat-Text gefragt, gilt: „Die Schicht-1-UI ist deaktiviert, aber das KI-Urteil der Schicht 2 fordert eine Bestätigung an.“ Ist im Terminal ein Dialog erschienen, der um Erlaubnis bittet, handelt es sich um eine der Rückfragen aus Schicht 1, die der Bypass-Modus beibehält, etwa eine ask-Regel oder das Löschen eines kritischen Pfads. In beiden Fällen funktioniert der Bypass einwandfrei (trifft keins von beiden zu und die Rückfragen gehen weiter, wurde die Sitzung womöglich gar nicht im Bypass-Modus gestartet).
Schicht 2 ist allerdings keine Sicherheitsgarantie. Ob Claude nachfragt, ist eine Einschätzung im Moment, und es hält nicht zwangsläufig vor jeder gefährlichen Aktion an. Die offizielle Dokumentation warnt zudem, dass der Bypass-Modus keinerlei Schutz vor Prompt-Injection oder unbeabsichtigten Aktionen bietet. Was niemals ausgeführt werden darf, blockieren Sie mit einer deny-Regel.
5. Operationen, bei denen Claude von sich aus fragt
Nach Operationstyp: Welche Schicht übernimmt die Bestätigung?
Schicht 1 (Tool-Berechtigungs-UI) vs Schicht 2 (KI-Urteil)
Claudes interne Kriterien für „das sollte ich bestätigen“ fallen in drei Hauptkategorien.
① Irreversibilität
Operationen, die nicht rückgängig gemacht werden können, machen Claude vorsichtig. Permanentes Löschen von Dateien, git push --force und DROP TABLE sind Paradebeispiele. Da Fehler schwer zu beheben sind, hält Claude inne und fragt nach.
② Wirkungsradius
Aktionen, die Produktionsumgebungen, eine große Anzahl von Dateien oder andere Benutzer betreffen, lösen häufigere Überprüfungen aus. Das Ändern einer lokalen Datei löst selten eine Frage aus; das Modifizieren eines Produktions-DB-Schemas fast immer.
③ Sicherheitsrisiko
Operationen, die .env-Dateien, Auth-Token oder API-Schlüssel nach außen senden, werden von Claude als hohes Sicherheitsrisiko eingestuft, das vor dem Fortfahren nachfragt.
Manche Löschvorgänge werden allerdings gar nicht Claudes Urteil überlassen: rm und rmdir auf kritische Pfade wie das Wurzelverzeichnis, Ihr Home-Verzeichnis oder das Arbeitsverzeichnis selbst werden auch im Bypass-Modus von Claude Code selbst gestoppt (Schicht 1). In der CLI erscheint eine Rückfrage, in der Desktop-App und in VS Code werden sie ab v2.1.309 sofort abgelehnt. Das ist eine der wenigen Rückfragen, die der Bypass-Modus nicht entfernt.
Diese Urteile sind im KI-Modell von Claude verankert und können nicht vollständig per Konfiguration abgeschaltet werden. Mehr darüber, wie KI-Agenten für sicheren Betrieb konzipiert sind, finden Sie unter Was ist ein KI-Agent?.
6. Warum zwei Schichten? Die Designphilosophie
Warum 2 Schichten? — Designphilosophie
Mit der Handwerker-Analogie erklärt
Hier ist eine Analogie, die das Zwei-Schichten-Design intuitiv verständlich macht.
Stellen Sie sich vor, Sie beauftragen einen Handwerker mit der Renovierung eines Zimmers und geben ihm einen Ersatzschlüssel mit den Worten „Sie können alles tun, was nötig ist.“ Das entspricht der Erteilung von Tool-Berechtigungen.
Aber wenn der Handwerker dabei ist, eine Wand einzureißen und fragt „Ist das eine tragende Wand? Sind Sie sicher, dass ich sie entfernen soll?“ — fragt er aufgrund seines eigenen professionellen Urteils, nicht weil er den Schlüssel verloren hat.
Ihm einen Schlüssel zu geben, hindert den Handwerker nicht am Nachdenken. Sein professionelles Urteil und sein Sicherheitsbewusstsein funktionieren unabhängig vom Schlüssel.
Claude funktioniert genauso. Der Bypass-Modus gibt Claude „den Schlüssel zur Nutzung von Tools“, aber er stoppt nicht Claudes KI-Urteil. Tatsächlich ist Claudes Innehalten vor Hochrisiko-Operationen eine absichtliche Sicherheitsfunktion, kein Fehlfunktion.
7. Praktische Wege zur Reduzierung von Bestätigungsanfragen
In CI/CD-Pipelines und anderen Automatisierungsszenarien müssen Sie möglicherweise, dass Claude Aufgaben ohne Unterbrechung erledigt. Hier sind die effektivsten Ansätze.
Ansatz 1: CLAUDE.md für Kontext nutzen
Erstellen Sie eine CLAUDE.md-Datei im Stammverzeichnis Ihres Projekts, in der Sie die Umgebung und die Einschränkungen erläutern. Wenn Claude versteht „das ist eine sichere, isolierte Umgebung“, sinkt die Bestätigungshäufigkeit erheblich.
# About This Environment
This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe
Please proceed without asking for extra confirmation.Ansatz 2: Kleine, spezifische Anweisungen geben
Vage Anweisungen erhöhen Claudes Unsicherheit und lösen mehr Bestätigungen aus.
| Anweisungstyp | Beispiel | Bestätigungsrate |
|---|---|---|
| Vage | „Räum dieses Projekt auf“ | Hoch |
| Spezifisch | „Entferne die ungenutzten Imports in src/“ | Niedrig |
| Vage | „Deploye es“ | Hoch |
| Spezifisch | „Führe npm run deploy:staging in der Staging-Umgebung aus“ | Niedrig |
Ansatz 3: Zuerst den Auto-Modus ausprobieren
Bevor Sie zum vollständigen Bypass-Modus greifen, versuchen Sie den Auto-Modus. Er führt im Hintergrund einen Sicherheitsklassifikator aus und genehmigt dabei die meisten Operationen automatisch; außerdem hält er Claude dazu an, weiterzuarbeiten, statt für Rückfragen zur Klärung anzuhalten (Claude fragt trotzdem, wenn Ihr Prompt oder ein Skill darauf angewiesen ist). Wenn der einzige Grund für die Nutzung von Bypass „ich bin müde von Bestätigungsanfragen“ ist, kann der Auto-Modus ausreichen. Aktionen, die zu einer ask-Regel passen, fragen auch im Auto-Modus nach.
Wichtiger Vorbehalt
Keine Konfiguration kann Claudes Sicherheitsurteil auf absolut null reduzieren. Das ist beabsichtigt — kein Bug und keine Einschränkung. Bei Hochrisiko-Operationen ist es das korrekte Verhalten, dass Claude nach Bestätigung fragt. Akzeptieren Sie es als Teil des Designs. Auch Schicht 1 behält einige Rückfragen, die der Bypass-Modus nicht entfernt, etwa ask-Regeln und das Löschen kritischer Pfade.
8. Zusammenfassung
| Punkt | Detail |
|---|---|
| Was Bypass ist | Überspringen fast aller Pre-Tool-Bestätigungsdialoge (Schicht 1) |
| Was Bypass deaktiviert | Tool-Berechtigungs-UI („Darf ich diesen Befehl ausführen?“), einschließlich der Rückfragen bei Schreibzugriffen auf geschützte Pfade wie .git und .claude |
| Was Bypass NICHT deaktiviert | Claudes KI-Sicherheitsurteil (Bestätigung als Chat-Text gesendet) und die Ausnahmen von Schicht 1 (ask-Regeln, rm/rmdir auf kritische Pfade, AskUserQuestion) |
| Regeln im Bypass-Modus | deny blockiert weiterhin; allow hat keine Wirkung |
| Claudes Bestätigungskriterien | Irreversibilität, Wirkungsradius, Sicherheitsrisiko |
| Wie Bestätigungen reduziert werden | CLAUDE.md-Kontext / spezifische Anweisungen / Auto-Modus |
| Warum zwei Schichten | Tool-Berechtigung und KI-Urteil sind grundlegend verschiedene Konzepte |
Wenn Claude im Bypass-Modus nach Bestätigung fragt, bedeutet das nicht, dass der Bypass aufgehört hat zu funktionieren — zwei unabhängige Systeme erledigen einfach ihre Aufgaben. Diesen Unterschied zu verstehen hilft Ihnen, das Verhalten von Claude Code genau vorherzusagen und es effizienter einzusetzen.
Um die Unterschiede zwischen Claude-Produkten zu verstehen, lesen Sie Claude.ai vs. Claude Code: Was ist der Unterschied?.
FAQ
Kann ich mit dem Bypass-Modus null Bestätigungen erhalten?
Sie können fast alle Tool-Ausführungs-UI-Dialoge (Schicht 1) deaktivieren, aber die Rückfragen bei Aktionen, die zu einer ask-Regel passen, bei rm oder rmdir auf kritische Pfade und bei Fragen über AskUserQuestion bleiben. Auch die Bestätigungen des KI-Sicherheitsurteils aus Schicht 2 lassen sich nicht vollständig eliminieren. Das ist eine absichtliche Sicherheitsfunktion. Durch sorgfältige Dokumentation Ihrer Umgebung in CLAUDE.md und spezifische Anweisungen können Sie jedoch deutlich reduzieren, wie oft Claude fragt.
Ist es ein Bug, wenn Claude nach Bestätigung fragt?
Nein. Der Bypass-Modus überspringt die Tool-Berechtigungs-UI, nicht Claudes KI-Urteil. Dass Claude bei irreversiblen Operationen, Produktionsumgebungen oder sensiblen Daten innehält, ist beabsichtigtes Sicherheitsverhalten — keine Fehlfunktion. Es ist nicht „Bypass funktioniert nicht“, sondern „zwei Systeme laufen unabhängig voneinander“. Erscheint statt Chat-Text ein Dialog, der um Erlaubnis bittet, handelt es sich um eine der Rückfragen aus Schicht 1, die der Bypass-Modus beibehält, etwa eine ask-Regel oder das Löschen eines kritischen Pfads.
Wie verhindere ich, dass Claude in CI/CD-Pipelines stoppt?
Drei Dinge helfen gut: ① Geben Sie in CLAUDE.md oder dem System-Prompt explizit an, dass „dies eine vollständig isolierte CI/CD-Umgebung ist und alle Operationen sicher ausgeführt werden“, ② geben Sie kleine, spezifische Aufgabenanweisungen (vage Anweisungen lösen mehr Bestätigungen aus), ③ kombinieren Sie den Bypass-Modus mit Docker-Container-Isolation. Führen Sie Claude Code bei ③ als Nicht-root-Benutzer aus: Unter Linux und macOS verweigert der Bypass-Modus den Start als root oder über sudo. Mit -p werden die wenigen Rückfragen, die der Bypass-Modus beibehält, abgelehnt, statt auf eine Eingabe zu warten. Sollen nur vorab genehmigte Aktionen laufen, nennt die offizielle Dokumentation für CI außerdem --permission-mode dontAsk zusammen mit --allowedTools. Beachten Sie, dass auch mit alledem noch gewisse Pausen auftreten können.
Kann ich einen Tool-Dialog und Claudes Bestätigung visuell unterscheiden?
Ja. Die Tool-Berechtigungsdialoge der Schicht 1 erscheinen im Claude Code Terminal als interaktive UI, die den Befehl oder die Änderung zusammen mit Auswahlmöglichkeiten wie Yes und No zeigt. Die KI-Urteilsbestätigungen der Schicht 2 erscheinen als normaler Gesprächstext von Claude (z. B. „Das wird die Produktions-DB ändern — ist das in Ordnung?“). Verwirrend ist AskUserQuestion, mit dem Claude eine Frage mit Auswahlmöglichkeiten stellt: Die Frage stammt von Claude, erscheint aber als Dialog und wartet auch im Bypass-Modus auf Ihre Antwort, weil Schicht 1 sie nie automatisch genehmigt. Die Anzeigeformate unterscheiden sich, sodass sie leicht zu unterscheiden sind, wenn man sich erst einmal damit vertraut gemacht hat.
