Claude Code permissions: wann ist Skip Permissions sicher?

--dangerously-skip-permissions schaltet die Permission-Rückfragen von Claude Code für die ganze Session ab. Es ist dasselbe wie --permission-mode bypassPermissions, und die Dokumentation von Anthropic sagt selbst, dass man es nur in Containern oder VMs nutzen soll, in denen Claude Code keinen Schaden anrichten kann. Wir nehmen das wörtlich: Auf dem Laptop eines Entwicklers arbeitet der Agent unter allow-, ask- und deny-Regeln plus Hooks, und voller Bypass läuft nur in einer isolierten Umgebung mit eigenen Konten.

Die kurze Antwort für einen CTO: Verbieten Sie das Flag nicht, entscheiden Sie, wo es erlaubt ist. Regeln für den Laptop, Hooks für das, was Regeln nicht sehen, Isolation für alles, was unbeaufsichtigt läuft.

Was schaltet --dangerously-skip-permissions tatsächlich ab?

Claude Code hat sechs Permission-Modi. Das Flag wählt den letzten:

"Alles" hat Ausnahmen, und die sind wichtig. Laut Dokumentation der Permission-Modi genehmigt kein Modus automatisch Tools, die eine explizite ask-Regel trifft, erkannte rm-Löschungen kritischer Pfade oder Tools, die einen Menschen brauchen, etwa AskUserQuestion. Auch Hooks laufen weiter. Was Bypass wegnimmt, ist die Rückfrage vor Schreibzugriffen auf geschützte Pfade wie .git und .claude, die jeder andere Modus behält.

Bypass heißt also nicht "keine Regeln". Es heißt "kein Mensch in der Schleife". Die Frage ist, ob sonst etwas in der Schleife ist.

Wie entscheiden allow-, ask- und deny-Regeln?

Regeln stehen in settings.json, als drei Listen. Das ist eine gekürzte Version aus unserem öffentlichen Claude Code Production Starter:

{
  "permissions": {
    "allow": ["Bash(pnpm check)", "Bash(pnpm test:*)", "Bash(bash scripts/gate.sh:*)"],
    "ask": ["Bash(git push:*)", "Bash(gh pr merge:*)", "Bash(vercel --prod:*)", "Bash(wrangler deploy:*)"],
    "deny": ["Read(**/.env)", "Read(**/*.pem)", "Bash(git push --force:*)", "Bash(git reset --hard:*)", "Bash(psql:*)"]
  }
}

Die Form ist die Policy. Allow für das, was der Agent braucht, um seine eigene Arbeit zu prüfen. Ask für alles, was die Maschine verlässt: ein Push, ein Merge, ein Deploy. Deny für Secrets, das Umschreiben der Historie und direkten Datenbankzugriff.

Claude Code prüft zuerst deny, dann ask, dann allow, und der erste Treffer gewinnt. Ein deny lässt sich nie durch ein engeres allow aufbrechen. Das gilt auch über Dateien hinweg: Ein deny im Repository schlägt ein allow in den persönlichen Einstellungen. Deshalb gehören Teamregeln in die .claude/settings.json des Repositorys und persönliche Abkürzungen in ~/.claude/settings.json.

Genau deshalb gehört jedes "mach niemals X" aus der CLAUDE.md in eine Regel oder einen Hook.

Was sieht eine Permission-Regel nicht?

Eine Regel vergleicht den Text des Befehls. Drei Dinge rutschen durch:

• Welcher Branch. Bash(git push:*) unterscheidet git push origin feat/x nicht von git push origin main. Fragen Sie bei jedem Push, klicken die Leute irgendwann ungelesen auf Ja.
• Indirekter Zugriff. Die Dokumentation sagt es klar: Read-deny-Regeln greifen nicht bei einem Python- oder Node-Skript, das die Datei selbst öffnet, und ein Bash-deny trifft dasselbe Programm innerhalb von sh -c nicht.
• Kontext. Eine Regel weiß nicht, wer die Session startet oder in welcher Art von Repository sie läuft.

Hier verdient ein PreToolUse-Hook sein Geld. Er bekommt den ganzen Tool-Aufruf als JSON, kann beliebige Logik ausführen, und Exit 2 blockiert den Aufruf, bevor Permission-Regeln überhaupt geprüft werden. Der Kern unseres Push-Gates, gekürzt:

CMD=$(jq -r '.tool_input.command // empty')
[[ "$CMD" != *"git push"* ]] && exit 0
BRANCH=$(git -C "${CLAUDE_PROJECT_DIR:-.}" branch --show-current 2>/dev/null)
if [[ "$CMD" =~ [[:space:]:](main|master)([[:space:]]|$) || "$BRANCH" == "main" ]]; then
  echo "Pushing to main is not allowed. Push a branch and open a PR." >&2
  exit 2
fi

Die Version in unserem Firmen-Plugin geht weiter: Sie liest die Ebene des Repositorys, sodass Code-Repositorys Pushes auf jeden geschützten Branch für alle blockieren, während Dokumentations-Repositorys den Gründer pushen lassen. Das kann keine Regel ausdrücken.

