Les permissions : jusqu'où on le laisse faire

Vingtième demande de la matinée. Tu ne lis plus : la fenêtre s’ouvre, ta main répond oui avant tes yeux. Ce n’est plus une validation, c’est un tic. Ou la scène inverse, souvent la même journée quelques heures plus tard : tu as fini par tout autoriser pour qu’on te laisse travailler, tu es allé chercher un café, et tu es revenu devant une liste d’actions dont deux te font froid dans le dos.

Ces deux moments ne sont pas deux erreurs opposées. C’est le même bouton poussé à ses deux bouts — et le vrai problème, c’est qu’on croit qu’il n’y en a qu’un.

Ce qui se passe vraiment

Reprends l’image de la leçon 1 : l’atelier et l’artisan. Les règles de sécurité de l’atelier ne sont pas des consignes que l’artisan s’applique à lui-même, ce sont des dispositifs de l’atelier. C’est vrai des règles d’autorisation : elles sont appliquées par le programme, pas par le modèle. Ce que tu écris dans ta demande ou dans ton CLAUDE.md (le fichier de règles du projet, leçon 6) oriente ce que Claude essaie de faire, et ne change rien à ce qu’une règle laisse passer. Le carter est vissé, il ne discute pas.

Mais depuis août 2026, le mode par défaut de la plupart des lecteurs ajoute un troisième personnage : le classificateur, un second modèle qui examine les actions avant qu’elles ne s’exécutent et approuve à ta place. Il ne voit pas tout : les lectures et les éditions faites dans ton répertoire de travail sont approuvées sans lui, sauf vers un chemin protégé. Lui n’est ni le carter ni l’artisan. Il lit tes messages et ton CLAUDE.md, et en tient compte dans les deux sens : une frontière que tu énonces bloque ce que les règles par défaut autoriseraient, et nommer précisément une cible lève un blocage par défaut. Le texte que tu écris déplace donc une frontière — celle-là seulement, et tant qu’il reste dans la conversation.

Ce que le mode règle, et ce qu’il ne règle pas

Six modes existent. Trois règlent surtout combien de fois on t’arrête : default, acceptEdits, auto. Les trois autres changent ce qui est possible : plan bloque les modifications tant que le plan n’est pas approuvé, dontAsk refuse au lieu de demander, et bypassPermissions autorise ce qu’aucune règle ne peut autoriser — les écritures vers les chemins protégés. Les règles d’autorisation et le bac à sable traversent les modes : un refus et une demande explicites s’appliquent dans les six.

À retenir — choisir un mode, ce n’est pas décider de ce qui peut arriver : c’est décider de ce qui t’est soumis. Ce que tu ne veux voir arriver dans aucun cas ne se règle donc pas en choisissant un mode : ça s’écrit en règle, et ça tient même quand tu as tout autorisé.

Un mot de vocabulaire, parce qu’il en cache deux : les règles d’autorisation (permission rules) n’ont rien à voir avec les rules de la leçon 6, ces fichiers d’instructions rangés dans .claude/rules/ que Claude lit. Ici, « règle » veut toujours dire barrière.

Où tu démarres, et pourquoi ce n’est pas ce que tu crois

Voilà le fait le plus périssable de cette leçon, à revérifier sur ton écran plutôt qu’à croire sur parole — claude --version donne ton numéro, comme en leçon 2. Sur les offres Pro, Max et Team, dans un terminal ou via l’extension VS Code, une session démarre maintenant en mode auto. Il faut la version 2.1.228 sur macOS, Linux et WSL, la 2.1.233 sur Windows natif ; en dessous, le défaut intégré reste Manual.

Quatre situations font retomber sur Manual, et deux te concernent : l’exécution non interactive (claude -p), et la toute première session après une installation, ou après la mise à jour qui apporte ce défaut — le temps que le programme récupère ses indicateurs de fonctionnalité. Qui teste juste après avoir mis à jour voit donc Manual, et la session suivante lui donnera tort. Les deux autres cas sont les offres Enterprise et les clés d’API, et les fournisseurs d’infrastructure. Et si une étape choisit auto alors qu’il n’est pas disponible, la session démarre en Manual.

