CGS IT Solutions GmbH — Claude Code Training · Erweiterung 3 · Permissions · v0.10.0

Erweiterung 3

Permissions im Detail

Vertiefung zu Modul 9 · Regeln, Muster, Auto-Mode

Inhalt

1Vier Antworten — allow, ask, deny, Klassifizierer 2Matching bei Bash — wo Muster danebengreifen 3Pfade — Anker und Tiefe 4Auto-Mode — und warum er keine Grenze ist 5Zaun, Netz, Firma — wo Regeln enden Glossar — Begriffe zum Nachschlagen

Was dieses Deck ergänzt

Modul 9 sagt, dass man den Radius eng zieht. Hier geht es darum, ob die Regel wirklich fängt, was sie fangen soll.

  1. Die Reihenfolge ist fest und Spezifität ändert nichts. Ein breites deny kann keine Ausnahme tragen.
  2. Bash-Muster greifen anders, als man denkt. Ein Leerzeichen entscheidet, Wrapper werden entfernt, eine Klasse von Werkzeugen umgeht alles.
  3. Pfad-Anker sind vier, und der naheliegendste ist der falsche.
  4. Auto-Mode ist ein zweites Tor, aber ausdrücklich keine Richtliniengrenze.
# Begleitprojekt, zwei Teile
examples/permissions-demo/
  .claude/settings.json # zum Ausloesen
  secrets/     # deny greift hier
  protected/   # lesen ja, aendern nein
  match.py     # Muster gegen Befehl
  verify.sh

# match.py prueft jedes Ergebnis gegen
# eine ERWARTUNG und endet mit Exit 1,
# wenn eines abweicht.

Vier Antworten

allow, ask, deny — und der Klassifizierer

Die Reihenfolge ist fest

deny, dann ask, dann allow. Der erste Treffer in dieser Reihenfolge entscheidet — und die Spezifität einer Regel ändert daran nichts.

  1. Ein breites deny kann keine Ausnahme tragen. Bash(aws *) in deny blockiert auch Bash(aws s3 ls) aus allow.
  2. Dasselbe zwischen ask und allow: eine passende ask-Regel fragt, auch wenn ein engeres allow denselben Aufruf trifft.
  3. Regeln werden über die Scopes hinweg zusammengeführt, nicht überschrieben. Ein deny auf irgendeiner Ebene gewinnt.
  4. Trifft keine Regel, gilt der Berechtigungsmodus.
„Permission rules are enforced by Claude Code, not by the model." Was im Prompt oder in CLAUDE.md steht, formt nur, was versucht wird — nicht, was erlaubt ist.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Nackter Name gegen Muster

Dieselbe Absicht, zwei ganz verschiedene Mechanismen. Der Unterschied entscheidet, ob Claude Code das Werkzeug überhaupt sieht.

deny-RegelWirkung
Bash (oder Bash(*))entfernt das Werkzeug ganz aus dem Kontext — es existiert für Claude Code nicht
Bash(rm *)lässt das Werkzeug verfügbar und blockiert erst beim Versuch
Beides ist manchmal richtig. Ein entferntes Werkzeug spart Kontext und verhindert Versuche; ein blockiertes Muster erzeugt eine sichtbare Ablehnung, aus der Claude Code lernen kann. EndConversation ist die Ausnahme: es lässt sich nicht entfernen, solange ein anderes Werkzeug bleibt.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Geschützte Pfade

