03 - Permissions et modes

Comment arreter de cliquer "oui" toutes les trente secondes, sans donner les cles du camion.

Temps de lecture : 14 min | Niveau : Intermediaire

Ce que tu sauras faire apres

Choisir le mode de permission adapte a ce que tu es en train de faire.
Utiliser le plan mode pour reflechir avant de toucher au code.
Ecrire des regles allow, ask et deny qui marchent vraiment.
Proteger tes fichiers sensibles (.env, secrets, production).
Supprimer les demandes d'autorisation repetitives sans tout autoriser.

1. Le principe de base

Claude Code utilise un systeme de permissions a plusieurs niveaux. Voici ce qui demande une approbation en mode Manuel :

Type d'outil	Exemple	Approbation demandee ?	Effet de "Oui, et ne redemande plus"
Lecture seule	Lecture de fichier, Grep	Non, dans les dossiers de travail	Sans objet
Commande Bash	Execution shell	Oui, sauf un jeu de commandes lecture seule	Permanent, par depot et par commande
Modification de fichier	Edit / Write	Oui	Jusqu'a la fin de la session
Fetch web	WebFetch	Oui, sauf domaines de doc pre-approuves	Permanent, par depot et par domaine
Recherche web	WebSearch	Oui	Permanent, par depot

Quand tu choisis "Oui, et ne redemande plus" et que l'approbation est permanente, Claude Code enregistre la regle dans .claude/settings.local.json a la racine du depot Git.

A savoir. Les regles de permission sont appliquees par Claude Code, pas par le modele. Une instruction dans ton prompt ou dans CLAUDE.md oriente ce que Claude essaie de faire, mais ne change pas ce que Claude Code autorise.

2. Les modes de permission

Un mode definit la ligne de base : ce que Claude peut faire sans te demander.

Mode	Ce qui passe sans demander	Bon pour
`default` (affiche Manual)	Lectures uniquement	Tout relire toi-meme, travail sensible
`acceptEdits`	Lectures, editions de fichiers, commandes systeme courantes	Iterer sur du code que tu relis apres
`plan`	Lectures, plus les commandes approuvees par le classifieur si le mode auto est disponible	Explorer un depot avant de le changer
`auto`	Tout, avec des controles de securite en arriere-plan	Longues taches, reduire la fatigue des prompts
`dontAsk`	Lectures et outils pre-approuves ; tout ce qui demanderait est refuse	CI et scripts verrouilles
`bypassPermissions`	Tout	Conteneurs et VM isolees uniquement

Le mode default s'appelle Manual dans l'interface. Sa valeur de configuration reste default, et l'alias manual est accepte la ou tu tapes la valeur.

Attention au mode acceptEdits. Les "commandes systeme courantes" qu'il laisse passer sans demander sont mkdir, touch, rm, rmdir, mv, cp et sed. Oui, rm en fait partie. L'auto-approbation ne vaut que pour les chemins dans ton dossier de travail, mais c'est une raison de plus de mettre tes fichiers sensibles en deny (section 4).

Changer de mode

Pendant une session : appuie sur Shift+Tab pour faire defiler les modes. Depuis auto, la premiere pression passe a default, puis le cycle est default → acceptEdits → plan → retour a default.

La barre d'etat t'indique ou tu es :

⏸ manual mode on
⏵⏵ accept edits on
⏸ plan mode on
⏵⏵ auto mode on

Au demarrage : passe le mode en option.

claude --permission-mode plan

Par defaut, partout : mets permissions.defaultMode dans ~/.claude/settings.json.

{
  "permissions": {
    "defaultMode": "default"
  }
}

Attention, piege documente. Les valeurs auto et bypassPermissions ne prennent pas effet depuis .claude/settings.json ni .claude/settings.local.json. Si tu veux auto par defaut, mets-le dans ~/.claude/settings.json.

Quel mode au demarrage ?

Depuis la version 2.1.283 de Claude Code, le mode auto est le mode de depart integre pour les sessions interactives en terminal et dans l'extension VS Code, sur tous les plans. Sur les versions anterieures, c'etait le cas seulement sur les plans Pro, Max et Team.

Cette information evolue vite d'une version a l'autre. Verifie ce que fait ta version en regardant la barre d'etat au demarrage.

3. Le plan mode, ton meilleur ami

