Il y a des notes de version qui se lisent comme une facture de plombier, et celle du 15 septembre en fait partie. Deux lignes, perdues au milieu de correctifs de connexion et de compteurs de contexte, disent ceci : des commandes que le contrôle des permissions n'arrivait pas à analyser complètement passaient sans demander l'accord de l'utilisateur, et un sous-shell arrivait à cacher une suppression de fichiers dangereuse. Traduction pour ceux qui n'ont jamais ouvert un terminal : le videur qui vérifie les commandes à la porte avait deux angles morts, et ils sont bouchés.

Ce n'est pas un détail de plomberie, c'est la promesse centrale de ces outils. Claude Code ne travaille pas tout seul dans son coin : il exécute des commandes sur votre machine, il lit et écrit des fichiers, il pousse du code. En échange, il vous demande l'autorisation avant de faire quelque chose de suspect. Toute la confiance qu'on lui accorde tient sur un programme qui lit une ligne de texte et décide si elle est dangereuse. Et ce programme, visiblement, se laisse raconter des histoires.

Comment le programme décide de te demander la permission

Le principe est simple à décrire. Avant d'exécuter une commande, l'outil la lit, la découpe, compare ce qu'il voit à la liste de vos règles, et regarde si elle sort ou non du dossier dans lequel vous l'avez laissé travailler. Si elle a l'air inoffensive, il la lance. Si elle sent le brûlé, il vous la montre et attend votre réponse.

Le badge ouvre, la porte reste fermée, et tout le monde est content jusqu'au jour où quelqu'un passe derrière

Tout repose donc sur une lecture. Pas sur un bac à sable, pas sur une machine séparée, sur une lecture. Et une lecture, ça se trompe. C'est exactement ce que la liste des correctifs raconte depuis quelques semaines : chaque fois, une formulation un peu tordue, une commande qui se déguise, et le contrôle conclut à tort que tout va bien.

Les deux trous bouchés le 15 septembre

Le premier concerne les commandes trop bizarres pour être analysées. La consigne dit que rien ne doit pouvoir lire en dehors du dossier de travail, et pendant un temps, une ligne que le contrôle ne comprenait pas passait sans question au lieu de déclencher l'alerte. Autrement dit, plus une commande était tordue, moins elle était contrôlée. Il fallait le faire.

Le second est plus vicieux et il est de ceux qui font sourire jaune. Une commande de suppression placée dans un sous-shell, c'est-à-dire entre parenthèses, à l'intérieur d'une autre commande, pouvait passer à travers dans le mode où l'outil ne demande plus rien du tout. C'est le mode que choisissent justement les gens pressés, ceux qui font tourner plusieurs sessions en parallèle et qui ne veulent plus valider chaque ligne, et dont je racontais le mois dernier à quel point il change la façon de travailler. C'est-à-dire moi, accessoirement, et probablement beaucoup d'autres.

La porte était bien fermée, la serrure était juste posée à côté

Ce n'était pas un accident isolé

Ce qui rend l'histoire intéressante, c'est la note de version du 14 septembre, la veille. Elle corrige une série de trous du même genre, tous dans le même contrôle : un fichier pouvait être lu par une commande dont l'option n'était pas reconnue, des fichiers pouvaient passer parce qu'ils venaient d'une étoile dans un chemin de dossier, une variable de shell pouvait décrire une toute autre commande que celle réellement lancée, et deux changements de dossier bout à bout pouvaient faire sauter la question dans les modes où l'outil ne demande plus rien.

Ce ne sont pas des scénarios de film. Ce sont des formulations ordinaires, celles qu'on écrit sans y penser, et le fait que six ou sept d'entre elles aient demandé un correctif le même jour dit quelque chose de la difficulté du problème : analyser une ligne de commande, c'est analyser un langage, et un langage a toujours un coin sombre.

La bonne nouvelle, c'est que les garde-fous se resserrent en même temps. La même mise à jour ajoute une autorisation de réseau par commande : quand l'outil a besoin d'accéder à un site pour une commande précise, il vous demande l'autorisation pour ce site-là et pour cette commande-là, et refuse tout le reste. Elle permet aussi de faire tourner les sous-agents sans leur coller vos fichiers d'instructions sur le dos, ce qui était loin d'être anodin pour ceux qui trimballent des consignes maison un peu partout.

Si tu es développeur

La leçon tient en une phrase : la vérification des commandes est un filtre, pas un mur. Un filtre qui, jusqu'à la semaine dernière, laissait passer les lignes les plus tordues, donc précisément celles qui méritaient le plus d'attention.

Le filtre arrête les gros morceaux et laisse passer la semoule, exactement le reproche fait au contrôle des permissions

Trois réflexes qui coûtent moins cher que la confiance. Mettre à jour, d'abord, parce que la version 2.1.273 corrige les deux trous décrits ici et que personne n'a envie de faire le malin avec une version qui a un mois de retard. Ensuite, ne pas confondre le mode sans question avec un mode sécurisé : il ne demande rien, ce qui veut dire qu'il ne vous protégera de rien, et il faut le réserver aux dossiers dont vous acceptez de perdre le contenu. Enfin, faire travailler l'outil dans un dossier jetable quand on lui donne une grosse tâche à écrire, plutôt que dans le dossier où vivent trois ans de travail. Ce n'est pas de la prudence de principe : il y a dix jours, un dossier de projet suffisait à faire tourner le code d'un inconnu sur la machine de celui qui l'ouvrait.

Le fichier de configuration qui décrit vos règles, de son côté, mérite d'être relu une fois par trimestre. Les règles oubliées d'un vieux projet ont la fâcheuse habitude de s'appliquer encore à celui du jour.

Espérons juste que la prochaine fournée de correctifs, dans une ou deux semaines, ne raconte pas la même histoire avec d'autres mots. À chaque fois, c'est une ligne tordue que quelqu'un a fini par écrire, et personne ne sait combien dorment encore dans la nature.