Deux avis à ne pas rater. La première fois que ce défaut démarre une de tes sessions en mode auto, un avis s’affiche. Et si tu as déjà posé un autre defaultMode dans tes réglages utilisateur, tes sessions continuent de démarrer dedans, mais Claude Code te demande une fois si tu veux passer au mode auto ; si tu refuses, ton réglage reste tel quel.

Le mode ne dit pas d’où tu travailles

Sur le projet audité en juillet 2026, un système en production dont ce parcours tire ses exemples, vingt-sept modifications avaient été faites directement depuis le serveur qui sert les utilisateurs, sur une seule branche. Ce n’est pas que les modes n’y auraient rien changé : c’est pire, ils s’y retournent. Tout le système d’autorisations est ancré sur une hypothèse — le répertoire de travail est la zone sûre : c’est là que les lectures passent, que acceptEdits approuve les suppressions, que le bac à sable autorise les écritures. Travailler depuis la production ne contourne donc pas les modes, ça fait tomber les défauts les plus permissifs sur les fichiers les plus dangereux. La leçon 14 traite cette moitié-là du problème.

Ce qu’on fait

Voir où tu es, et en changer

La barre d’état affiche le mode en cours, en toutes lettres ; dans VS Code, c’est l’indicateur de mode en bas de la zone de saisie.

Valeur de configuration	Ce que la barre affiche	Ce qui passe sans qu’on te demande	Quand le choisir
default	⏸ manual mode on, en gris	les lectures seules	tu ne connais pas encore le dépôt, ou ce que tu touches est sensible
acceptEdits	⏵⏵ accept edits on	les lectures, les éditions, et les commandes de fichiers courantes (mkdir, touch, mv, cp…)	tu itères sur du code que tu vas exercer toi-même juste après
plan	⏸ plan mode on	les lectures, plus les commandes approuvées par le classificateur quand le mode auto est disponible	tu veux voir la trajectoire avant qu’une ligne bouge
auto	⏵⏵ auto mode on	tout, avec le classificateur en arrière-plan	une tâche longue dont tu approuves la direction générale
dontAsk	⏵⏵ don't ask on	uniquement les outils pré-approuvés	intégration continue, jamais le travail courant
bypassPermissions	⏵⏵ bypass permissions on	tout	un conteneur isolé ou une machine virtuelle, et nulle part ailleurs

Trois lignes méritent d’être lues deux fois :

• default : ce qui passe librement ne le fait que dans ton répertoire de travail et tes répertoires additionnels (ceux ajoutés par --add-dir ou /add-dir), plus un jeu intégré de commandes en lecture seule — ls, cat, grep, find, les formes de git qui ne modifient rien ;
• acceptEdits : les « commandes de fichiers courantes » comprennent aussi rm, rmdir et sed, et seulement dans cette même portée. Hors d’elle, vers un chemin protégé (.git, .claude, ton .zshrc, .mcp.json…, jamais approuvés automatiquement sauf en bypassPermissions), et pour toute autre commande, on te demande ;
• dontAsk n’est pas un mode silencieux : il refuse ce qui aurait demandé, et ne laisse passer que ce que tes règles ont pré-approuvé et ce qu’un hook PreToolUse approuve.

Le piège de vocabulaire est dans la première ligne, et il coûte cher en recherche. Le mode qui fait valider chaque action s’appelle Manual partout dans l’interface, mais sa valeur de configuration est default — celle qu’emploient les hooks et les intégrations. manual est accepté comme valeur depuis la 2.1.200.