Ein kleiner Satz Pfade wird nie automatisch genehmigt — und permissions.allow kann daran nichts ändern.

  1. Geschützt sind unter anderem .git, .config/git und .claude — Repository-Zustand und die eigene Konfiguration von Claude Code.
  2. Die Sicherheitsprüfung läuft vor den allow-Regeln. Ein Edit(.claude/**) in den Settings ändert das Ergebnis nicht.
  3. Ausnahme ist nur bypassPermissions und Planung mit verfügbarem Bypass.
  4. In den fragenden Modi bietet die Rückfrage an, Änderungen an .claude/ für diese Sitzung freizugeben.
Das ist die Antwort auf „ich habe es doch erlaubt". Manche Grenzen sind keine Regeln, sondern eingebaute Prüfungen — sie stehen vor der Regelauswertung und lassen sich nicht wegkonfigurieren.
checked am 2026-07-29 gegen code.claude.com/docs/en/permission-modes

Matching bei Bash

Wo Muster greifen — und wo sie danebengreifen

Das Leerzeichen entscheidet

Ein Stern trifft beliebige Zeichenfolgen einschließlich Leerzeichen — ein Platzhalter kann also mehrere Argumente überspannen. Das Leerzeichen davor erzwingt eine Wortgrenze.

  1. Bash(ls *) trifft ls -la, aber nicht lsof.
  2. Bash(ls*) trifft beide — ohne Leerzeichen keine Wortgrenze.
  3. Bash(ls:*) ist gleichbedeutend mit Bash(ls *). Der Freigabedialog schreibt die Leerzeichen-Form.
  4. Aber nur am Ende: in Bash(git:* push) ist der Doppelpunkt ein wörtliches Zeichen und trifft keine Git-Befehle.
$ python3 match.py

ls -la            allow
lsof -i           fragt nach
git merge main    allow

# 'git * main' trifft 'git merge main'
# UND 'git push origin main' -- ein
# Stern ueberspannt beide Argumente.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Wrapper werden entfernt

Vor dem Abgleich entfernt Claude Code einen festen, nicht konfigurierbaren Satz Wrapper. Was nicht darin steht, ist die Lücke.

  1. Entfernt: timeout, time, nice, nohup, stdbuf, command, builtin, noglob. Also trifft Bash(npm test *) auch timeout 30 npm test.
  2. Nacktes xargs auch — aber xargs -n1 … nicht: mit Flags gilt es als eigener Befehl.
  3. Führende Variablenzuweisungen werden bei allow nur für bekannte Variablen entfernt, bei deny und ask für jede.
  4. watch, setsid, flock und find -exec fragen immer und lassen sich nicht per Präfix freigeben.
Umgebungs-Runner stehen nicht in der Liste. Bash(devbox run *) erlaubt alles, was nach run kommt — einschließlich devbox run rm -rf .. Dasselbe gilt für direnv exec, mise exec, npx und docker exec.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Zusammengesetzte Befehle

Claude Code kennt Shell-Operatoren. Eine Regel muss jeden Teilbefehl einzeln treffen — sonst greift sie nicht.

  1. Erkannte Trenner: &&, ||, ;, |, |&, & und Zeilenumbrüche.
  2. Bash(safe-cmd *) erlaubt nicht safe-cmd && other-cmd — und genau deshalb ist Bash(command:rm *) als Parameterregel verboten und wird mit Startwarnung ignoriert.
  3. Bei „nicht mehr fragen" wird pro Teilbefehl eine eigene Regel gespeichert, höchstens fünf.
  4. Ein fester Nur-Lese-Satz läuft in jedem Modus ohne Rückfrage: ls, cat, grep, find, wc, lesende Formen von git und weitere. Nicht konfigurierbar.
Der Nur-Lese-Satz ist in der Doku nicht vollständig aufgezählt — sie schreibt „these include". Auf einer Folie darf er deshalb nicht als vollständige Liste erscheinen. Wer eine Rückfrage für einen davon will, braucht eine ask- oder deny-Regel.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Warum Argument-Muster brüchig sind

Die Doku warnt ausdrücklich: Muster, die Argumente einschränken sollen, halten nicht. Fünf Varianten genügen, um daran vorbeizukommen.

  1. Option vor der Adresse: curl -X GET http://…
  2. Anderes Protokoll: https:// statt http://
  3. Weiterleitung: curl -L http://kurz.example.com/xyz landet doch bei GitHub
  4. Variable: URL=http://github.com && curl $URL
  5. Doppeltes Leerzeichen. Reicht schon.
Und der Satz, der die ganze Folie trägt: curl zu verbieten verhindert keinen Netzzugriff. Es verbietet einen Weg. Ist Bash erlaubt, erreicht Claude Code jede Adresse — mit wget, mit Python, mit dem nächsten Werkzeug.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Pfade

Vier Anker und zwei Tiefen

Vier Anker — einer ist eine Falle

Read- und Edit-Regeln benutzen gitignore-Syntax. Der Anker entscheidet, wogegen ein Pfad aufgelöst wird.

MusterBedeutung
//pfadabsolut, ab Dateisystem-Wurzel
~/pfadab Heimatverzeichnis
/pfadrelativ zur Settings-Quelle — nicht zur Wurzel
pfad oder ./pfadrelativ zum aktuellen Verzeichnis
Read(/secrets/**) in den User-Settings blockiert ~/.claude/secrets/** — und nicht das Projektverzeichnis. Wer aus den User-Settings in jedes Projekt wirken will, braucht // oder ~/.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

allow und deny treffen verschieden tief

Dieselbe Zeile, zwei Bedeutungen — je nachdem, in welcher Rolle sie steht. Bei einem relativen Muster mit einem Verzeichnissegment.

  1. Als allow trifft Edit(src/**) nur <cwd>/src und darunter.
  2. Als deny oder ask trifft dieselbe Zeile ein src in jeder Tiefe — also auch vendor/pkg/src/.
  3. Für jede Tiefe auch bei allow: Edit(**/src/**) schreiben.
  4. Nackte Dateinamen folgen gitignore-Semantik und treffen überall: Read(.env) ist dasselbe wie Read(**/.env).
