Claude Code : l'option « don't ask again » a exposé des secrets sur GitHub, comment vérifier tes dépôts

Ce que fait réellement « don't ask again »

Par défaut, Claude Code, l'agent de programmation d'Anthropic qui tourne dans ton terminal, demande la permission avant d'exécuter une commande shell. Si tu choisis « Yes, and don't ask again », la documentation des fichiers de réglages indique que l'approbation est enregistrée comme règle allow dans .claude/settings.local.json, à la racine du dépôt git. La commande ne te sera plus soumise dans les sessions suivantes.

Le problème tient au contenu de la règle. Quand l'invite propose un motif, comme toutes les commandes npm test, seul le motif est gardé. Quand elle propose une commande exacte, c'est la ligne entière qui est écrite en clair, y compris le mot de passe passé après PGPASSWORD= ou le jeton collé dans un curl. Le ticket n° 5544, ouvert le 11 août 2025, décrivait déjà des clés d'API et des jetons d'autorisation stockés « verbatim » dans la liste permissions.allow.

Anthropic a prévu un garde-fou, mais il est local. La documentation précise que, la première fois qu'il écrit le fichier dans un dépôt qui ne l'ignore pas déjà, Claude Code ajoute **/.claude/settings.local.json au fichier d'exclusion git global de ta machine. Rien n'est ajouté au .gitignore du projet. Et la documentation de git rappelle qu'un fichier déjà suivi n'est pas concerné par les règles d'exclusion. Si tu as créé le fichier à la main, si tu clones le dépôt sur un autre poste ou si le dossier devient un dépôt plus tard, la protection ne joue pas.

Ce qu'Apiiro a trouvé sur GitHub

L'éditeur de sécurité Apiiro, qui vend des outils de protection du développement, a recensé les copies publiques de ce fichier entre le 1er et le 3 novembre 2026. Sa publication n'a pas pu être consultée directement (page dynamique inaccessible) ; les chiffres ci-dessous sont ceux qu'en rapporte The Hacker News le 7 novembre 2026. Ce sont les chiffres d'Apiiro, sans réplication indépendante, et l'éditeur n'a testé aucun des secrets.

Source : reprise par The Hacker News de l'étude Apiiro, relevé du 10 novembre 2026.

Deux détails comptent pour toi. D'abord, dans 539 des 1 105 dépôts retracés, un commit cosigné par Claude modifiait le fichier, ce qu'Apiiro interprète comme le signe que l'agent le commite souvent lui-même, selon The Hacker News. Ensuite, sur 16 agents de programmation dont Apiiro a comparé la documentation, Claude Code serait le seul à enregistrer par défaut la commande complète dans un fichier du projet. Les deux affirmations sont celles de l'éditeur.

Pourquoi tes scanners peuvent passer à côté

Les outils comme gitleaks ou TruffleHog cherchent des formats de clés connus (préfixe d'un fournisseur, longueur typique). Un mot de passe écrit après mysql -p, sshpass -p ou PGPASSWORD= ressemble à un mot ordinaire dans une ligne de commande. C'est l'explication que donne Apiiro aux 215 fichiers non signalés, toujours selon The Hacker News. Un scan propre ne prouve donc pas que le fichier est sain : ouvre-le et lis-le.

Le même risque vaut pour tout dossier d'agent : Apiiro recommande de traiter .cursor/, .gemini/ ou .specstory/ comme des fichiers .env, d'après la même reprise. C'est la logique des contrôles de secrets que Cursor applique avant chaque publication d'appli. Les agents IA exécutent des commandes en ton nom ; ce qu'ils retiennent de ces commandes devient une donnée sensible. Il en va de même des conversations avec un assistant : en novembre 2026, des transcriptions de Notion AI ont été dérobées chez son sous-traitant Fireworks, avec les secrets que des utilisateurs y avaient collés.

Les tickets restés sans suite

Le ticket de 2025 n'est pas resté isolé. Le ticket n° 13106 du 4 décembre 2025 raconte une clé repérée par une alerte de sécurité après le push d'un settings.local.json vers un dépôt public ; un robot l'a fermé comme doublon le 8 décembre. Le ticket n° 24994 du 11 février 2026 décrit un fichier de 311 entrées après deux mois d'usage, avec des clés Stripe et des mots de passe Postgres ; il a été fermé de la même façon. Le ticket d'août 2025, lui, a été fermé automatiquement le 3 janvier 2026 après 60 jours d'inactivité.

Côté Anthropic, Boris Cherny, de l'équipe Claude Code, a écrit sur Hacker News que l'équipe « regarde ce qu'elle peut faire pour l'empêcher » (traduction Le Latent), d'après Ars Technica le 9 novembre 2026. Il conseille le mode automatique et les scanners de secrets, tout en reconnaissant qu'en mode automatique aussi, des commandes sensibles peuvent être enregistrées. Le 10 novembre 2026, le journal des modifications de Claude Code, arrivé à la version 2.1.322, ne mentionne aucun changement sur ce point ; ce n'est pas la première fois que des données sortent de l'outil, comme l'avait montré l'email du compte envoyé dans le User-Agent.

La marche à suivre pour un développeur indépendant

1. Cherche le fichier partout, historique compris. Dans chaque dépôt : git log --all -- .claude/settings.local.json .claude/settings.json. Sur GitHub, cherche ces deux chemins dans tes dépôts et ceux de tes clients.
2. Révoque avant de nettoyer. La documentation de GitHub est nette : un secret exposé se révoque ou se change en premier. Une fois révoqué, il ne donne plus accès ; réécrire l'historique avec git-filter-repo devient facultatif, et ne touche de toute façon ni les forks ni les clones existants.
3. Arrête de suivre le fichier. git rm --cached .claude/settings.local.json, puis ajoute .claude/settings.local.json au .gitignore du projet et commite ce .gitignore, pour que la protection voyage avec le dépôt.
4. Purge ton fichier local, même s'il n'a jamais été poussé : supprime chaque règle qui contient un secret. Le fichier peut aussi finir dans un paquet npm, une image Docker ou un dossier synchronisé.
5. Change de réflexe. Plus de secret tapé en clair dans une commande : passe par une variable ($DB_URL) chargée depuis ton gestionnaire de secrets, et approuve des motifs plutôt que des commandes exactes.

Si une clé exposée ouvrait une base contenant des données personnelles de tes clients et que tu constates un accès non autorisé, la CNIL rappelle que toute violation se documente en interne et qu'elle se notifie, si elle présente un risque pour les personnes, dans les 72 heures si possible après sa constatation (article 33 du RGPD). Pour un freelance, le responsable de traitement est souvent le client : préviens-le sans attendre. D'autres outils pour ton activité sont rassemblés dans la rubrique Freelances.

Ce qu'on ne sait pas encore

La date exacte de publication d'Apiiro diffère selon les reprises : le 5 novembre 2026 pour certaines, la veille du 7 novembre pour The Hacker News. Personne ne sait si les 1 379 secrets ont été utilisés ; une seule organisation prévenue a confirmé que sa clé était encore active. Enfin, Anthropic n'a annoncé ni date ni forme de correctif (masquage automatique, scanner intégré ou fichier déplacé hors du projet).