Der Hook braucht einen eigenen Test, sonst verstummt er. Genau daran haben wir eine Woche verloren, beschrieben in Claude Code Hooks, die still nichts tun.

Wann ist das Überspringen der Permissions wirklich sicher?

Wenn die Umgebung selbst die Grenze ist. Unsere unbeaufsichtigten Läufe bauen mit --permission-mode bypassPermissions und --disallowedTools AskUserQuestion ExitPlanMode, weil niemand da ist, der eine Rückfrage beantwortet. Akzeptabel macht das nicht das Flag, sondern das, was es umgibt. Beim dauerhaft laufenden KI-Agenten, der unsere Issues bearbeitet, sieht das so aus:

Auch im Bypass bleibt der Merge bei einem Menschen. Der Agent öffnet einen Pull Request, die Branch Protection verlangt eine Freigabe, und die Freigabe ist nie die des Agenten.

Der Reviewer in der CI ist das andere Extrem. Er läuft ebenfalls unbeaufsichtigt, bekommt aber statt Bypass eine explizite Tool-Liste:

claude_args: --allowed-tools "Read,Glob,Grep,Bash(git diff:*),Bash(git log:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Er kann den Diff lesen und kommentieren. Er kann nicht ändern, pushen oder mergen, also gibt es nichts zu umgehen.

Was ist mit der eingebauten Sandbox?

Claude Code hat eine Sandbox auf Betriebssystemebene, die begrenzt, was Shell-Befehle lesen, schreiben und im Netzwerk erreichen dürfen, samt ihrer Kindprozesse. Sie ist die richtige Antwort auf den zweiten blinden Fleck oben, weil sie nicht vom Text des Befehls abhängt.

Zwei Einstellungen sollten Sie kennen, bevor Sie etwas ausrollen. permissions.disableBypassPermissionsMode: "disable" in den Managed Settings nimmt allen den Bypass weg. Eine Person kann es auch für sich selbst setzen.

Wie richten Sie Claude Code Permissions für ein Team ein?

Gehen Sie durch, was Ihre Repositorys schon haben:

Die Reihenfolge zählt. deny-Regeln kosten nichts und stoppen die schlimmsten Fälle ab dem ersten Tag. Der Hook kommt als Nächstes. Isolation brauchen Sie erst, wenn etwas läuft, ohne dass ein Mensch zusieht.

Wie diese Regeln neben CLAUDE.md und den Teamkonventionen stehen, erklärt Regeln für KI-Code im Team. Wie die unbeaufsichtigte Schleife ein Issue bis zum Pull Request bringt, steht in Harness Engineering in der Praxis.

Möchten Sie Agenten, die schnell sind und trotzdem nicht die Produktion brechen?

Wir richten Permission-Regeln, Hooks, Isolation und CI direkt in den Repositorys eines Teams ein, im Rahmen von AI-native SDLC für Entwicklerteams. KI schreibt heute unseren gesamten Code, und ein Senior steht für das Ergebnis gerade. Seit 2023 haben wir 15+ Produktionsprojekte geliefert.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Wie weit käme Ihr Agent heute, wenn niemand eine einzige Rückfrage beantwortet?

Häufige Fragen

Was macht --dangerously-skip-permissions in Claude Code?

Es startet die Session im Modus bypassPermissions, genau wie --permission-mode bypassPermissions. Claude Code fragt nicht mehr vor Befehlen, Änderungen und Abrufen. Explizite ask-Regeln, einige kritische Löschungen und Tools, die einen Menschen brauchen, fragen weiterhin, und Hooks laufen weiter.

Ist der YOLO-Modus von Claude Code sicher?

Nur in einer isolierten Umgebung. Anthropic empfiehlt bypassPermissions ausschließlich in Containern oder VMs, in denen Claude Code keinen Schaden anrichten kann. Auf einem Entwickler-Laptop mit echten Zugangsdaten nehmen Sie besser Permission-Regeln und Hooks.

In welcher Reihenfolge werden allow-, ask- und deny-Regeln geprüft?

Zuerst deny, dann ask, dann allow. Der erste Treffer in dieser Reihenfolge gewinnt. Eine allow-Regel kann also nie eine Ausnahme aus einer deny-Regel herausschneiden, und eine ask-Regel fragt auch dann, wenn eine engere allow-Regel ebenfalls passt.

Wo liegen die Permission-Einstellungen von Claude Code?

In settings.json-Dateien: Managed Settings für die Organisation, ~/.claude/settings.json für eine Person, .claude/settings.json im Repository für das Team und .claude/settings.local.json für lokale Abweichungen. Managed Settings haben Vorrang, und ein deny auf jeder Ebene schlägt ein allow auf jeder anderen.

Wie verhindere ich, dass Entwickler den Bypass-Modus nutzen?

Setzen Sie permissions.disableBypassPermissionsMode auf "disable", am besten in den Managed Settings, wo niemand es überschreiben kann.