C'est le mode le plus utile au quotidien, et le plus sous-utilise.

En plan mode, Claude lit les fichiers, lance des commandes d'exploration, et ecrit un plan. Il ne modifie pas tes sources. Les editions restent bloquees jusqu'a ce que tu approuves le plan.

Le workflow en quatre temps

Explorer. Shift+Tab jusqu'a ⏸ plan mode on, puis :

lis dbt/models/marts/ et explique-moi comment fct_commandes est construit,
d'ou viennent ses sources, et quels tests existent dessus

Planifier.

Je veux ajouter une colonne marge_brute a fct_commandes, calculee a partir du prix
d'achat de dim_produits. Quels fichiers doivent changer ? Fais-moi un plan.

Appuie sur Ctrl+G pour ouvrir le plan dans ton editeur de texte et le modifier directement avant que Claude ne continue.

Implementer. Approuve le plan. Claude sort du plan mode et code.
Committer.

commit avec un message descriptif et ouvre une PR

Approuver un plan

Quand le plan est pret, trois options :

Yes, and use auto mode : approuve et demarre en mode auto.
Yes, manually approve edits : approuve et tu relis chaque edition.
No, keep planning : reste en plan mode et dis a Claude ce qu'il faut changer.

Quand le plan mode ne sert a rien

Le plan mode ajoute de la friction. Pour une faute de frappe, une ligne de log, un renommage de variable, demande directement. Si tu peux decrire le diff en une phrase, saute le plan.

Le plan mode est utile quand tu n'es pas sur de l'approche, quand le changement touche plusieurs fichiers, ou quand tu ne connais pas le code.

Pour mettre le plan mode par defaut sur un projet, dans .claude/settings.json :

{
  "permissions": {
    "defaultMode": "plan"
  }
}

4. Les regles de permission

Trois listes, evaluees dans cet ordre : deny, puis ask, puis allow. La premiere qui correspond decide. La precision de la regle ne change pas cet ordre.

Liste	Effet
`allow`	Claude utilise l'outil sans approbation manuelle
`ask`	Claude Code demande confirmation a chaque fois
`deny`	Claude Code empeche l'utilisation

Un mot de vocabulaire. Dire qu'une regle matche un appel, c'est dire qu'elle correspond a cet appel. Le mot revient partout dans la documentation officielle, donc autant s'y habituer tout de suite.

Consequence importante : une regle deny large comme Bash(aws *) bloque tous les appels qui lui correspondent. Meme ceux qui correspondent aussi a une regle allow plus precise comme Bash(aws s3 ls). Une regle allow ne peut pas creer une exception dans un deny.

Pour voir et gerer tes regles :

/permissions

Syntaxe

La forme est Outil ou Outil(specificateur).

Regle	Effet
`Bash`	Toutes les commandes Bash
`Bash(npm run build)`	Exactement cette commande
`Bash(npm run *)`	Toutes les commandes qui commencent par `npm run`
`Read(./.env)`	La lecture du fichier `.env` du dossier courant
`WebFetch(domain:docs.getdbt.com)`	Les fetch vers ce domaine

La regle des jokers `*`

C'est le point ou tout le monde se trompe. Mets le * apres la sous-commande.

Claude Code compare tout ce qui precede le premier * a la lettre. Ces mots-la sont donc ce qui limite la regle.

Tu ecris	Ca matche	Ca ne matche pas
`Bash(npm run build)`	`npm run build`	`npm run build --watch`
`Bash(npm run *)`	`npm run build`, `npm run test --watch`, `npm run`	`npm install`
`Bash(git log * main)`	`git log --oneline main`, `git log -5 main`	`git log main`
`Bash(git * main)`	`git merge main`, `git push origin main`	`git log`
`Bash(ls *)`	`ls -la`, `ls`	`lsof`
`Bash(ls*)`	`ls -la`, `lsof`

Trois regles expliquent ce tableau :

Le * remplace n'importe quel texte a sa place, espaces compris.
Un * final precede d'un espace matche aussi la commande nue : Bash(ls *) matche ls.
L'espace avant un * final fait partie de la regle : Bash(ls *) ne matche pas lsof, mais Bash(ls*) oui.

Le suffixe :* est equivalent : Bash(ls:*) = Bash(ls *).

Commandes composees

