Accueil / Fondamentaux et boucle d'agent
Lire et approuver un diff
Un diff se lit ligne par ligne avant d'être approuvé, et l'approbation elle-même se fait aujourd'hui par un menu à options nommées plutôt que par une frappe libre de lettre.
Un diff marque en moins ce qui disparaît d'un fichier et en plus ce qui s'ajoute. Une modification chirurgicale, qui ne touche que ce qui est nécessaire, se reconnaît à la brièveté de ces deux blocs, peu de lignes en moins, peu de lignes en plus, concentrées sur le point précis de la demande.
Un menu, pas une frappe libre
Quand Claude propose de modifier un fichier, l'invite de permission qui s'affiche est aujourd'hui un menu à options nommées, Yes, Yes and don't ask again, qui vaut jusqu'à la fin de la session pour une édition de fichier, et No. Cette édition n'est pas enregistrée dans le fichier lui même : le tableau des permissions le montre, elle dure jusqu'à la fin de session. Ce n'est que pour une commande shell ou un domaine WebFetch qu'un choix mémorisé survit à la session et au redémarrage, de façon permanente et par dépôt. On se déplace vers l'option voulue et on valide par Entrée. La touche Tab ouvre, avant de valider, un champ de commentaire attaché à l'option choisie, ce qui permet d'expliquer un refus plutôt que de le laisser muet. Aucune option nommée de ce menu ne permet d'éditer directement le contenu du diff affiché à cet endroit précis. Éditer un contenu proposé passe par un autre canal, la combinaison Ctrl+G, qui ouvre un plan dans l'éditeur de texte par défaut avant approbation, un mécanisme distinct de l'édition d'un diff de code déjà proposé à ce stade.
Lire avant d'approuver, ligne par ligne
La lecture ligne par ligne reste le geste qui protège, quel que soit le mécanisme d'approbation en place. Un diff qui touche vingt fichiers pour un changement annoncé comme localisé mérite un refus, ou un commentaire explicite ajouté par Tab, plutôt qu'une approbation rapide. Voici un exemple de diff minimal, produit sur des fichiers fabriqués pour la démonstration :
mkdir -p /tmp/demo-diff
printf 'ligne un\nligne deux\nligne trois\n' > /tmp/demo-diff/avant.txt
printf 'ligne un\nligne deux modifiée\nligne trois\n' > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
La sortie affiche une seule ligne retirée et une seule ligne ajoutée, exactement le périmètre attendu d'une modification chirurgicale. Un diff qui, pour la même demande, déplacerait aussi les lignes un et trois sort du périmètre nécessaire.
Le mode qui supprime cette invite entièrement, --dangerously-skip-permissions, équivaut au mode de permission bypass présenté dans la leçon sur les permissions et le mode plan. Ce mode est refusé par défaut si la session tourne en tant que root ou sous sudo sur Linux et macOS, sauf à l'intérieur d'un bac à sable reconnu, et sa première utilisation interactive affiche une boîte de dialogue d'avertissement à accepter une fois.
Les trois options du menu de permission sur une modification de fichier
| Invite de permission affichée sur une modification de fichier proposée par Claude | Effet immédiat | Effet pour la suite du dépôt |
|---|---|---|
| Yes | La modification proposée est appliquée une fois | Aucun changement pour les prochaines demandes |
| Yes and don't ask again | La modification proposée est appliquée | Plus d'invite jusqu'à la fin de la session, pas au delà, contrairement à une commande shell mémorisée |
| No | La modification proposée n'est pas appliquée | Un commentaire ajouté par Tab peut expliquer le refus |
Une ingénieure demande à Claude Code de renommer une variable dans un seul fichier. Claude propose une modification et l'invite de permission apparaît sous la forme d'un menu avec les options Yes, Yes and don't ask again et No. L'ingénieure déplace le curseur sur Yes et appuie sur Tab avant de valider.
Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.
Ce que cela établit : La situation établit qu'un champ de commentaire s'est ouvert sur l'option Yes avant que l'ingénieure ne valide son choix par Entrée.
Ce que cela n’établit pas : Elle n'établit pas quel texte l'ingénieure a écrit dans ce champ, ni si la modification proposée a finalement été appliquée.
Les trois calibrages faux les plus courants
- Trop large Elle établit que toute approbation de modification de fichier dans Claude Code passe désormais obligatoirement par l'ajout d'un commentaire.
- Trop étroit Elle établit seulement que la touche Tab existe sur le clavier utilisé par l'ingénieure, sans rien dire de son effet dans Claude Code.
- À côté Elle montre que le renommage de variable demandé touchait un fichier plus complexe que la moyenne des fichiers du projet.
- L'invite d'approbation d'une modification de fichier est aujourd'hui un menu à options nommées, Yes, Yes and don't ask again, No, et non une frappe libre de lettre.
- Sur une édition de fichier, Yes and don't ask again vaut jusqu'à la fin de la session, jamais plus : la mémorisation permanente par dépôt et par commande ne s'applique qu'à une commande shell ou un domaine WebFetch.
- La touche Tab ouvre un champ de commentaire attaché à l'option choisie avant de valider par Entrée.
- Aucune option de ce menu ne permet d'éditer directement le contenu du diff affiché à cet endroit.
- Le mode --dangerously-skip-permissions équivaut au mode bypass et se refuse par défaut en session root ou sudo hors bac à sable reconnu.
Sur une modification que vous demandez à Claude Code dans votre projet, ouvrez le champ de commentaire de l'invite avec Tab avant de valider, et écrivez en une phrase pourquoi vous approuvez ou refusez ce diff précis.
Ces points dépendent d’une interface ou d’une règle qui peut avoir changé depuis la rédaction. Vérifiez-les sur votre propre écran avant de vous y fier.
- Le nombre exact d'options affichées sur un prompt d'édition de fichier précis n'est pas documenté écran par écran sur une seule page source.
Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.