Rapport : selon Apiiro, le « Don't Ask Again » de Claude Code a exposé des mots de passe dans 1 122 fichiers publics sur GitHub. Vérifiez .claude/settings.local.json

Verdict : si quelqu'un dans votre équipe a déjà cliqué sur « Yes, and don't ask again » (« Oui, et ne plus demander », notre traduction) pour une commande qui portait un mot de passe, un jeton ou une clé, partez du principe que cet identifiant se trouve dans .claude/settings.local.json, et vérifiez si le fichier a atteint Git. Le décompte d'Apiiro est un chiffre rapporté et nous n'avons pas pu lire son billet, mais le mécanisme figure dans la documentation d'Anthropic : « Yes, and don't ask again » enregistre l'approbation comme règle allow dans .claude/settings.local.json, et Claude Code ne tient ce fichier hors des commits que via vos exclusions git globales. Claude Code reste Conditionnel dans notre répertoire : c'est un risque de configuration que vous pouvez fermer dès aujourd'hui, pas une raison d'abandonner l'outil.

Ce qui s'est passé

L'entreprise de sécurité Apiiro a publié une recherche sur le fichier de droits que Claude Code écrit. Elle est arrivée sur Hacker News le 7 novembre sous le titre « Claude Code's "Don't Ask Again" exposes passwords in 1,122 public GitHub files » (« Le "Don't Ask Again" de Claude Code expose des mots de passe dans 1 122 fichiers publics sur GitHub », notre traduction). Le site d'Apiiro a refusé nos requêtes (HTTP 403), donc nous n'avons pas pu vérifier sa méthode, ses autres chiffres ni ce qu'elle comptait comme un secret. La documentation des paramètres d'Anthropic confirme le mécanisme : lorsque vous choisissez « Yes, and don't ask again » pour une commande Bash, Claude Code enregistre cette approbation comme règle allow dans .claude/settings.local.json. Si la commande approuvée contenait un mot de passe ou un jeton, le secret se retrouve dans cette règle.

Pourquoi le fichier se retrouve dans Git

La première fois que Claude Code écrit le fichier, il ajoute **/.claude/settings.local.json à votre fichier d'exclusions git global, pas au .gitignore du dépôt. Un fichier d'exclusions global vit sur une seule machine, donc le dépôt lui-même ne porte aucune règle qui tienne le fichier à l'écart, et la documentation indique que si vous créez le fichier à la main, vous devez l'ajouter vous-même au .gitignore. Ne comptez pas sur un scanner de secrets comme dernier recours : un mot de passe dans une chaîne de commande peut ne pas correspondre aux formats de clés que les scanners recherchent.

Ce qu'Anthropic a dit

Boris Cherny, qui dirige Claude Code, a répondu dans le fil Hacker News le 7 novembre : « Historiquement, Claude Code n'a pas fait de nettoyage des secrets (il existe beaucoup de bons outils pour cela), mais nous étudions ce que nous pouvons faire pour l'empêcher. » (notre traduction) Dans le même commentaire, il a écrit que le fichier « est censé rester local », que Claude Code l'ajoute automatiquement au gitignore lorsqu'il le crée, « donc dans ce cas, les fichiers ont été créés manuellement et commités » (notre traduction). Il a aussi conseillé aux utilisateurs de passer en mode auto et d'activer la détection de secrets chez leur hébergeur Git. Ni l'entrée 2.1.319 (6 novembre) ni l'entrée 2.1.321 (9 novembre) du journal des modifications ne traitent le sujet. La 2.1.321 corrige bien un autre bug de secrets (des requêtes MCP OAuth envoyant des jetons de rafraîchissement à un autre hôte lors d'une redirection), qui n'est pas ce problème. Considérez le comportement comme actuel.

Ce qui change pour vous

FAQ

Mon secret est-il exposé si le fichier n'a jamais quitté ma machine ? Pas via GitHub. Le chemin d'exposition est le commit puis le push du fichier, donc vérifiez le statut Git et l'historique avant tout.

Un scanner de secrets le détectera-t-il ? Pas de façon fiable. Un mot de passe dans une commande approuvée peut ne pas correspondre aux formats recherchés par les scanners, donc cherchez directement dans le fichier.

Anthropic a-t-il publié un correctif ? Pas à la date de la version 2.1.321 du 9 novembre. Boris Cherny a déclaré que l'équipe « étudie ce que nous pouvons faire pour l'empêcher » (notre traduction).