Permissions Claude Code : règles allow, deny et ask, expliquées
Un décryptage image par image de la façon dont Claude Code demande la permission : les trois options de prompt, les règles allow enregistrées dans settings.local.json, l'ordre d'évaluation deny d'abord, les modes de permission, et les recettes qui font moins prompter le codage au quotidien et en CI — avec la doc officielle pour combler chaque blanc laissé par la vidéo.
Les permissions Claude Code en 60 secondes
- Claude Code demande avant Bash, Edit, WebFetch et Write ; Read, Glob, Grep et LS s'exécutent sans rien demander.
- « Yes, and don't ask again » enregistre une règle comme Bash(git add:*) dans .claude/settings.local.json — votre registre de règles personnel, exclu de git, propre à ce dépôt.
- Les règles s'évaluent deny → ask → allow : un deny venu de n'importe quel fichier de settings gagne, et aucune règle allow ne peut y creuser d'exception.
- Les modes dosent la confiance : acceptEdits (alt+m) pour le travail riche en éditions, plan pour la reconnaissance en lecture seule, bypassPermissions pour la CI via --permission-mode — et les valeurs defaultMode auto et bypassPermissions ne prennent effet que depuis les settings user ou managed.
Claude Code Tutorial #4 - Tools & Permissions
Vidéo:The Net Ninja4:55
Permission Modes Head to Head
Vidéo:ttywood6:20
Permissions — Claude Code documentation
Docs:code.claude.com
Settings files — Claude Code documentation
Docs:code.claude.com
Chaque capture vient de l'enregistrement du Net Ninja, une capture d'écran propre sans caméra ni overlays. L'épisode ttywood comparant les modes de permission tête à tête a servi de contre-vérification pour les sections modes et recettes mais n'a fourni aucune image — les siennes portent des sous-titres incrustés. La syntaxe des règles, l'ordre d'évaluation, le comportement des modes et la précédence des fichiers de settings sont vérifiés contre les deux pages de documentation officielles.
Vidéos © The Net Ninja et ttywood, liées seulement. Documentation © Anthropic. Les captures d'écran sont référencées dans ce guide à des fins de commentaire.
Configurer les permissions Claude Code, étape par étape
Ce que Claude Code demande avant d'agir
- 1
Voyez quels outils déclenchent un prompt de permission
Claude Code choisit ses propres outils — Read pour ouvrir des fichiers, Edit pour les modifier, Bash pour les commandes shell. La doc des settings d'Anthropic donne à chacun une colonne Permission Required : Bash, Edit, WebFetch et Write s'arrêtent et demandent, tandis que Read, Glob, Grep et LS s'exécutent. Vous ne tapez jamais les noms d'outils vous-même ; l'important est de savoir à l'avance quelles actions marqueront une pause pour vous.
La doc des settings de Claude Code liste chaque outil intégré avec son verdict Permission Required.Voir à 1:05 - 2
Demandez une édition et regardez-le lire d'abord
Dans la vidéo, la demande est volontairement petite : ajouter une variable --highlight jaune pastel à src/app/globals.css. Claude Code lit d'abord le fichier — Read ne demande jamais la permission — et ne s'arrête qu'au moment de le modifier. Cette séparation résume tout le modèle de permissions : regarder est gratuit, toucher demande.
La demande de variable highlight saisie dans l'entrée Claude Code de VS Code.Voir à 1:45 - 3
Lisez les trois options avant de répondre
Chaque prompt d'édition offre trois réponses. 1. Yes approuve cette seule édition. 2. Yes, and don't ask again this session approuve les éditions restantes de la session (alt+m dans la build montrée). 3. No, and tell Claude what to do differently (esc) refuse le changement et vous laisse reprendre la direction. L'option 3 n'est pas un échec — c'est comme ça qu'on corrige la trajectoire avant que le code n'atterrisse.
Le prompt d'édition de globals.css avec les trois options de permission visibles.Voir à 2:17
Dire oui une fois : enregistrer une règle allow
- 4
Attendez-vous à un prompt par édition, pas par tâche
L'approbation ne se reporte pas sur le changement suivant. La démo a demandé trois Yes pour trois éditions distinctes du même fichier, et le changement d'après a de nouveau sollicité. Le oui-à-chaque-fois fonctionne, mais ça passe mal à l'échelle au-delà d'une tâche de deux lignes — c'est précisément pour ça qu'existent les règles allow et les modes.
Une deuxième édition de globals.css qui redemande juste après l'approbation de la première.Voir à 2:32 - 5
Les commandes Bash sollicitent séparément
Les commandes shell ont leur propre barrière. Quand la démo demande à Claude de faire un commit, Bash(git add src/app/globals.css) reste en attente jusqu'à votre réponse. Un oui pour une commande n'est pas un oui pour la suivante — le git commit qui suit demande pour son propre compte.
La commande git add en attente d'approbation pendant que la sortie git précédente défile au-dessus.Voir à 3:16 - 6
Laissez « don't ask again » écrire la règle pour vous
Choisir Yes, and don't ask again pour les commandes git add fait deux choses d'un coup : il débloque la commande en cours et enregistre une règle. Le fichier créé est .claude/settings.local.json à la racine du dépôt, qui contient un objet permissions avec un tableau allow — ici "Bash(git add:*)" — plus des tableaux deny et ask vides. Tous les futurs git add de ce projet tournent désormais sans prompt.
settings.local.json créé sous .claude avec la règle allow Bash(git add:*) enregistrée.Voir à 3:40 - 7
Éditez les règles à la main quand la boîte de dialogue ne peut pas
Le tableau allow est du JSON brut, vous pouvez donc y ajouter des règles vous-même. Utilisez une chaîne exacte pour une seule commande — Bash(npm run test) — et un suffixe :* pour tout ce qui commence pareil — Bash(npm run test:*). La doc confirme que :* est le raccourci du joker de fin. Gardez le fichier personnel : Claude Code exclut settings.local.json de git automatiquement, et la vidéo le dit pareil — c'est pour votre flux de travail, pas pour le dépôt.
La règle enregistrée sélectionnée dans permissions.allow pendant l'édition manuelle du fichier.Voir à 4:22
Dosser la délégation avec les modes
- 8
Passez en accept edits pour les séries d'éditions
alt+m (shift+tab fait défiler les modes dans les builds actuelles) bascule le badge de session sur accept edits on. Les éditions de fichiers atterrissent désormais sans prompt, et la doc ajoute que les commandes de système de fichiers courantes — mkdir, touch, mv, cp — sont aussi auto-acceptées. La grâce est limitée à la session : nouvelle session, retour aux prompts par édition, jusqu'à nouvel opt-in.
Le badge accept edits on pendant que les commandes git autorisées finissent le commit.Voir à 4:35 - 9
Connaissez toute l'échelle des modes avant de grimper
Les modes fixent la posture par défaut d'une session. default demande à la première utilisation de chaque outil ; plan est une exploration en lecture seule qui n'édite rien ; acceptEdits auto-accepte les éditions de fichiers ; dontAsk refuse automatiquement tout ce qui aurait demandé ; auto approuve les appels d'outils avec des contrôles de sécurité en arrière-plan ; bypassPermissions saute les prompts sauf pour le petit ensemble d'actions qu'aucun mode ne peut auto-approuver. Choisissez-en un par session avec --permission-mode, ou rendez-le persistant avec permissions.defaultMode.
- 10
Mettez defaultMode dans le bon fichier
La doc des settings est explicite : les valeurs defaultMode auto et bypassPermissions ne prennent pas effet depuis les settings projet ou locaux — posez-les dans les settings user (~/.claude/settings.json) ou managed, ou passez --permission-mode pour une seule session. La précédence va des settings managed → CLI --settings → .claude/settings.local.json → .claude/settings.json → user, et un deny à n'importe quel niveau bat chaque allow en dessous.
Recettes à copier-coller pour de vrais projets
- 11
Recette : allow pour les tests, deny pour la destruction
Dans le .claude/settings.json partagé par l'équipe, autorisez la boucle de test avec "Bash(npm run test:*)" et neutralisez les parties dangereuses avec "Bash(rm -rf *)" et "Read(./.env)" pour que les secrets restent illisibles. La recherche web confirme la même logique : "WebFetch(domain:example.com)" pour un domaine, "WebFetch(domain:*.example.com)" pour tout un sous-domaine. Comme deny est évalué en premier, aucune règle allow ne peut y creuser d'exception.
- 12
Recette : sauter les prompts en CI sans risque
Les exécutions non interactives exigent une posture délibérée, pas accidentelle : passez --permission-mode bypassPermissions sur le job de CI, ou posez defaultMode dans les settings user ou managed — un fichier projet ne peut pas l'accorder. Pour rendre le garde-fou permanent, mettez permissions.disableBypassPermissionsMode à "disable" dans les settings managed, et auditez toute machine avec /permissions, qui liste chaque règle active et le fichier d'où elle vient.
deny → ask → allow : comment les règles sont réellement évaluées
La doc des permissions le dit crûment : les règles s'évaluent dans l'ordre — deny, puis ask, puis allow — la première correspondance décide, et la spécificité d'une règle ne change jamais cet ordre. Une règle allow ne peut pas creuser d'exception dans une règle deny, aussi précise soit-elle.
Le deny est aussi global entre fichiers. Si les settings user autorisent une commande et que les settings projet l'interdisent, le deny gagne, parce que les règles deny de n'importe quelle portée s'évaluent avant les allow — et un deny des settings managed ne peut être outrepassé même par des drapeaux en ligne de commande. Interdire un nom d'outil nu comme "Bash" va encore plus loin : la doc précise que ça retire l'outil du contexte de Claude entièrement.
Conséquence pratique : livrez vos règles de sécurité — deny rm, deny lecture de .env, deny force-push — dans le .claude/settings.json du projet qui voyage avec le dépôt, et traitez les listes allow comme des commodités qui s'empilent au-dessus. Les listes allow fusionnent entre portées au lieu de s'écraser, donc votre settings.local.json personnel peut ajouter des tolérances sans affaiblir les interdictions de personne.
Trois recettes à s'approprier
Chaque recette nomme le fichier où elle va. Une constante vaut pour toutes : le deny gagne partout, toujours.
Tests libres, rm et .env sous verrou
Dans .claude/settings.json : "permissions.allow": ["Bash(npm run test:*)"] (remplacez par "Bash(npx vitest:*)" ou "Bash(uv run pytest:*)" selon votre stack), "permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]. Les tests et leurs callbacks tournent sans les mains ; les suppressions destructrices et les lectures de secrets sont bloquées avant même que l'évaluation n'atteigne votre liste allow.
Calez la recherche sur les domaines de confiance
Pour le travail chargé en documentation : "WebFetch(domain:developer.mozilla.org)" et "WebFetch(domain:claude.com)" en allow, ou "WebFetch(domain:*.example.com)" pour couvrir tout un sous-domaine. Interdire l'outil nu "WebFetch" coupe entièrement la lecture web — utile pour des exécutions reproductibles qui doivent se tenir au contexte local.
Une CI headless sans partir dans la nature
Faites passer --permission-mode bypassPermissions au job de CI, ou posez "permissions.defaultMode": "bypassPermissions" dans les settings user ou managed — les settings projet et locaux ne peuvent pas l'accorder. Pour interdire carrément le mode, "permissions.disableBypassPermissionsMode": "disable" dans les settings managed verrouille chaque dépôt et chaque drapeau. Même alors, bypassPermissions bloque toujours la courte liste d'actions qu'aucun mode ne peut auto-approuver.
Une règle ne marche pas ? Vérifiez ces quatre points
La plupart des signalements « mon allow est ignoré » tiennent au fichier où la règle a atterri et au fichier qui gagne.
- 1La bonne règle, le mauvais fichier. Les approbations de session atterrissent dans .claude/settings.local.json ; les règles d'équipe vont dans .claude/settings.json ; les règles machine dans ~/.claude/settings.json. Lancez /permissions — il liste chaque règle active et le fichier de settings d'où elle vient.
- 2Un fichier plus haut l'interdit. Les valeurs s'écrasent vers le bas, mais un deny de n'importe quel niveau s'évalue avant les allow, donc un allow au niveau user ne sauve jamais un deny au niveau projet — et les settings managed battent tout, drapeaux en ligne de commande compris.
- 3La règle allow attend la confiance. Les règles deny et ask s'appliquent immédiatement, mais un allow venant d'un fichier projet commité ne prend effet qu'après l'approbation du workspace — une barrière délibérée pour les dépôts clonés.
- 4Un mode mal placé. Les valeurs defaultMode auto et bypassPermissions sont ignorées depuis les settings projet et locaux (la doc note que c'est changé en v2.1.257 — avant, bypassPermissions prenait effet depuis n'importe quel fichier). Déplacez-les vers les settings user ou managed, ou servez-vous de --permission-mode pour une session unique.