Shift+Tab fait tourner les modes en session : depuis auto, la première pression bascule vers default, puis le cycle est default → acceptEdits → plan, les modes optionnels activés venant après, bypassPermissions d’abord et auto en dernier. C’est aussi la réponse à « le mode auto est-il disponible chez moi » : s’il apparaît dans le cycle, oui ; sinon une condition manque (offre, organisation, modèle, fournisseur), et ce n’est pas une panne passagère. bypassPermissions et dontAsk ne s’obtiennent qu’au lancement, et demander un changement de mode dans la conversation ne marche pas : chaque interface a son propre contrôle. Au démarrage dans un terminal, trois étapes décident, la première qui s’applique gagne : l’option de ligne de commande (claude --permission-mode plan), puis permissions.defaultMode dans un fichier de réglages, puis le défaut intégré. L’extension VS Code suit une liste à elle, et ne lit jamais les réglages d’un projet pour son mode de départ.

Une session reprise garde son mode, sauf si tu repasses une option de ligne de commande : plan et bypassPermissions ne sont jamais restaurés, auto ne l’est que si ton compte remplit encore ses conditions, et Manual reste Manual même là où une nouvelle session démarrerait en auto. Dernier point : approuver un plan fait sortir du mode plan, et chacun des trois choix proposés décrit le mode dans lequel la session bascule. C’est le moment où l’on change de mode sans s’en apercevoir.

Lire une demande avant d’y répondre

C’est le geste qui règle la première scène du début, et il ne demande aucun réglage. Sur une demande qui porte sur une commande, Bash comme PowerShell, Ctrl+E affiche une explication : ce que la commande fait, pourquoi Claude la lance, ce qui pourrait mal tourner, avec une étiquette Low risk, Med risk ou High risk. L’afficher n’exécute pas la commande, et celle-ci n’est envoyée au modèle qu’au moment où tu appuies.

Attention à ce que tu réponds ensuite, parce que le même bouton ne dure pas la même chose selon ce sur quoi tu réponds. « Yes, don’t ask again » couvre quatre familles, et une seule meurt avec ta session :

Ce sur quoi tu réponds	Ce que ça enregistre
une commande Bash	une règle permanente, par dépôt et par commande
un domaine WebFetch — l’outil qui va chercher une page web	une règle permanente, par dépôt et par domaine
une WebSearch — la recherche sur le web	une règle permanente, par dépôt
une modification de fichier	rien du tout : ça vaut jusqu’à la fin de la session

Les trois premières s’écrivent dans .claude/settings.local.json, à la racine de ton dépôt git : elles vaudront pour toutes tes sessions futures, dans tout le dépôt, sous-dossiers et worktrees compris (le terme est passé en leçon 6, le sujet entier est la leçon 14) — c’est la version 2.1.211 qui a fait remonter ce chemin jusqu’à la copie principale ; avant elle, la règle restait dans le dossier de lancement, et celles qui y ont été écrites y valent toujours. Hors dépôt git, et quand la racine du dépôt est ton répertoire personnel, elle est écrite dans le dossier d’où tu as lancé. Le même geste, deux durées de vie : c’est comme ça qu’on accumule des autorisations qu’on ne se souvient pas d’avoir données.

Ce que le mode auto laisse passer sans que tu le devines

Le classificateur bloque ce qui va au-delà de ta demande, ce qui vise une infrastructure qu’il ne reconnaît pas et ce qui semble piloté par du contenu hostile ; la liste bouge à chaque version, et claude auto-mode defaults l’imprime. Deux autorisations par défaut, elles, ne se devinent pas.

Autorisé par défaut	La nuance qui compte
lire les .env et envoyer les identifiants vers leur API correspondante	rien ne l’empêche par défaut, ni côté classificateur, ni côté bac à sable
pousser sur n’importe quelle branche du dépôt, branche par défaut comprise	une branche dont le nom la désigne comme cible de déploiement (production, gh-pages) n’est pas couverte ; le contenu du push reste examiné — force push, secret qui entre dans le commit ; un refus posé en règle bloque toujours, dans tous les modes ; et la protection de branche du dépôt distant s’applique

Où s’écrivent les règles

Fichier	Ce qu’il couvre	Partagé
~/.claude/settings.json	toi, dans tous tes projets	non
.claude/settings.json dans le projet	tout le monde sur ce dépôt	oui, versionné
.claude/settings.local.json, à la racine du dépôt	toi, sur ce dépôt	non — à condition qu’il soit exclu de git, ce qui n’est pas automatique
les réglages gérés, déployés par une organisation	tout le monde	oui

