Claude Code Security Patterns: Die Permission-Regeln, die ich früher hätte aufsetzen sollen

Standardmäßig kann Claude Code jede Datei lesen und jeden Befehl auf deinem Rechner ausführen. Das ist Absicht — es soll leistungsfähig sein. Aber es heißt auch: Jeder einzelne Bash-Befehl löst eine Freigabe-Anfrage aus, und "nicht mehr fragen" gilt nur für genau diesen einen Befehl. Fragst du morgen anders nach npm run test, gibst du wieder frei. Multipliziere das mit einem echten Arbeitstag, und es nervt genug, dass Leute anfangen, Dinge freizugeben, ohne sie zu lesen — was schlimmer ist als die Popups selbst.

Die drei Permission-Level#

• Dateien lesen — sofort, keine Nachfrage. Code anschauen, Dateien auflisten, suchen.
• Befehle ausführen — braucht deine Freigabe, weil ein Bash-Befehl alles auf deinem Rechner tun kann. Einmal ja sagen, Claude sagen, nicht mehr zu fragen — und es merkt sich das fürs Projekt, aber nur für genau diesen Befehl.
• Dateien ändern — fragt immer. Und anders als bei Befehlen: das setzt sich zurück. Claude Code schließen, und in der nächsten Session fragt es wieder.

Lesen ist sofort. Befehle können dauerhaft werden. Dateiänderungen setzen sich jede Session zurück. Das ist der Standard. Die Lösung für "warum fragt es schon wieder" ist nicht schneller zuzustimmen — es ist, Regeln zu schreiben.

Regeln schreiben statt ewig Ja klicken#

Der schnelle Weg: /permissions eingeben und die Regel beschreiben — das Tool, dann in Klammern, was du willst. bash(npm run test:*) erlaubt alles, was mit npm run test beginnt. Claude schreibt das direkt in deine Settings-Datei.

Die eigentliche Power zeigt sich, wenn du settings.json direkt editierst. Alles liegt unter einem permission-Objekt mit drei Kategorien: allow (tun, keine Nachfrage), ask (immer fragen), deny (komplett blockieren). Die Priorität ist hier wichtig: deny schlägt allow, und allow schlägt ask. Du kannst eine sauber aussehende Allow-Regel schreiben und sie wird still von einer Deny-Regel woanders überschrieben — gut zu wissen, bevor du Zeit damit verbringst zu debuggen, warum ein Befehl immer noch blockiert ist.

Die drei Tools, die auf die drei Permission-Level mappen: read, bash, edit. Du kannst jedes davon zwischen den Kategorien verschieben — Lesen in deny packen, wenn es komplett blockiert sein soll, oder in ask, wenn du eine Nachfrage willst, bevor Claude überhaupt reinschaut.

Secrets konkret vor dem Lesen schützen#

Pfade in diesen Regeln werden relativ zum Ordner aufgelöst, der die settings.json enthält. Eine echte, häufige Regel: Claude komplett das Lesen der .env-Datei verbieten.

{
  "permission": {
    "deny": ["read(./.env)"]
  }
}

Frag Claude danach, was in deiner .env steht, und du bekommst "permission denied" — keine zusammengefasste Antwort, kein Teil-Read. Blockiert.

Im Video#

• 00:04 — Die drei Permission-Level: read, bash, edit
• 01:10 — Warum Freigabe pro Befehl nicht skaliert, und wie Permission-Regeln das lösen
• 02:30 — Der Aufbau der settings.json: allow / ask / deny, und die Prioritätsreihenfolge
• 03:48 — .env-Reads konkret blockieren
• 05:06 — Die Settings-Hierarchie — vier Ebenen, und welche gewinnt

Die Hierarchie, die einem niemand erzählt#

Das ist der Teil, der sich wirklich zu merken lohnt: settings.json ist nicht die einzige Quelle für Permissions, und es gibt eine strikte Reihenfolge, welche gewinnt — wie eine Befehlskette, mächtigste zuerst.

1. Enterprise Policies — vom IT-Admin der Firma gesetzt. Können nicht überschrieben werden, Punkt. Sagt der Admin, niemand darf Dateien löschen, darf niemand Dateien löschen, egal was eine andere Einstellung behauptet.
2. Lokale Projekt-Settings — deine persönlichen Overrides für ein bestimmtes Projekt. Meist in der .gitignore, also nur für dich — extra Schutz, den du willst, selbst wenn das Team mehr erlaubt.
3. Geteilte Projekt-Settings — die Team-Konfiguration, in Git committed. Jeder, der das Repo klont, bekommt dieselben Regeln. Der Großteil deiner projektweiten Security-Policy lebt hier.
4. Persönliche globale Settings — deine Home-Ordner-Defaults, angewendet auf jedes Projekt ohne eigene Regeln.

Worum es eigentlich geht#

Die Popups sind nicht das Problem. Einzeln darauf zu reagieren, ist es. Schreib die Regeln einmal — verbiete, was nie lesbar sein sollte, erlaube die Befehle, die du ständig ausführst, lass ask für das übrig, was wirklich einen zweiten Blick verdient — und setz sie auf der richtigen Ebene der Hierarchie, damit das ganze Team dieselbe Grenze erbt, statt dass jeder still bei unterschiedlichen Dingen Ja klickt.