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

Les règles de permission de Claude Code utilisent allow / ask / deny dans settings.json pour définir les outils, commandes, fichiers et domaines autorisés sans confirmation, demandant une approbation ou interdits. Les équipes peuvent les partager pour refuser les appels correspondants et réduire les approbations des tâches courantes déjà examinées. Elles ne bloquent pas uniformément les variantes d'écriture du même programme ni l'accès via des scripts.

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 d'autorisations à plusieurs niveaux. En Manual, les lectures de l'espace de travail ne demandent normalement pas confirmation ; l'édition et Bash, si, avec des exceptions comme les commandes intégrées en lecture seule et allow. Sur cette base, les règles définissent des exceptions individuelles (source : documentation officielle « Configure permissions »).

Les règles se confondent facilement avec les modes de permission. Les modes définissent la politique générale de confirmation (default, acceptEdits, auto, etc.) ; les règles précisent outils et commandes. Les modes fixent la base, les règles la modifient avec « toujours autoriser ceci » ou « refuser cet appel ».

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 deny → ask → allow. Dans les règles ordinaires de réglages, la première correspondance détermine le résultat ; la spécificité ne change pas cet ordre. Un deny large Bash(aws *) bloque même un allow plus précis Bash(aws s3 ls). L'essentiel : allow ne remplace pas un deny correspondant. La négation des chemins relatifs Read/Edit est une fonction distincte.

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 règles MCP ne s'appliquent qu'au serveur qu'elles désignent. À partir de la v2.1.299 (14 octobre 2026), mcp__a n'autorise pas les autres serveurs nommés a__b ou a_. Pour un serveur dont le nom contient __ ou se termine par _, écrivez le nom normalisé complet suivi de __*, comme dans mcp__reports__v2__* (documentation officielle et historique des versions, vérifié le 18 octobre 2026).

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 ou refuser des appels précis ne bloque pas toutes les voies vers le même programme
{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Les commandes composées sont évaluées par sous-commande ; les wrappers reconnus sont retirés avant l'évaluation. Mais les variantes d'écriture du même programme ne correspondent pas nécessairement : Bash(git push *) ne correspond pas à git -C . push. Les commandes intégrées en lecture seule évitent normalement la confirmation, mais les restrictions de lecture hors de l'espace de travail et l'attente du classificateur auto sont distinctes.

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

* /Users/... n'est PAS absolu — il est relatif à l'ancre du fichier de paramètres (la racine du projet pour les paramètres du projet). Dans les paramètres utilisateur, Read(/secrets/**) désigne ~/.claude/secrets/** ; pour une règle valable dans tous les projets, utilisez // ou ~/. 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

La hiérarchie détermine les valeurs des réglages. Pour les règles de permission, un deny correspondant est évalué avant allow. Le tableau décrit la priorité entre fichiers de réglages et règles CLI, sans garantie absolue couvrant aussi les décisions modifiées par les mods.

// .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). Attention : auto et bypassPermissions n'ont pas d'effet dans les réglages de projet (.claude/settings.json, .claude/settings.local.json) ; placez-les dans les réglages utilisateur ou gérés. Pour lire/modifier en dehors du répertoire de travail, ajoutez des chemins à additionalDirectories.

5. Recettes pratiques

Commencez par limiter allow aux appels courants examinés et appliquer ask/deny aux appels à restreindre. Cela ne contrôle pas automatiquement les variantes de la même opération ni tout ce qui se passe dans un script autorisé.

La correspondance des arguments Bash ne suffit pas à imposer des restrictions d'URL. Même en interdisant curl/wget et utilisant WebFetch, restent les chemins absolus, sh -c et la communication via d'autres programmes. Les règles de domaine WebFetch contrôlent cet outil, pas tout le trafic Bash. Combinez notamment la liste de destinations réseau du sandbox et gérez séparément les outils et nouvelles tentatives hors du sandbox.

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.
• Read/Edit deny ne bloque pas les accès indirects. Il concerne les outils de fichiers intégrés et cat/head/sed, pas les scripts Python ou Node ouvrant eux-mêmes les fichiers. Les recherches récursives comme grep -r pattern . sans nom de fichier cible sont une autre exception. Les restrictions OS concernent les processus dans le sandbox ; Read intégré, MCP et les autres voies nécessitent des contrôles distincts.
• 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 remplacent pas les règles. Un hook PreToolUse peut étendre les permissions, mais deny/ask sont évalués quel que soit son résultat. En revanche, tool.check d'un mod peut remplacer la décision ensuite. Il peut approuver ask et, en environnement personnel sans réglages administrés, deny. Sur les machines administrées et Team/Enterprise, deny a priorité par défaut, mais l'organisation peut changer cela. Vous devez décider si vous faites confiance aux mods installés.
• En mode automatique, même une commande de votre liste allow peut passer par le classificateur. À l'entrée en mode automatique, les règles allow larges qui permettent d'exécuter du code arbitraire (Bash(*) sans restriction, interpréteurs avec joker comme Bash(python*), commandes run des gestionnaires de paquets, règles Agent, etc.) sont retirées, puis rétablies à la sortie du mode ; les règles étroites comme Bash(npm test) restent en vigueur. Les règles ne correspondent que telles qu'elles sont écrites : Bash(git push *) ne correspond pas à git -C . push, et une commande qu'aucune règle ne couvre est jugée par le classificateur. Les écritures dans des chemins protégés passent aussi par le classificateur, même si une règle allow correspond. Si une action légitime est bloquée, vous pouvez la retenter depuis Recently blocked (Recently denied avant la v2.1.314) dans /permissions (voir les modes de permission). Des issues GitHub signalent aussi des commandes autorisées qui ont été bloquées (par ex. #95996). Ce point suit la documentation officielle (Choose a permission mode) au 9 octobre 2026.

* Ce comportement suit la documentation officielle de Claude Code (Configure permissions / Settings files and precedence / Choose a permission mode), au 9 octobre 2026. Il peut changer ; consultez les documents officiels pour les informations actuelles.

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 (première correspondance ; spécificité sans effet). Dans les règles de réglages, allow ne remplace pas un deny correspondant. 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.

Comprenez les correspondances de chaque règle et réduisez seulement les approbations nécessaires. Combinez règles, modes de permission et hooks. Envisagez un sandbox pour imposer des restrictions de fichiers ou réseau. Distinguez la couche couvrant chaque voie.

Pour examiner l'état actuel du code sans le modifier et obtenir seulement des conseils, consultez notre guide pour limiter Codex et Claude Code à l'analyse. Il présente les étapes dans l'application, l'IDE et la CLI, ainsi qu'une consigne qui termine la tâche après le rapport sans demander de mise en œuvre.

FAQ

Le périmètre et les exceptions des permissions et de l'isolation ont été revérifiés dans les sources officielles le 9 octobre 2026. Aucun réglage de l'appareil n'a été modifié et aucun essai de démarrage effectué.