Quatre endroits, donc, et quand la même clé est posée à deux : réglages gérés d’abord (rien ne les contredit, ligne de commande comprise), puis la ligne de commande, le fichier local, le projet, toi. Les règles d’autorisation, elles, ne s’écrasent pas : elles se cumulent depuis toutes les portées, et un refus posé à n’importe quel niveau ne peut être levé par aucun autre.

Une réserve sur la troisième ligne, parce que c’est celle où tu vas écrire. Ce fichier n’est pas ignoré par git tout seul. L’exclusion n’est posée que quand c’est Claude Code qui y enregistre un réglage (un « ne me redemande plus »), et elle est écrite dans le fichier d’exclusions global de ta machine, pas dans le .gitignore du projet : elle ne voyage donc ni vers un second clone, ni vers un collègue. Si tu crées le fichier à la main, ou si tu le fais écrire, rien ne l’ignore et c’est à toi d’ajouter le motif. Sans ça, le premier git add -A emporte la liste de tes autorisations dans le dépôt — celles-là mêmes dont on vient de dire qu’on les accumule sans s’en souvenir.

Les deux ou trois règles qui tiennent

C’est la partie que personne ne fait, et la seule qui tient quand tu n’es pas devant l’écran. On les ajoute depuis /permissions, ou sous la clé permissions d’un des fichiers ci-dessus — et si c’est le fichier local qu’on ouvre à la main, la réserve ci-dessus s’applique : il faut l’exclure soi-même.