Claude Code connait les operateurs shell. Une regle comme Bash(safe-cmd *) ne donne pas la permission de lancer safe-cmd && other-cmd. Les separateurs reconnus sont &&, ||, ;, |, |&, & et les retours a la ligne. Chaque sous-commande doit matcher independamment.

Les regles deny et ask s'appliquent des qu'une sous-commande matche, y compris a l'interieur d'un sous-shell ou d'une substitution de commande.

Ce qu'une regle Bash ne bloque pas

Une regle Bash compare le texte de la commande. Elle ne couvre pas le meme programme appele autrement. Ce n'est donc pas une frontiere de securite.

Regle en `deny`	Bloque	Ne bloque pas
`Bash(curl *)`	`curl https://exemple.com`	`/usr/bin/curl ...`, `sh -c 'curl ...'`
`Bash(rm *)`	`rm -rf build/`	`/bin/rm -rf build/`, `bash -c 'rm -rf build/'`
`Bash(git push *)`	`git push origin main`	`git -C . push origin main`

Pour une vraie barriere, il faut le sandbox (isolation systeme) ou un hook PreToolUse.

Regles de fichiers : Read et Edit

Les regles Read et Edit utilisent la syntaxe des motifs .gitignore, avec quatre formes d'ancrage :

Motif	Sens	Exemple
`//chemin`	Chemin absolu depuis la racine du disque	`Read(//Users/wael/secrets/**)`
`~/chemin`	Depuis le dossier personnel	`Read(~/Documents/*.pdf)`
`/chemin`	Relatif a la source du reglage	`Edit(/src/*/.py)`
`chemin` ou `./chemin`	Relatif au dossier courant	`Read(*.env)`

Piege. /Users/wael/fichier n'est pas un chemin absolu ici : le slash initial ancre a la source du reglage. Pour un vrai chemin absolu, il faut //Users/wael/fichier.

Une regle Edit(chemin) couvre tous les outils integres qui modifient des fichiers. Une regle Read en deny bloque aussi Edit et Write sur le meme chemin. Elle ne couvre pas NotebookEdit : pour un chemin qu'aucun outil ne doit modifier, ajoute aussi une regle Edit en deny.

Ne mets pas de chemin sur Write, Glob ou NotebookEdit : Claude Code accepte la regle mais ne la consulte jamais, et t'avertit au demarrage. Utilise Edit(docs/**) a la place de Write(docs/**), et Read(docs/**) a la place de Glob(docs/**).

Limite importante. Les regles Read et Edit couvrent les outils fichiers, les commandes Bash qui nomment le fichier (cat, head, tail, sed, tee) et les cibles de redirection. Elles ne couvrent pas une commande qui lit sans nommer le fichier, comme grep -r motif ., ni un script Python qui ouvre le fichier lui-meme.

5. Eviter les demandes repetitives sans tout autoriser

C'est la question pratique numero un. Cinq leviers, du plus doux au plus large.

Levier 1 : approuver avec memoire

Quand la boite de dialogue apparait, choisis "Oui, et ne redemande plus" pour les commandes que tu fais tous les jours. La regle part dans .claude/settings.local.json du depot.

Levier 2 : une liste `allow` ecrite a la main