Das ist bequem und richtig: eine Schutzregel soll auch die verschachtelte Kopie treffen, eine Freigabe soll das nicht. Bei Symlinks dieselbe Logik — allow verlangt, dass beide Pfade passen, deny greift, wenn einer passt.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Auto-Mode

Das zweite Tor — und warum es keine Grenze ist

Der Klassifizierer

Auto-Mode lässt Claude Code ohne die üblichen Rückfragen laufen, indem Aufrufe durch einen Klassifizierer gehen. deny- und ask-Regeln werden vorher ausgewertet.

  1. Er blockt, was unumkehrbar oder zerstörend ist oder aus der eigenen Umgebung hinausführt.
  2. Standardmäßig traut er nur dem Arbeitsverzeichnis und den Remotes des aktuellen Repositorys. Alles andere ist geblockt, bis es in environment steht.
  3. Er liest dieselbe CLAUDE.md wie das Modell. „Niemals force-pushen" dort steuert damit beide.
  4. Nicht aus Projekt- und Local-Settings — ein eingecheckter Stand könnte sich sonst selbst Freigaben schreiben.
Zwei nicht-interaktive Befehle zum Nachsehen: claude auto-mode defaults druckt die eingebauten Regeln, claude auto-mode config die wirksame Konfiguration samt eigener Einträge.
checked am 2026-07-29 gegen code.claude.com/docs/en/auto-mode-config

Vier Stufen im Klassifizierer

Innerhalb des Klassifizierers gilt eine eigene Rangfolge — und die vierte Stufe ist die interessante.

  1. hard_deny blockt unbedingt. Absicht und allow greifen nicht.
  2. soft_deny blockt als Nächstes — hier können Absicht und allow aufheben.
  3. allow hebt passende soft-Regeln auf, als Ausnahme.
  4. Ausdrückliche Absicht hebt den Rest auf — aber nur, wenn die Nachricht unmittelbar und genau die anstehende Handlung beschreibt.
„Räum das Repository auf" erlaubt kein Force-Push. „Force-push diesen Branch" erlaubt es. Allgemeine Aufträge zählen nicht als Absicht.
checked am 2026-07-29 gegen code.claude.com/docs/en/auto-mode-config

Auto-Mode ist keine Grenze

Die Einträge aller Ebenen werden zusammengeführt. Eine Entwicklerin kann Firmen-Einträge nicht entfernen — aber sie kann sie aushebeln.

  1. Ein selbst hinzugefügtes allow hebt ein soft_deny der Organisation auf, weil allow-Regeln innerhalb des Klassifizierers als Ausnahmen wirken.
  2. Die Doku sagt es selbst: „additive, not a hard policy boundary."
  3. Wer eine echte Grenze braucht, nimmt permissions.deny in den Managed Settings — das blockt, bevor der Klassifizierer befragt wird.
Das ist die Folie, die man einer Sicherheitsabteilung zeigt. Der Klassifizierer ist Komfort, nicht Kontrolle. Er senkt Abfragemüdigkeit; er ersetzt keine Richtlinie.
checked am 2026-07-29 gegen code.claude.com/docs/en/auto-mode-config

Zaun, Netz, Firma

Wo Regeln enden und etwas anderes anfängt

Wo Permissions enden

