Règles de permission de Claude Code et settings.json

Les règles de permission de Claude Code vous permettent d'écrire des entrées allow / ask / deny dans settings.json pour préciser, de façon fine, quels outils, commandes, fichiers et domaines s'exécutent sans demander, sollicitent une confirmation à chaque fois, ou sont interdits. Elles peuvent être partagées au sein d'une équipe : vous bloquez à coup sûr les opérations dangereuses tout en laissant le travail sûr et routinier s'exécuter sans interruption.

Ce guide explique ce que sont les règles de permission (et en quoi elles diffèrent des modes de permission), l'ordre de priorité allow/ask/deny, la syntaxe des règles, la hiérarchie de settings.json et des recettes pratiques — le tout basé sur la spécification officielle.

1. Ce que sont les règles de permission (vs les modes)

Claude Code utilise un système de permissions à plusieurs niveaux. Les lectures (consultation de fichiers, Grep, etc.) ne nécessitent aucune approbation ; les commandes Bash et les modifications de fichiers, si — et par-dessus cette base, les règles vous permettent de préciser des exceptions fines (source : la documentation officielle « Configure permissions » de Claude Code).

Il est facile de confondre les règles et les modes de permission. Les modes constituent la base générale du « à quelle fréquence il demande » (default/acceptEdits/auto, etc.) ; les règles sont des spécifications par outil, par commande. Les deux fonctionnent ensemble : le mode fixe la base, et les règles le surchargent avec « toujours autoriser ceci » ou « ne jamais autoriser cela ».

2. allow / ask / deny et l'ordre de priorité

Il existe trois types de règles. La commande /permissions les liste et les édite (et indique de quel settings.json chacune provient).

Les règles sont évaluées dans l'ordre deny → ask → allow. La première correspondance détermine le résultat, et la spécificité d'une règle ne change pas cet ordre. Un deny large Bash(aws *) l'emporte sur un allow plus spécifique Bash(aws s3 ls). L'essentiel : un deny ne peut pas comporter d'exceptions de liste d'autorisation.

3. Syntaxe des règles (Tool(specifier))

Le format est Tool (tout) ou Tool(specifier) (spécifique). Chaque outil a son propre style de specifier.

Les jokers de Bash peuvent apparaître n'importe où. Bash(ls *) (espace + *) correspond à ls -la mais pas à lsof (limite de mot) ; Bash(ls*) (sans espace) correspond aux deux. Un :* final équivaut à *.

// Autoriser les commandes sûres, refuser git push
{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Attention aux commandes composées. Claude Code comprend les séparateurs tels que && || ; |, et chaque sous-commande doit correspondre indépendamment. Bash(safe-cmd *) n'autorise pas safe-cmd && rm -rf .. Notez que les commandes en lecture seule (ls/cat/grep/find/pwd, etc.) s'exécutent sans confirmation dans tous les modes, et que les wrappers comme timeout/nice/nohup sont retirés avant la comparaison.

Les chemins Read/Edit suivent la sémantique de gitignore avec quatre ancrages :

※ /Users/... n'est PAS absolu — il est relatif à la racine du projet. Utilisez //Users/... (double barre oblique) pour les chemins absolus. Read(.env) équivaut à Read(**/.env) et correspond à tous les .env en dessous.

4. Hiérarchie et priorité de settings.json

Les règles se trouvent dans settings.json. Il existe plusieurs fichiers, et les niveaux supérieurs sont plus forts. La règle clé : un deny à n'importe quel niveau l'emporte toujours sur un allow à n'importe quel autre niveau.

// .claude/settings.json (partagé en équipe)
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)", "WebFetch(domain:docs.example.com)"],
    "deny": ["Read(.env)", "Read(**/secrets/**)", "Bash(git push *)"],
    "additionalDirectories": ["../shared-lib"]
  }
}

Le mode de permission par défaut se définit ici aussi, via defaultMode (détails sur les modes). Pour lire/modifier en dehors du répertoire de travail, ajoutez des chemins à additionalDirectories.

5. Recettes pratiques

Des combinaisons courantes. La forme de base : refuser à coup sûr les opérations dangereuses, autoriser la routine sûre pour l'automatiser.

Restreindre les URL via des motifs d'arguments Bash est fragile (curl http://github.com/ * se contourne facilement avec -X GET ou l'expansion de variables). À la place, refusez curl/wget et autorisez des domaines précis avec WebFetch(domain:...). Pour un contrôle plus strict, validez les URL dans un hook PreToolUse.

6. Pièges et confusions courantes

• Le deny est appliqué par Claude Code, pas par le modèle. Écrire « ne lis pas ceci » dans votre prompt ou votre CLAUDE.md ne l'empêchera pas sans une règle.
• Un deny Read/Edit ne peut pas empêcher un accès indirect. Il s'applique aux outils de fichiers intégrés et à cat/head/sed, mais pas à un script Python ou Node qui ouvre lui-même les fichiers. Pour une application au niveau du système d'exploitation, utilisez aussi le sandboxing.
• Méfiez-vous des lanceurs d'environnement. devbox run *, npx et docker exec exécutent leurs arguments comme une commande, donc Bash(devbox run *) permet aussi devbox run rm -rf .. Écrivez des règles qui incluent la commande interne.
• Les hooks ne surchargent pas les règles. Un hook PreToolUse peut étendre les permissions, mais deny/ask sont évalués indépendamment de ce que renvoie le hook (la priorité du deny reste inchangée).

※ Le comportement décrit suit la documentation officielle de Claude Code (Configure permissions / Settings), à jour en juin 2026. Il peut évoluer — consultez la documentation officielle pour les informations les plus récentes.

Résumé

Trois points à retenir sur les règles de permission de Claude Code.

• Ce qu'elles sont : allow/ask/deny dans settings.json pour autoriser/demander/interdire par outil, commande, fichier et domaine. Les modes fixent la base ; les règles gèrent les détails.
• Priorité : deny → ask → allow (la première correspondance l'emporte ; la spécificité est sans effet). Un deny à n'importe quel niveau gagne toujours. Niveaux : managed > CLI > local > projet > utilisateur.
• Syntaxe : Tool(specifier). Bash utilise des jokers (espace + * est une limite de mot), Read/Edit utilisent des chemins de style gitignore, WebFetch utilise domain:. Les commandes composées exigent que chaque sous-commande corresponde.

« Bloquer à coup sûr les opérations dangereuses, automatiser la routine sûre » est le cœur de la conception des règles. Combinez cela avec les modes de permission, les hooks et le réglage de l'effort pour utiliser Claude Code de façon sûre et fluide.

FAQ