Vendredi, Claude Code arrête de te demander la permission. Et le chiffre qui va avec fait mal.

Le 14 août, dans deux jours, le mode auto deviendra le réglage par défaut de Claude Code pour les formules Pro, Max et Team. En clair, plus de petite fenêtre pour te demander si tu autorises une commande. L'outil décide et l'exécute.

Ma première réaction a sans doute été la même que la tienne. Ah bon. On me retire le bouton ?

Puis j'ai lu le chiffre publié par Anthropic dans son annonce. J'ai tout de suite fait un peu moins le malin.

Quelque part dans la pile, il y a la commande qui efface tout. Il a dit oui.

Tu cliques sur oui 97 fois sur 100

97 %. C'est la proportion de demandes d'autorisation que les utilisateurs approuvent. Pas 60. Pas 80. Quatre-vingt-dix-sept.

Autrement dit, ce fameux garde-fou ne contrôle plus grand-chose. C'est un bouton « suivant » avec une étape en plus.

Anthropic a mené une étude auprès de 1 053 testeurs rémunérés. Les deux groupes ont reçu le même ensemble d'actions dangereuses. Résultat, la validation humaine en bloque 143. Le mode auto en bloque 937.

Le bâton bleu, c'est nous. On va dire que c'est la fin de journée.

Et ce n'est pas seulement vrai en laboratoire. Dans les sessions réelles de mai et juin, des dégâts sérieux et involontaires apparaissent dans 6,3 % des sessions validées à la main, contre 2,4 % en mode auto. Plus du double, et pas dans le bon sens.

Le problème est connu depuis longtemps. Il s'appelle la fatigue de validation. C'est ce qui t'arrive avec les bandeaux de cookies, les conditions d'utilisation et les demandes d'autorisation de ton téléphone. Après la troisième demande, ton cerveau ne lit plus. Ta main, elle, continue de cliquer.

Bon, alors ça bloque quoi, maintenant ?

Le mode auto ne supprime pas le contrôle. Il change de contrôleur. Chaque action passe devant ce qu'Anthropic appelle un classifieur. C'est une deuxième instance qui examine ce que l'outil s'apprête à faire, puis décide de l'autoriser ou non. Sa consigne est simple : bloquer ce qui est irréversible, destructif ou dirigé vers l'extérieur de ton environnement.

Le videur ne lit pas ton code. Il regarde ce que tu portes.

Concrètement, certaines actions restent interdites sans exception, comme l'envoi de code ou de secrets vers l'extérieur. Cette règle ne peut être levée ni avec une option ni en insistant. D'autres actions restent bloquées, sauf si tu les demandes explicitement. C'est le cas du force push, qui réécrit de force l'historique Git, de la suppression de branches ou de tags distants, de la réécriture de l'historique, du fameux curl | bash et des déploiements en production.

La nuance autour du mot « explicitement » est jolie. Elle figure même dans la documentation. Demander à Claude de « nettoyer le dépôt » ne l'autorise pas à effectuer un force push. Lui demander de « force-pusher cette branche », oui. Une demande vague ne vaut pas consentement. C'est aussi une bonne règle de vie.

Autre détail bien pensé, le classifieur ne fait confiance, par défaut, qu'à ton répertoire de travail et aux dépôts distants déjà configurés. Ton bucket d'entreprise, ton GitLab interne ou ton registre privé de paquets ? Inconnus au bataillon. Ils sont donc considérés comme extérieurs et restent bloqués tant que tu ne les as pas déclarés.

Le piège que personne ne va lire

Il y en a un. Et il est vicieux.

Quand le mode auto est actif, tes règles d'autorisation générales, comme celle qui permet tout dans le terminal, sont mises de côté. C'est logique, puisqu'elles contourneraient le classifieur. En revanche, les règles plus précises, celles qui autorisent une commande particulière, restent prioritaires. Le problème, c'est qu'une règle précise autorise un préfixe de commande, pas son résultat. Si la commande reçoit un argument dangereux que la règle n'avait pas prévu, elle passe sans être examinée.

Tout ce budget de sécurité, et la porte de service est restée ouverte.

La parade tient en une ligne de configuration à ajouter dans ton fichier de réglages personnel :

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Ce réglage oblige toutes les commandes du terminal à passer devant le classifieur, y compris celles qui disposent déjà d'une autorisation. Tu perds un peu de temps à chaque commande, puisqu'il faut attendre sa décision. Personnellement, je préfère.

Deuxième point, et celui-là mérite un bravo. Le classifieur ne lit pas les réglages placés dans le dossier du projet. Il consulte seulement ceux de ton compte et ceux déployés par ton entreprise. La raison est écrite noir sur blanc dans la documentation. Sinon, un dépôt cloné ou une simple étape de compilation pourrait ajouter ses propres règles d'autorisation et se donner le feu vert tout seul. Quelqu'un chez Anthropic a pensé au dépôt piégé. Ça fait plaisir.

Comment garder la main, en quatre recettes

Si tu veux une validation humaine avant chaque envoi de code, une règle peut prendre la priorité sur le classifieur et afficher la demande à chaque fois. Ajoute ceci dans tes réglages :

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