• Un point de contrôle sur ce qui sort de ta machine, en ask : Bash(git push *), Bash(gh pr create *). C’est la recette documentée, et une règle ask est évaluée avant le classificateur — elle force une demande même en mode auto. Ce qu’elle ne fait pas : c’est un motif de chaîne de caractères, pas une intention, et git -C . push origin main ne lui correspond pas. En dontAsk, une règle ask ne demande d’ailleurs pas : elle refuse, en silence.
• Un refus de lecture sur tes identifiants, en deny : Read(./.env), Read(./.env.*), puis Read(~/.ssh/**), Read(~/.aws/credentials) — la contrepartie de la première ligne du tableau ci-dessus. Les deux premiers motifs sont ceux de la documentation, et ce sont eux qui répondent à cette ligne : elle parle du fichier d’environnement de ton projet, pas de ton répertoire personnel. C’est aussi la réponse à la question laissée ouverte à la leçon 2, quand git status t’a mis un fichier de configuration sous les yeux : l’exclure de git décidait de ce qui part dans le dépôt, cette ligne-ci décide de ce qui peut être lu. Ce qu’il ne fait pas : il couvre les outils de fichiers et les commandes de fichiers que Claude Code reconnaît (cat, head, tail, sed), pas un script Python ou Node qui ouvre le fichier lui-même. Pour ce cas-là, le bac à sable et son réglage sandbox.credentials.
• Un refus sur l’action que ton projet ne doit jamais subir, en deny, en nommant la commande plutôt que la catégorie : celle qui déploie, celle qui migre, celle qui touche la production.

Sur Windows, ces règles ne s’écrivent pas forcément Bash(...). La leçon 2 a posé le mécanisme : sans Git Bash, l’outil PowerShell est activé d’office ; avec Git Bash installé, il s’ajoute à l’outil Bash par un déploiement progressif. Tu peux donc l’avoir sans l’avoir demandé et sans rien avoir changé. Quand il est actif, Claude traite PowerShell comme shell principal, et les règles de PowerShell sont une famille à part — même forme, autre nom : PowerShell(git commit *). Une barrière écrite pour Bash ne regarde tout simplement pas ce qui passe par là. Comme ce n’est pas un cas ou l’autre mais un état qui peut changer sous toi, la conclusion pratique tient en une ligne : sur Windows, écris les deux familles plutôt que de parier sur celle qui est active chez toi.

Ces trois règles tiennent dans un fichier qui se rejette en bloc. Une seule erreur de schéma (une virgule en trop, une valeur du mauvais type, n’importe où dans le fichier), et Claude Code ne rejette pas la ligne fautive : il rejette le fichier entier. Tes trois règles tombent avec elle. Ce n’est pas une hypothèse d’école : ce même fichier est celui où la leçon 9 te fera écrire tes remplacements de skills, la leçon 13 tes déclenchements automatiques, la leçon 14 un réglage de copies de travail, la leçon 15 un bloc de variables. Chaque ajout est une occasion de désarmer les trois règles, et rien à l’écran ne fait le lien.

Détail qui dit à qui profite la tolérance : les réglages déployés par une organisation, eux, ne sont pas rejetés en bloc — seule l’entrée invalide est retirée, le reste continue de s’appliquer. L’entreprise est protégée de la faute de frappe. Toi, non.

Trois choses à savoir avant d’écrire. L’ordre d’évaluation est refus, puis demande, puis autorisation : la première correspondance dans cet ordre décide, et la précision de la règle n’y change rien. Un refus large ne supporte donc pas d’exception — Bash(aws *) bloque aussi ce qu’un Bash(aws s3 ls) autorisé couvrirait. Et un refus qui nomme un outil nu (Bash) retire l’outil du contexte de Claude, qui ne le voit jamais, là où un refus délimité (Bash(rm *)) laisse l’outil disponible et bloque les appels correspondants ; un seul outil échappe à ce retrait, celui qui met fin à la conversation.

Quatre gestes pour vérifier ensuite : /permissions liste les règles effectives et leur fichier d’origine, c’est là qu’on retrouve celle qu’on a laissée s’écrire un jeudi soir ; son onglet Recently denied liste ce que le classificateur a bloqué, r rejouant une ligne avec une approbation manuelle ; claude auto-mode config imprime ce que le classificateur utilise réellement. Le quatrième répond à la question d’avant toutes les autres : est-ce que mon fichier a seulement été lu ? Au démarrage, un fichier invalide déclenche un dialogue Settings Error, qui propose de le réparer, de quitter, ou de continuer sans les réglages cassés. Cette troisième option est celle qu’on choisit sans réfléchir parce qu’elle laisse travailler : c’est elle qui te fait passer une session entière sans tes règles. Si tu l’as prise, /status liste les fichiers touchés (sa ligne Setting sources dit quelles couches ont été chargées) et claude doctor donne le détail de chaque erreur. Un dispositif qu’on ne regarde jamais finit par ne plus rien tenir sans prévenir — c’est le sujet entier de la leçon 13.

Le bac à sable, la seule barrière que le système tient lui-même

Le bac à sable est d’une autre nature que tout ce qui précède. Les décisions d’autorisation sont prises avant l’exécution, à partir de la chaîne de commande et, en mode auto, du jugement du classificateur. Le bac à sable, lui, est appliqué par le système d’exploitation sur le processus en train de tourner : sa frontière tient quoi que le modèle ait choisi de lancer, et même si une commande autorisée fait plus que ce que son nom suggère.

C’est ce qui en fait la réponse au risque annoncé à la leçon 1. La documentation l’écrit sans détour : les restrictions du bac à sable empêchent les commandes d’atteindre des ressources hors de la frontière « même si une prompt injection a contourné la décision de Claude ». Relis la phrase : elle suppose que le contournement a réussi. Tous les autres dispositifs de cette leçon dépendent d’un jugement — le tien, ou celui du classificateur ; celui-ci est le seul qui tienne encore quand ce jugement a été retourné par un contenu que quelqu’un d’autre a écrit. C’est aussi pour ça qu’il vaut la peine de l’installer avant d’en avoir besoin.

L’installation n’est pas la même partout : rien sur macOS, deux paquets sur Linux et WSL2, WSL2 obligatoire sur Windows natif. Et le contrôle de dépendances tourne au démarrage : redémarre après avoir installé, sinon l’onglet Dependencies de /sandbox continuera de les réclamer.

Deux noms se ressemblent et désignent deux mécanismes distincts : l’approbation automatique du bac à sable (auto-allow) approuve parce que la frontière contient la commande, le mode auto parce qu’un classificateur l’a jugée. D’où le point qui surprend, et que la leçon 2 t’avait annoncé : l’approbation automatique du bac à sable fonctionne indépendamment de ton mode d’autorisation, à une exception près, le mode plan. Des commandes qui modifient des fichiers à l’intérieur de la frontière s’exécutent donc sans rien demander même en mode Manual, là où les outils d’édition demanderaient. Ce qui tient quand même : les refus explicites, les rm visant la racine, ton répertoire personnel ou des chemins système critiques, et les règles ask délimitées par leur contenu. Une règle ask sur Bash nu, elle, est sautée en bac à sable.

Ce que ça ne fait pas

Le mode auto n’est pas une relecture

La documentation le dit elle-même, et la phrase vaut d’être retenue mot pour mot :

Auto mode reduces permission prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations.

Il réduit les demandes d’autorisation ; il ne garantit pas la sécurité, et ne remplace pas la relecture sur les opérations sensibles. Trois conséquences qu’on ne voit pas venir :

• le garde-fou cède au bout de N essais. Si le classificateur bloque une action 3 fois de suite ou 20 fois au total, le mode auto se met en pause et les demandes reviennent ; approuver l’action redemandée le relance. Le compteur consécutif se remet à zéro à la première action autorisée, le total persiste pour la session et ne retombe qu’une fois qu’il a lui-même déclenché la bascule. Ces seuils ne sont pas configurables ;
• dans une exécution non interactive (claude -p sans outil de demande dédié), il n’y a aucune demande de repli : l’action ne s’exécute pas, et Claude continue de travailler comme si de rien n’était, dans la conversation principale comme dans ses subagents ;
• quand le classificateur ne rend aucun verdict, l’action est refusée sans notification et sans entrée dans Recently denied. Ton tableau de bord ne la verra pas.

Ce qu’il voit, enfin : tes messages, les appels d’outils et le CLAUDE.md — les résultats d’outils, eux, lui sont retirés, donc du contenu hostile dans un fichier ou une page web ne peut pas le manipuler directement. Et pour les subagents (leçon 4), un permissionMode posé en tête de leur fichier est ignoré en mode auto.

Les barrières qu’on croit avoir posées

Dire « ne pousse pas avant que j’aie relu » dans la conversation n’est pas une règle. Le classificateur traite bien ces frontières comme un signal de blocage, et elles tiennent jusqu’à ce que tu les lèves toi-même, mais elles ne sont stockées nulle part : il les relit dans le fil à chaque contrôle. Une compaction qui retire le message où tu l’as dite fait disparaître la frontière — et la leçon 3 t’a montré que la compaction ne prévient pas.

Ce que tu poses	Ce que ça vaut en mode auto
une règle deny	bloque avant que le classificateur soit consulté ; ni lui ni ton intention ne passent outre
une règle ask délimitée	fait toujours demander ; le classificateur ne peut pas auto-approuver l’action
une règle allow large	est suspendue à l’entrée en mode auto, et rétablie à la sortie
une phrase dans la conversation	le classificateur bloque — mais la frontière peut être perdue à la compaction

La troisième ligne surprend dans les deux sens. Les autorisations larges qui donnent l’exécution de code arbitraire (Bash(*), les interpréteurs génériques comme Bash(python*), les commandes de lancement des gestionnaires de paquets, les autorisations d’Agent) sont abandonnées tant que le mode auto est actif. Mais les règles étroites sont conservées et résolues avant le classificateur : Bash(npm test) laisse passer sans qu’il voie rien, y compris un argument que le préfixe n’avait pas prévu. autoMode.classifyAllShell à true les suspend toutes.

Une autorisation que tu écris ne couvre jamais les chemins protégés. Le contrôle de sécurité tourne avant l’évaluation des règles allow : Edit(.claude/**) n’y change rien. Selon le mode, l’écriture est demandée (default, acceptEdits), envoyée au classificateur (auto), refusée (dontAsk) ou autorisée (bypassPermissions).

Une règle mal écrite, elle, est acceptée et n’est jamais consultée. Un avertissement au démarrage signale certains cas — pas tous, et il défile avec le reste. Trois pièges de syntaxe produisent une barrière fantôme :

• une seule barre oblique en tête n’est pas un chemin absolu, mais un chemin ancré à la source du réglage — il faut // ;
• seules les règles de chemin écrites pour Edit et Read sont consultées ; celles écrites pour Write, NotebookEdit, Glob ou l’ancien MultiEdit sont acceptées puis ignorées — c’est celui des trois qui avertit au démarrage, depuis la version 2.1.210 et sauf pour un Glob passé dans --allowedTools ;
• les lanceurs d’environnement ne sont pas déballés, si bien qu’autoriser Bash(devbox run *) autorise tout ce qui vient après run, devbox run rm -rf . compris.

S’y ajoute la barrière fantôme du mode de départ : un permissions.defaultMode posé dans les réglages d’un projet ne sera pas lu par les conversations que l’extension VS Code démarre, et la valeur "auto" posée dans les réglages de projet ou locaux ne prend pas effet du tout — pire, Claude Code retombe alors sur le défaut intégré au lieu du defaultMode de tes réglages utilisateur. Enfin, les refus de lecture et d’écriture ne couvrent pas un programme qui ouvre les fichiers lui-même : un script Python ou Node passe à travers, et pour une barrière au niveau du système d’exploitation, il n’y a que le bac à sable.

Le bac à sable n’est pas un coffre-fort

Par défaut, les commandes en bac à sable écrivent seulement dans le répertoire de travail et le répertoire temporaire de la session — mais elles lisent presque tout l’ordinateur, fichiers d’identifiants compris (~/.aws/credentials, ~/.ssh/). Il n’existe aucune liste de refus intégrée : seuls les fichiers et variables déclarés dans sandbox.credentials sont restreints.

Piège — si le bac à sable ne peut pas démarrer, dépendance manquante ou plateforme non prise en charge, le comportement par défaut est d’afficher un avertissement et d’exécuter les commandes sans bac à sable. La barrière que tu crois avoir n’est pas là, et rien ne t’arrête. Il faut poser sandbox.failIfUnavailable à true pour en faire un échec dur.

Autre limite du même ordre : une commande qui échoue à cause du bac à sable peut être relancée dehors, avec dangerouslyDisableSandbox. Elle repasse par le flux d’autorisation normal, donc en Manual tu reçois une demande — mais en mode auto c’est le classificateur qui tranche, pas toi. "allowUnsandboxedCommands": false coupe l’échappatoire.

bypassPermissions est un engagement plus long que ta session

On ne peut pas y entrer depuis une session démarrée sans lui : il s’active au lancement. La première fois, un dialogue demande d’accepter la responsabilité des actions prises sans contrôle — et cette acceptation est enregistrée dans tes réglages utilisateur, donc il n’apparaît qu’une fois, pour toujours et pour tous tes projets.

Ce qui tient encore : les règles ask explicites, les outils qu’une organisation a mis à ask, les outils MCP marqués comme exigeant une interaction humaine, deux garde-fous sur les messages entre tes sessions, et les suppressions visant la racine du système de fichiers ou ton répertoire personnel (rm -rf /, rm -rf ~). Un dernier joue en amont : sur Linux et macOS, le programme refuse de démarrer dans ce mode en root ou sous sudo — sauf à l’intérieur d’un bac à sable reconnu, où le contrôle est sauté.

Ce qui ne tient plus : dans une session où le bypass est disponible, les blocages du mode plan ne sont plus appliqués non plus. Claude a toujours pour instruction de planifier sans modifier, mais une édition tentée pendant la planification s’exécute sans demander. Le mode le plus prudent des six cesse d’être une barrière dans la session où tu as levé les autres. Pour t’interdire ce mode à toi-même, permissions.disableBypassPermissionsMode à "disable" fonctionne depuis n’importe quelle portée de réglages, y compris la tienne.

Où c’est écrit

• Modes d’autorisation — les modes, le départ, le classificateur, les chemins protégés ;
• Permissions — les règles, leur ordre, leur syntaxe et ses pièges, la précédence ;
• Configurer le mode auto — le point de contrôle humain, la revue des refus ;
• Bac à sable — l’installation, les modes, la protection des identifiants ;
• Sécurité — et surtout se protéger de la prompt injection, la seule page qui traite le risque nommé à la leçon 1 ; à lire avant de brancher quoi que ce soit qui aille chercher du contenu sur le web.

Pas de renvoi vers la version française cette fois : ouverte le 18 août 2026, elle décrit encore un état antérieur du programme sur les modes — pas de section sur le mode dans lequel une session démarre, et l’ancienne règle sur les push autorisés par défaut.

Ce que cette leçon ajoute à ces pages : la séparation entre ce que le mode règle et ce que seules les règles règlent, que la documentation n’a pas de raison de formuler puisqu’elle documente chaque mécanisme chez lui ; et la liste rassemblée des barrières qui ont l’air posées sans l’être.

Le point de bascule

Tu as basculé le jour où, en voyant passer une demande d’autorisation, ta question n’est plus « est-ce que je clique oui » mais « qu’est-ce qui aurait arrêté ça si je n’avais pas été là ? ». Si la réponse est « rien », le mode n’y changera rien : c’est une règle qui manque — deny si ça ne doit jamais arriver, ask si ça doit t’attendre.

Vérifier que c’est passé

Tu travailles en mode auto. En début de session, tu écris « ne pousse rien, je veux relire avant ». Deux heures et une conversation compactée plus tard, il pousse sur la branche par défaut. Bug ?

Non, et les deux moitiés sont documentées. Une frontière énoncée dans la conversation n’est pas stockée comme une règle : le classificateur la relit dans le fil à chaque contrôle, donc une compaction qui retire ce message la fait disparaître. Et pousser sur n’importe quelle branche du dépôt, branche par défaut comprise, est autorisé par défaut en mode auto. Il fallait une règle — deny bloque avant le classificateur, ask force toujours une demande.

La semaine dernière tu as répondu « Yes, don't ask again » deux fois : une fois sur une commande, une fois sur une modification de fichier. Aujourd'hui, dans un autre dossier du même dépôt, l'une des deux ne te demande plus rien et l'autre si. Que s'est-il passé ?

Les deux réponses n’ont pas la même durée de vie. Sur une commande Bash, l’approbation devient une règle permanente dans .claude/settings.local.json à la racine du dépôt git : elle vaut pour toutes les sessions futures, dans tout le dépôt, sous-dossiers et worktrees compris. Deux autres réponses s’enregistrent de la même façon, et on les oublie encore plus facilement : un domaine WebFetch et une WebSearch. La modification de fichier est la seule des quatre à n’être écrite nulle part — elle meurt avec la session. Pour voir ce que tu as accumulé : /permissions, et le fichier d’origine de chaque règle.

Tu es en mode Manual, donc tu t'attends à valider chaque écriture. Une commande modifie plusieurs fichiers sans t'avoir rien demandé. Avant de conclure à un bug, tu vérifies quoi ?

Si le bac à sable tourne en approbation automatique, c’est le comportement documenté : elle fonctionne indépendamment de ton mode d’autorisation, à une exception près, le mode plan. Des commandes qui modifient des fichiers à l’intérieur de la frontière s’exécutent donc sans demander, y compris en Manual, là où les outils d’édition demanderaient. Ce n’est pas le mode auto : deux mécanismes distincts qui portent presque le même nom. Regarde /sandbox avant d’accuser le mode — ce qui reste ferme là-dedans, ce sont les refus explicites et les ask délimitées par leur contenu.