Permission budget Claude Code: vérifier droits, coûts et logs en 5 minutes

Pourquoi cinq minutes chaque matin changent tout

Avec Claude Code, la question opérationnelle n’est pas seulement « peut-il coder ? ». Elle est surtout « que peut-il faire sans s’arrêter pour demander ? ». Valider chaque commande Bash semble prudent au début, puis la fatigue d’approbation arrive. Tout autoriser est pire : lecture de .env, installation de paquets, git push, déploiements de production, migrations et changements de facturation se retrouvent trop proches.

Un permission budget est une petite table d’exploitation. Elle dit quelles actions Claude Code peut lancer sans approbation, lesquelles doivent demander à un humain et lesquelles sont interdites dans ce dépôt. La boucle consiste à relire cette table chaque matin avec le journal d’exécution et l’usage de la veille. En langage simple, on recompte les clés et le budget confiés à l’agent.

Au 3 juin 2026, la documentation officielle décrit les règles Claude Code avec allow, ask et deny; deny passe avant ask et allow. /permissions affiche les règles actives et leur fichier source. Côté coûts, /usage donne une vue locale ou de session, tandis que Claude Console reste la référence pour la facturation et les limites workspace. Gardez sous la main Configure permissions, Claude Code settings, Manage costs effectively et la CLI reference.

Pour le contexte interne, reliez cette boucle au guide des permissions Claude Code, à la checklist d’audit des permissions et au permission receipt pattern.

Les bases sans jargon

Les permissions Claude Code sont appliquées par la CLI, pas par la bonne volonté du modèle. Écrire dans CLAUDE.md « ne lis pas les secrets » aide le modèle, mais ce n’est pas une barrière. Une règle deny comme Read(./.env) ou Read(./secrets/**) est une barrière que Claude Code peut appliquer.

Les modes de permission doivent aussi être distingués. default est le flux normal. plan favorise la lecture et l’exploration. acceptEdits facilite les modifications de fichiers. dontAsk refuse les outils qui ne sont pas préapprouvés ou en ask. bypassPermissions, aussi disponible via --dangerously-skip-permissions, supprime les confirmations et doit rester réservé aux conteneurs ou VM isolés.

Le coût suit la même logique. /usage repère une session locale trop chère, mais la facturation API doit être confirmée dans Claude Console. Pour les scripts claude -p, --max-budget-usd et --max-turns sont utiles; ils ne remplacent pas un budget d’équipe.

La boucle quotidienne

La routine doit rester assez courte pour être répétée. L’objectif n’est pas un audit parfait, mais d’éviter de commencer la journée avec une autorisation dangereuse ouverte.

Étape	Vérification	Critère
1	/permissions	Pas de Bash(*) ni de règle trop large comme Bash(npm *)
2	.claude/settings.json	secrets, déploiements, base de données et facturation sont en ask ou deny
3	/usage et Console	La dépense de la veille est expliquée
4	git diff et journal	Le travail autorisé correspond au diff
5	note de relais	Autorisations ouvertes, actions bloquées et prochain reviewer sont notés

Prompt de départ:

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.

Exemple partagé de settings.json

Voici un point de départ pour .claude/settings.json. defaultMode: "dontAsk" est strict : ce qui n’est pas autorisé ou marqué comme ask-first ne s’exécute pas. Testez localement avant d’en faire une règle partagée.

{
  "$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 *)"
    ]
  }
}

Le point clé est la précision. Bash(npm *) peut glisser de test vers install ou publish. Bash(git *) peut glisser de diff vers push. Gardez lecture, lint, test et build en allow étroit; gardez install, push, deploy et apply derrière une validation humaine.

Budget et journal en JSON

Les permissions ne couvrent que la moitié du problème. L’autre moitié est le coût. Une recherche longue, des tests répétés, des sessions en arrière-plan et des logs énormes peuvent coûter cher sans bruit. Un fichier budget et un journal quotidien rendent cette revue visible.

{
  "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"
  ]
}

Placez-les dans .claude/permission-budget.json et .claude/daily-claude-log.json. Un tableur peut servir au reporting, mais JSON est plus simple à relire en PR et à automatiser.

Script Node d’audit

Enregistrez ce fichier sous scripts/audit-claude-loop.mjs, puis lancez node scripts/audit-claude-loop.mjs. Aucune dépendance externe. Le script détecte Bash trop large, deploy dans allow, absence de deny sur .env, dépassement de budget et manque de handoff.

#!/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.");

En CI, commencez par un mode avertissement ou manuel. Une politique trop dure dès le premier jour crée souvent des contournements.

Quatre cas d’usage concrets

Premier cas: articles et documentation. Markdown, MDX, liens internes, CTA, corrections et chemins d’images touchent rarement aux secrets ou à la production. Autorisez étroitement les lectures, git diff, lint, tests et build local pour éviter les interruptions inutiles.

Deuxième cas: dépendances. npm install et pnpm add modifient lockfiles, scripts postinstall, licences, vulnérabilités et bundle size. Placez-les en ask et exigez la raison, l’alternative et le plan de retrait.

Troisième cas: déploiements et migrations. wrangler deploy, vercel deploy, terraform apply, kubectl apply et les migrations changent un état externe. Claude Code peut préparer commande, impact, rollback, URL de vérification et monitoring, mais l’exécution doit être validée par une personne.

Quatrième cas: passage de relais. Si quelqu’un reprend plus tard, il lui faut les permissions ouvertes, les commandes de preuve, les actions bloquées et le budget restant. Sinon, il refait l’analyse et rouvre les mêmes risques.

Erreurs à éviter

La plus fréquente est l’autorisation Bash trop large. Bash(npm *) et Bash(git *) mélangent commandes de lecture et commandes qui changent l’état. Préférez des commandes exactes pour la voie quotidienne.

La deuxième erreur est l’autorisation de deploy oubliée. Pendant un incident, wrangler deploy * peut passer de ask à allow. Si elle reste là le lendemain, le travail normal a accès à la production.

La troisième est d’ignorer la croissance des tokens et du coût. Une recherche longue peut sembler productive tout en consommant le budget. Vérifiez /usage, comparez avec Console si la facturation compte et arrêtez les sessions sans valeur claire.

Enfin, ne confondez pas prompt et enforcement. « Ne lis pas les secrets » guide. Read(./.env) dans deny bloque. Le harness, le cadre de travail de l’agent, demande prompt, settings, logs et review ensemble.

Produits, formation et déploiement d’équipe

Pour pratiquer seul, copiez les JSON et le script dans un petit dépôt. Pour des checklists réutilisables, templates CLAUDE.md et prompts de review, utilisez /products/. Pour un déploiement d’équipe avec permissions, coûts, CI, formation reviewers et règles par dépôt, utilisez /training/.

Note de pratique (実際に試した結果): le gain principal n’est pas venu du blocage de toutes les commandes risquées. Il est venu des cinq minutes passées chaque matin sur /permissions, /usage, git diff et la note de relais. Les règles allow étroites sont restées utiles, tandis que deploys, billing et secrets revenaient toujours en ask ou deny.