Claude Code Permission Budget Loop: Rechte, Kosten und Logs in 5 Minuten prüfen

Warum die tägliche Fünf-Minuten-Routine wichtig ist

Bei Claude Code lautet die operative Frage nicht nur: „Kann der Agent Code schreiben?“ Wichtiger ist: „Was darf er ohne Nachfrage tun?“ Jeden Bash-Befehl manuell zu bestätigen wirkt zunächst vorsichtig. Nach vielen Prompts liest aber kaum jemand noch genau. Alles automatisch zu erlauben ist gefährlicher: .env-Dateien, Paketinstallationen, git push, Produktions-Deploys, Datenbankmigrationen und Billing-Änderungen landen dann zu leicht in derselben Spur.

Ein permission budget ist eine kurze Betriebstabelle. Sie legt fest, welche Aktionen Claude Code ohne Freigabe ausführen darf, welche vorher einen Menschen fragen müssen und welche in diesem Repository verboten bleiben. Der Loop ist die Gewohnheit, diese Tabelle jeden Morgen mit dem Ausführungslog und der Nutzung vom Vortag abzugleichen. Einfacher gesagt: Man zählt kurz die Schlüssel und das Budget, die man dem Agenten gegeben hat.

Laut offizieller Dokumentation vom 3. Juni 2026 arbeitet Claude Code mit allow, ask und deny. Deny-Regeln gewinnen vor Ask- und Allow-Regeln. Mit /permissions sieht man aktive Regeln und die jeweilige Settings-Datei. Für Kosten nutzt man /usage als lokale/sessionbezogene Sicht und Claude Console für verbindliche Nutzung und Workspace-Limits. Relevante Quellen sind Configure permissions, Claude Code settings, Manage costs effectively und die CLI reference.

Als interne Vertiefung passen der Claude Code permissions guide, die permission audit checklist und das permission receipt pattern.

Die Grundlagen ohne Sicherheitsjargon