Drei Werkzeuge, drei Reichweiten. Die Rangfolge zwischen Regel und Hook ist dabei in beide Richtungen festgelegt.

  1. Hooks umgehen Regeln nicht: deny und ask werden unabhängig ausgewertet — auch wenn ein Hook "allow" zurückgibt.
  2. Aber ein blockierender Hook schlägt allow: Exit-Code 2 stoppt den Aufruf, bevor die Regeln ausgewertet werden.
  3. Daraus folgt das Muster: "Bash" in allow, und ein PreToolUse-Hook lehnt die wenigen verbotenen Befehle ab.
  4. Die Sandbox ist die dritte Ebene — Durchsetzung auf Betriebssystemebene, aber nur für Bash und dessen Kindprozesse.
Die Sandbox trägt den Fall, den keine Regel trägt: sie hält, auch wenn eine Prompt-Injection die Entscheidung von Claude Code unterläuft. Regel und Sandbox werden zusammengeführt, nicht gegeneinander ausgespielt.
checked am 2026-07-29 gegen code.claude.com/docs/en/permissions

Wenn die Firma entscheidet

Einige Schlüssel gelten nur in Managed Settings. Teilnehmer:innen begegnen ihnen als Betroffene — es lohnt, sie zu erkennen.

  1. allowManagedPermissionRulesOnly — eigene allow-, ask- und deny-Regeln gelten nicht mehr.
  2. allowManagedHooksOnly — eigene Hooks werden nicht geladen.
  3. disableSkillShellExecution — eingebettete Kommandos in Skills laufen nicht, sondern werden durch einen Hinweis ersetzt.
  4. strictPluginOnlyCustomization — Skills, Agenten, Hooks und MCP-Server dürfen nur aus Plugins kommen.
Und die tröstliche Eigenschaft: Managed Settings sind fehlertolerant. Ein ungültiger Eintrag wird einzeln entfernt, der Rest gilt weiter — ein Tippfehler kann die Firmenrichtlinie nicht abschalten. Eigene Settings sind streng: dort verwirft ein Syntaxfehler die ganze Datei.
checked am 2026-07-29 gegen code.claude.com/docs/en/settings

Erweiterung 3 in fünf Sätzen

Was von diesem Deck hängenbleiben soll.

  1. deny, ask, allow — und Spezifität zählt nicht. Ein breites deny kann keine Ausnahme tragen.
  2. Das Leerzeichen vor dem Stern entscheidet, und Wrapper werden vorher entfernt. Umgebungs-Runner nicht: Bash(devbox run *) erlaubt alles.
  3. curl zu verbieten verhindert keinen Netzzugriff, sondern einen Weg. Argument-Muster halten nicht.
  4. Ein einzelner Schrägstrich ist kein absoluter Pfad, und dieselbe Pfadregel trifft als deny tiefer als als allow.
  5. Auto-Mode ist Komfort, nicht Kontrolle. Die echte Grenze ist permissions.deny in Managed Settings.

Glossar Glossar

Permission-Regel Ein Eintrag der Form Werkzeug oder Werkzeug(Muster) in allow, ask oder deny. Durchgesetzt von Claude Code selbst, nicht vom Modell.
Klassifizierer (Auto-Mode) Ein zweites Tor nach den Permission-Regeln, das unumkehrbare, zerstörende und nach außen führende Handlungen blockt. Gesteuert über Prosa-Regeln in autoMode. Komfort, keine Richtliniengrenze.
Managed Settings Von der Organisation ausgerollte Konfiguration, die keine andere Ebene überschreiben kann — auch kein Kommandozeilenargument. Einzige Ebene, auf der bestimmte Sperrschlüssel gelten.
Workspace Trust Die Bestätigung, dass man einem Projektverzeichnis vertraut. Erst danach wirken allow-Regeln und zusätzliche Verzeichnisse aus der Projektkonfiguration. deny und ask sind davon unberührt.
MCP (Model Context Protocol) Offenes Protokoll, über das Claude Code fremde Systeme als Werkzeuge anbindet. Für Permissions relevant, weil MCP-Werkzeuge eigene Regelformen haben: mcp__server für alle Werkzeuge eines Servers, mcp__server__tool für eines.
Sandbox Durchsetzung auf Betriebssystemebene für Dateisystem und Netz, die nur Bash-Befehle und deren Kindprozesse betrifft. Hält auch dann, wenn die Entscheidung des Modells unterlaufen wurde.

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Erweiterung 3 · Permissions · v0.10.0