.claude/settings.json d'équipe : permissions allow, ask, deny

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run typecheck)",
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git branch *)"
    ],
    "ask": ["Bash(git commit *)", "Bash(git push *)", "Bash(npm install *)"],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Edit(./.env)",
      "Edit(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

Par défaut, Claude Code demande votre accord avant d'exécuter une commande shell ou de modifier un fichier. C'est prudent, mais vite fastidieux pour des commandes sans risque comme le lint ou les tests. Le fichier .claude/settings.json, versionné avec le projet, permet de fixer pour toute l'équipe ce qui est autorisé d'office, ce qui doit être confirmé et ce qui est interdit.

Les trois listes

• allow : exécuté sans demande. Le modèle y place le lint, la vérification des types, le build, les tests et les commandes Git en lecture (status, diff, log, branch).
• ask : toujours soumis à confirmation, même si une règle allow plus large correspond. Ici : git commit, git push, npm install.
• deny : refusé. Le modèle bloque la lecture et l'édition des fichiers .env, le dossier secrets/, les suppressions récursives, les réécritures d'historique et les téléchargements par curl ou wget.

L'ordre d'évaluation est deny, puis ask, puis allow : une règle deny ne peut pas être contournée par une règle allow plus précise.

Syntaxe des règles

• Bash(npm run test *) : l'étoile précédée d'une espace couvre les arguments, et la commande seule aussi. L'ancienne forme Bash(npm run test:*) reste reconnue en fin de motif, mais la documentation utilise désormais l'espace.
• Read(./.env) et Edit(./.env) : chemins relatifs au répertoire courant, avec une syntaxe proche de .gitignore (** pour tous les sous-dossiers).
• Claude Code reconnaît les opérateurs du shell : autoriser Bash(npm test *) ne permet pas npm test && rm -rf build, car chaque sous-commande doit être autorisée séparément.

La ligne $schema active l'autocomplétion et la validation dans les éditeurs compatibles.

Comment l'adapter

1. Remplacez les scripts npm par ceux de votre projet (pnpm, make, uv run pytest…).
2. Ajoutez vos fichiers sensibles aux règles deny (clés, certificats, exports de données).
3. Gardez vos réglages personnels dans .claude/settings.local.json, non versionné, placé au-dessus du fichier partagé dans l'ordre de priorité des réglages.

Pièges fréquents

• Se fier aux motifs d'arguments : une règle comme Bash(curl http://exemple.com/ *) se contourne facilement ; la documentation déconseille de filtrer finement les arguments.
• Règles sur Write : les vérifications de chemin ne consultent que les règles Read(...) et Edit(...). Écrivez Edit(docs/**) et non Write(docs/**).
• Tout autoriser pour aller vite : chaque entrée allow doit rester inoffensive, car elle s'applique à toute l'équipe.

La commande /permissions affiche les règles actives par portée. La leçon Installation et configuration présente les différents fichiers de réglages.