Claude-Code-Permissions sind keine Bitte an das Modell, sondern eine Grenze im CLI. Ein Hinweis in CLAUDE.md wie „lies keine Secrets“ ist wichtig, aber keine technische Sperre. Eine deny-Regel wie Read(./.env) oder Read(./secrets/**) ist dagegen eine Grenze, die Claude Code durchsetzen kann.

Auch Permission-Modes sollte man trennen. default ist der normale Freigabefluss. plan eignet sich für Lesen und Untersuchung. acceptEdits macht Dateiedits flüssiger. dontAsk lehnt Tools ab, wenn sie nicht vorher erlaubt oder als Ask-Regel definiert wurden. bypassPermissions, auch über --dangerously-skip-permissions, überspringt Nachfragen und gehört nur in isolierte Container oder VMs.

Kosten folgen demselben Muster. /usage hilft, eine unerwartet teure Session zu erkennen. Für API-Abrechnung zählt aber die Claude Console. Bei Skriptläufen mit claude -p helfen --max-budget-usd und --max-turns; sie ersetzen jedoch kein Team-Budget.

Der tägliche Permission-Budget-Loop

Die Routine muss klein bleiben, sonst wird sie nicht gemacht. Ziel ist nicht eine perfekte Prüfung, sondern kein gefährlich offenes Recht am Tagesanfang.

Schritt	Prüfung	Kriterium
1	/permissions	Kein Bash(*) und keine zu breite Regel wie Bash(npm *)
2	.claude/settings.json	Secrets, Deploys, Datenbank und Billing stehen in ask oder deny
3	/usage und Console	Die Kosten vom Vortag sind erklärbar
4	git diff und Log	Freigaben und Diff passen zusammen
5	Übergabenotiz	Offene Rechte, blockierte Aktionen und nächster Reviewer sind notiert

Ein kurzer Startprompt reicht:

Before starting today's Claude Code work, classify the task into:
1. safe to run without approval
2. requires human approval
3. should not run in this session

Then list up to five checks for /permissions, /usage, and git diff.

Starter für gemeinsame settings.json

Diese .claude/settings.json ist ein praktischer Ausgangspunkt. defaultMode: "dontAsk" ist streng: Was nicht erlaubt oder als Ask-Regel markiert ist, läuft nicht. Teste das erst lokal, bevor es zur Teamvorgabe wird.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run test *)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git diff *)",
      "WebFetch(domain:code.claude.com)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(pnpm add *)",
      "Bash(git push *)",
      "Bash(wrangler deploy *)",
      "Bash(vercel deploy *)",
      "Bash(terraform apply *)",
      "Bash(kubectl apply *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)"
    ]
  }
}

Wichtig ist die Enge der Regeln. Bash(npm *) kann von Tests zu Installationen oder Publish-Befehlen rutschen. Bash(git *) kann von Diff zu Push rutschen. Lesen, Lint, Test und Build eng erlauben; Install, Push, Deploy und Apply bleiben hinter einer menschlichen Freigabe.

Budget und Ausführungslog als JSON

Permissions sind nur die halbe Schleife. Die andere Hälfte sind Kosten. Lange Untersuchungen, wiederholte fehlschlagende Tests, Hintergrundsessions und große Logs können leise teuer werden. Deshalb gehören Budget und Tageslog in eine reviewbare Datei.

{
  "date": "2026-06-03",
  "dailyLimitUsd": 6,
  "warnAtUsd": 4,
  "usageSource": "/usage plus Claude Console",
  "safeAllow": [
    "Bash(npm run lint)",
    "Bash(npm run test)",
    "Bash(git diff *)"
  ],
  "askFirst": [
    "Bash(npm install *)",
    "Bash(git push *)",
    "Bash(wrangler deploy *)"
  ],
  "mustDeny": [
    "Read(./.env)",
    "Read(./.env.*)",
    "Read(./secrets/**)"
  ],
  "handoffRequired": true
}

{
  "date": "2026-06-03",
  "spentUsd": 1.85,
  "usageChecked": true,
  "settingsChecked": true,
  "permissionsReviewed": [
    "/permissions",
    ".claude/settings.json"
  ],
  "openAllowances": [
    "Bash(npm run lint)",
    "Bash(npm run test *)"
  ],
  "handoff": [
    "No deploy allowance left open",
    "Claude stopped before production data work"
  ]
}

Speichere sie als .claude/permission-budget.json und .claude/daily-claude-log.json. Ein Spreadsheet ist für Managementberichte okay, aber JSON ist besser für PRs und Automatisierung.

Node-Audit-Skript zum Kopieren

Speichere die Datei als scripts/audit-claude-loop.mjs und führe node scripts/audit-claude-loop.mjs aus. Es braucht keine externen Pakete und prüft breite Bash-Rechte, Deploy-Befehle im Allow-Bereich, fehlende .env-Deny-Regeln, Budgetüberschreitungen und fehlende Übergaben.

#!/usr/bin/env node
import fs from "node:fs";

const readJson = (file) => JSON.parse(fs.readFileSync(file, "utf8"));

const budget = readJson(".claude/permission-budget.json");
const log = readJson(".claude/daily-claude-log.json");
const settings = readJson(".claude/settings.json");

const problems = [];
const permissions = settings.permissions ?? {};
const allow = new Set(permissions.allow ?? []);
const ask = new Set(permissions.ask ?? []);
const deny = new Set(permissions.deny ?? []);
const hasPattern = (items, pattern) => [...items].some((item) => pattern.test(item));

if (typeof budget.dailyLimitUsd !== "number" || budget.dailyLimitUsd <= 0) {
  problems.push("dailyLimitUsd must be a positive number");
}

if (typeof budget.warnAtUsd !== "number" || budget.warnAtUsd >= budget.dailyLimitUsd) {
  problems.push("warnAtUsd must be lower than dailyLimitUsd");
}

if (log.spentUsd > budget.dailyLimitUsd) {
  problems.push(`spentUsd ${log.spentUsd} exceeds daily limit ${budget.dailyLimitUsd}`);
}

if (log.spentUsd >= budget.warnAtUsd) {
  console.warn(`WARN: spentUsd ${log.spentUsd} has reached warnAtUsd ${budget.warnAtUsd}`);
}

if (!log.usageChecked) problems.push("Run /usage and mark usageChecked true");
if (!log.settingsChecked) problems.push("Review /permissions and mark settingsChecked true");

if (allow.has("Bash") || allow.has("Bash(*)") || hasPattern(allow, /^Bash\(\*.*\)$/)) {
  problems.push("Do not allow every Bash command");
}

if (hasPattern(allow, /(deploy|terraform apply|kubectl apply|git push)/)) {
  problems.push("Deploy, infrastructure, and push commands must be ask-first, not allow");
}

for (const rule of budget.askFirst ?? []) {
  if (!ask.has(rule)) problems.push(`Missing ask rule: ${rule}`);
}

for (const rule of budget.mustDeny ?? []) {
  if (!deny.has(rule)) problems.push(`Missing deny rule: ${rule}`);
}

if (!hasPattern(deny, /Read\(.*\.env/)) {
  problems.push("Deny rules should block .env reads");
}

if (!Array.isArray(log.handoff) || log.handoff.length === 0) {
  problems.push("Add at least one handoff note");
}

if (problems.length) {
  console.error(problems.map((problem) => `- ${problem}`).join("\n"));
  process.exit(1);
}

console.log("Claude Code daily permission budget check passed.");

Für CI sollte man zuerst mit Warnungen oder manueller Ausführung starten. Eine Permission Policy funktioniert nur, wenn das Team sie versteht.

Vier konkrete Einsatzfälle

Der erste Einsatzfall sind Artikel und Dokumentation. Markdown, MDX, interne Links, CTAs, Tippfehler und Bildpfade berühren meist keine Secrets und keine Produktion. git diff, Lint, Tests und lokale Builds können eng erlaubt werden.

Der zweite Einsatzfall sind Dependency-Änderungen. npm install und pnpm add beeinflussen Lockfiles, Postinstall-Skripte, Lizenzen, Vulnerabilities und Bundle-Größe. Diese Befehle gehören in ask; Claude Code soll vor der Freigabe Zweck, Alternative und Rückbauplan nennen.

Der dritte Einsatzfall sind Deploys und Migrationen. wrangler deploy, vercel deploy, terraform apply, kubectl apply und DB-Migrationen verändern externe Zustände. Claude Code kann Befehl, Impact, Rollback, Prüf-URL und Monitoring vorbereiten. Ausführen sollte ein Mensch freigeben.

Der vierte Einsatzfall ist die Teamübergabe. Wenn später jemand übernimmt, braucht diese Person offene Rechte, Proof-Commands, blockierte Aktionen und Restbudget. Sonst wiederholt sie dieselbe Analyse und öffnet dieselbe riskante Erlaubnis erneut.

Typische Fehler

Der häufigste Fehler ist eine zu breite Bash-Erlaubnis. Bash(npm *) und Bash(git *) sind bequem, vermischen aber lesende Gewohnheiten mit zustandsändernden Befehlen. Besser sind exakte Kommandos für die tägliche Spur.

Der zweite Fehler ist eine vergessene Deploy-Erlaubnis. Während eines Incidents wird wrangler deploy * schnell von Ask nach Allow geschoben. Bleibt es dort, hat normale Feature-Arbeit am nächsten Morgen Produktionsmacht.

Der dritte Fehler ist ignoriertes Kostenwachstum. Eine lange Analyse fühlt sich produktiv an, kann aber Budget verbrennen. Prüfe /usage, vergleiche bei Bedarf mit Console und stoppe Sessions ohne klaren Nutzen.

Der vierte Fehler ist die Verwechslung von Prompt und Durchsetzung. „Lies keine Secrets“ ist Anleitung. Read(./.env) in deny ist Durchsetzung. Der Harness, also das Arbeitsgerüst des Agenten, braucht Prompt, Settings, Logs und Review zusammen.

Produkte, Training und Rollout

Für den Einzelstart kopiere JSON-Dateien und Skript zuerst in ein kleines Repository. Wiederverwendbare Checklisten, CLAUDE.md-Templates und Review-Prompts stehen unter /products/. Für Team-Rollout mit Permissions, Kostenkontrolle, CI-Regeln, Reviewer-Training und repo-spezifischen Vorgaben ist /training/ der passende nächste Schritt.

Praxisnotiz (実際に試した結果): Die größte Verbesserung kam nicht davon, jeden riskanten Befehl zu blockieren. Sie kam durch fünf Minuten Prüfung von /permissions, /usage, git diff und Übergabenotiz am Morgen. Enge Allow-Regeln blieben nützlich, während Deploys, Billing und Secrets zuverlässig wieder in Ask oder Deny landeten.