C'est ce que j'utilise. Le reste fonctionne en mode auto. La seule chose qui me réveille, c'est le moment où mon travail quitte ma machine.

Pour changer de mode en cours de route, Shift+Tab fait défiler les modes dans le terminal. Pour voir les règles que le classifieur applique réellement chez toi, utilise cette commande. Elle est plus utile qu'elle n'en a l'air :

claude auto-mode config

Elle affiche les règles réellement appliquées, c'est-à-dire les tiennes une fois fusionnées avec celles d'origine. Tu peux aussi utiliser claude auto-mode defaults pour consulter les règles intégrées et claude auto-mode reset pour tout remettre d'équerre après avoir trop bricolé.

Attention, parce que cette erreur peut coûter cher. Si tu écris ta propre liste de règles sans conserver la mention "$defaults", tu remplaces toute la liste d'origine. Cela inclut la règle qui empêche l'exfiltration des données. Tu pensais ajouter une ligne. Tu viens d'en supprimer trente.

Dernier réflexe utile, quand une action est refusée, tape /permissions et consulte l'onglet des refus récents. Tu peux indiquer qu'une action doit être retentée. C'est mieux que de tout désactiver en décidant que le portier est trop bête.

Et puis il y a la couche au-dessus, celle dont je n'ai pas encore parlé et que tu écris toi-même : les hooks.

Un hook, c'est un bout de script que Claude Code lance avant d'utiliser un outil. Il passe avant les règles d'autorisation, avant le classifieur, avant tout le reste. Le mode auto ne le désactive pas. La documentation précise que le hook reçoit le mode en cours parmi ses données d'entrée, y compris "auto". On ne transmet pas un paramètre à quelque chose qu'on n'exécute pas.

La différence est simple. Le classifieur est un modèle chargé de prendre une décision. Il lit l'intention, analyse le contexte pendant quelques centaines de millisecondes et peut se tromper. Un hook, lui, ne juge rien. Quinze lignes regardent le chemin d'un fichier et répondent non. Pas d'avis, pas de nuance, pas de fatigue. Et pas un jeton dépensé.

Chez moi, il y en a deux. Ce sont exactement ceux que tu imagines. Le premier bloque toute lecture d'un fichier .env, d'un fichier .pgpass, d'une clé SSH ou du fichier d'identifiants. Peu importe le mode ou la raison, même si je demande gentiment. Le second exige mon accord avant chaque git push. Une autorisation ne vaut jamais pour la tentative suivante. Et ça sert. En écrivant cet article, j'ai voulu relire un fichier de documentation rangé au mauvais endroit. Mon propre script m'a envoyé promener. Trois secondes d'agacement, puis plutôt content.

Dans les réglages, ça tient en quelques lignes :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Edit|Write",
        "hooks": [
          { "type": "command", "command": "~/.claude/hooks/block-secrets.sh" }
        ]
      }
    ]
  }
}

Le script se termine avec le code de sortie 2, donc l'outil n'est pas lancé. S'il ne faut retenir qu'une phrase, c'est celle-ci : quand tu sais déjà ce qui ne doit jamais arriver, ne demande pas son avis à un modèle. Écris trois lignes de script.

Et si tu ne codes pas, ça te concerne quand même

Ce chiffre de 97 % ne concerne pas seulement les développeurs. C'est aussi le tien.

Combien de fois as-tu accepté des conditions d'utilisation sans les lire ? Cliqué sur « tout accepter » pour faire disparaître un bandeau de cookies ? Donné à une application l'accès à tes photos, à ta position et à tes contacts parce qu'elle refusait de s'ouvrir autrement ? Tu as fait exactement comme ces développeurs. Tu as validé pour pouvoir continuer.

Le vrai enseignement, c'est que la case à cocher n'a jamais vraiment servi à te protéger. Elle sert surtout à transférer la responsabilité. Si quelque chose tourne mal, quelqu'un pourra dire que tu avais accepté. Une protection qui laisse passer neuf dangers sur dix n'est pas une protection. C'est un parapluie juridique.

Alors, quand une machine fait mieux que notre clic machinal, il faut le reconnaître. Même si ça pique un peu.

Ce que j'en pense

Les chiffres sont têtus, et je les crois. Boris Cherny, le responsable de Claude Code, affirme que son équipe et lui utilisent exclusivement le mode auto depuis des mois. Honnêtement, moi aussi, je l'utilise déjà.

Ce qui me gêne, ce n'est pas le mode auto. C'est le mot « défaut ».

Tant que je choisis, j'assume. Quand le réglage est activé pour tout le monde et que la question ne se pose plus, la responsabilité devient floue. Si quelque chose tourne mal, on finira toujours par entendre « c'était le réglage d'usine ». Cela dit, si tu avais déjà choisi ton mode, il reste en place. On te demande seulement une fois si tu veux basculer.

Vendredi, je regarderai donc ce que ça donne. Je garderai ma règle sur les envois de code. Je suis peut-être convaincu par l'étude, mais pas au point de laisser partir mon travail sans lever les yeux.