Dans .claude/settings.json du projet (partage avec l'equipe) :

{
  "permissions": {
    "allow": [
      "Bash(make test-unit)",
      "Bash(make lint)",
      "Bash(uv run pytest *)",
      "Bash(dbt compile *)",
      "Bash(dbt build --select * --target dev)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(dbt run --target prod *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./dbt/profiles.yml)",
      "Read(./secrets/**)",
      "Bash(bq rm *)",
      "Bash(gcloud * delete *)"
    ]
  }
}

Lis ce bloc a voix haute : "lance mes tests et mon lint sans demander, demande-moi avant de pousser ou de toucher a la prod, et ne lis jamais mes secrets".

Levier 3 : la commande `/fewer-permission-prompts`

Claude Code inclut une commande qui analyse tes transcripts, repere les appels lecture seule que tu approuves sans arret, et te propose une liste allow prioritaire dans .claude/settings.json.

/fewer-permission-prompts

Levier 4 : le mode `acceptEdits`

Si tu relis de toute facon avec git diff, passe en acceptEdits. Les editions de fichiers et les commandes systeme courantes passent sans demander, mais toutes les autres commandes Bash continuent de demander.

Levier 5 : le mode `auto`

Un second modele, le classifieur, relit les actions a ta place. Il bloque ce qui sort du cadre de ta demande, ce qui vise une infrastructure inconnue, ou ce qui semble pilote par du contenu hostile que Claude a lu.

Bloque par defaut :

telecharger et executer du code, du type curl | bash
envoyer des donnees sensibles vers des points externes
les deploiements et migrations en production

Avertissement officiel. Le mode auto reduit les demandes mais ne garantit pas la securite. Utilise-le pour des taches dont tu approuves la direction generale, pas comme un remplacement de la relecture sur des operations sensibles.

Les regles ask explicites forcent toujours une demande, meme en mode auto.

6. Dossiers de travail

Par defaut, Claude accede aux fichiers du dossier ou tu as lance la commande. Pour etendre :

Quand	Comment
Au demarrage	`claude --add-dir ../lib-partagee`
Pendant la session	`/add-dir ../lib-partagee`
De maniere permanente	Cle `additionalDirectories` dans un fichier de reglages

Sur Windows, tu ne peux pas ajouter un chemin reseau UNC du type \\serveur\partage comme dossier de travail. Mappe le partage sur une lettre de lecteur et passe cette lettre avec --add-dir.

7. AVANT / APRES

AVANT

Tu lances claude --dangerously-skip-permissions parce que tu en as assez des questions. Claude peut tout faire, y compris dbt run --target prod ou lire ton .env.

APRES

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(make *)", "Bash(git diff *)", "Bash(git status *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./dbt/profiles.yml)", "Bash(bq rm *)"]
  }
}

Pourquoi c'est mieux ? Tu n'as plus de questions sur ton travail quotidien, mais la prod et tes secrets restent proteges, et un git push te demande toujours confirmation.

Template pret a copier

{
  "permissions": {
    "allow": [
      "Bash([TA_COMMANDE_DE_TEST])",
      "Bash([TA_COMMANDE_DE_LINT])",
      "Bash(git status *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash([TA_COMMANDE_VERS_LA_PROD] *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./[TON_FICHIER_DE_SECRETS])",
      "Bash([TA_COMMANDE_DESTRUCTRICE] *)"
    ]
  }
}

A retenir

Six modes : default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions. Shift+Tab pour changer.
Le plan mode fait reflechir Claude avant qu'il touche au code. Ctrl+G edite le plan.
Ordre d'evaluation : deny, puis ask, puis allow. Un allow ne perce jamais un deny.
Mets le * apres la sous-commande : Bash(git log *), pas Bash(git * main).
Une regle Bash n'est pas une frontiere de securite : /bin/rm echappe a Bash(rm *).
Pour moins de questions : liste allow explicite + /fewer-permission-prompts, plutot que --dangerously-skip-permissions.
auto et bypassPermissions ne s'appliquent pas depuis les reglages projet ou locaux.

Sources

Claude Code - Configure permissions
Claude Code - Choose a permission mode
Claude Code - Settings files and precedence
Claude Code - Example settings files
Claude Code - Best practices
Claude Code - Commands
anthropics/claude-code - trois politiques de permissions officielles dans examples/settings/ : settings-lax.json, settings-strict.json, settings-bash-sandbox.json

Liens verifies le 26 septembre 2026.

03 - Permissions et modes#

Ce que tu sauras faire apres#

1. Le principe de base#

2. Les modes de permission#

Changer de mode#

Quel mode au demarrage ?#

3. Le plan mode, ton meilleur ami#

Le workflow en quatre temps#

Approuver un plan#

Quand le plan mode ne sert a rien#

4. Les regles de permission#

Syntaxe#

La regle des jokers *#

Commandes composees#

Ce qu'une regle Bash ne bloque pas#

Regles de fichiers : Read et Edit#

5. Eviter les demandes repetitives sans tout autoriser#

Levier 1 : approuver avec memoire#

Levier 2 : une liste allow ecrite a la main#

Levier 3 : la commande /fewer-permission-prompts#

Levier 4 : le mode acceptEdits#

Levier 5 : le mode auto#

6. Dossiers de travail#

7. AVANT / APRES#

Template pret a copier#

A retenir#

Sources#