L'option « ne plus demander » de Claude Code a laissé des mots de passe dans 1 122 fichiers publics sur GitHub

Apiiro a indiqué le 5 novembre 2026 que cliquer sur « Yes, and don't ask again » dans Claude Code, l'assistant de code d'Anthropic, peut enregistrer un mot de passe ou une clé API, mot pour mot, dans un fichier de projet ensuite publié sur GitHub. The Hacker News et Cyber Security News ont repris ces résultats le 7 novembre 2026.

Apiiro a interrogé GitHub public entre le 1er et le 3 novembre 2026 et a trouvé 104 185 copies de .claude/settings.local.json dans 103 617 dépôts. Parmi elles, 1 122 (environ 1,1 %) contenaient au moins un « vrai secret » : une valeur au format d'une clé connue, ou un mot de passe ou un jeton à côté d'un hôte public. Ces fichiers regroupaient 1 379 secrets distincts. En ajoutant les versions plus anciennes, le .claude/settings.json partagé versionné volontairement et les journaux d'agents sauvegardés, le total monte à 2 539 secrets distincts dans 1 994 dépôts (Apiiro, The Hacker News).

Apiiro n'a testé aucun secret et n'a contacté aucun hôte : « vrai secret » désigne un identifiant qui a passé ses détecteurs et une revue indépendante, non un identifiant prouvé valide (Apiiro). Une organisation prévenue les 2 ou 3 novembre a confirmé que sa clé exposée était encore active (Apiiro, The Hacker News).

Comment un secret se retrouve dans le fichier

Par défaut, Claude Code demande l'autorisation avant d'exécuter la plupart des commandes shell. La documentation des réglages d'Anthropic indique que choisir « Yes, and don't ask again » sur une invite d'autorisation écrit une approbation permanente sous la forme d'une règle allow dans .claude/settings.local.json, à l'intérieur du projet.

La règle, c'est la commande elle-même. Si la commande proposée par Claude contenait déjà un mot de passe de base de données ou un jeton API, ce secret est enregistré en clair avec l'approbation (Apiiro, The Hacker News). Apiiro affirme qu'il s'agit du comportement de Claude Code, et non d'une particularité d'un modèle : les chercheurs l'ont reproduit avec Opus 5.5 et Fable 5.1 d'Anthropic (Apiiro).

Sur 16 agents de code comparés, Claude Code est le seul dont ils ont confirmé qu'il écrit par défaut la commande approuvée en entier dans un fichier du projet (Apiiro).

Une protection qui ne voyage pas avec le projet

Le fichier est censé rester sur une seule machine. Les docs d'Anthropic précisent que, la première fois que Claude Code l'écrit dans un dépôt git, il ajoute **/.claude/settings.local.json aux exclusions git globales du développeur, afin que le fichier reste hors des commits sur cet ordinateur. Si quelqu'un crée le fichier à la main, il lui est demandé de l'ajouter lui-même au .gitignore (documentation des réglages).

Le constat d'Apiiro est que cette protection vit dans les réglages git d'un utilisateur, sur un ordinateur. Elle n'entre pas dans le .gitignore du projet : elle ne suit donc pas le projet sur un autre clone, ne couvre pas un dossier qui devient un dépôt plus tard, et n'aide pas un fichier déjà commité (Apiiro, documentation des réglages).

Dans 539 des 1 105 dépôts contenant un secret que les chercheurs ont retracés, un commit indiquant Claude comme co-auteur avait modifié le fichier. Ils en déduisent que Claude commite souvent le fichier lui-même (Apiiro, The Hacker News).

Ce qui a été exposé

Apiiro indique que 63 organisations détiennent un vrai secret dans une liste d'autorisations publique, pour la plupart des entreprises de logiciel de toutes tailles. Parmi les cas les plus nets qu'elle décrit, chacun vérifié à un commit figé, figurent la clé cloud de niveau administrateur d'un éditeur de bases de données, un mot de passe Azure Postgres de production, un jeton Square de production, et le mot de passe propriétaire de la base d'une application de dossiers médicaux (Apiiro).

Plus d'un tiers des secrets présents dans les fichiers de réglages locaux actuels ouvrent directement une base de données, dont 379 mots de passe de bases et 122 clés de rôle de service Supabase. Les mêmes fichiers contenaient aussi 43 identifiants SSH vers des serveurs publics, 42 jetons GitHub, GitLab et npm, 23 clés AWS et 6 clés privées (Apiiro).

Les 1 122 fichiers contenant un secret étaient encore sur la branche par défaut de leur dépôt le 2 novembre 2026 ; dans le dépôt médian, le fichier avait d'abord été commité 217 jours plus tôt. Le supprimer ne suffit pas : l'historique git contenait 734 autres secrets dans 509 dépôts, et 211 forks de 74 dépôts portaient les mêmes secrets (Apiiro).

Les équipes versionnent aussi volontairement le .claude/settings.json partagé. Apiiro a trouvé des secrets dans 298 des 76 011 copies publiques de ce fichier, surtout dans des règles d'autorisation (Apiiro).

Pourquoi les scanners en manquent beaucoup

Les chercheurs ont passé gitleaks et TruffleHog sur les 104 185 fichiers, sans vérification. Sur les 1 122 fichiers contenant un secret, gitleaks en a signalé 564 et TruffleHog 643 ; 215 n'ont été vus par aucun des deux, souvent parce qu'un mot de passe dans une commande ressemble à un mot ordinaire, pas à une clé reconnaissable (Apiiro, The Hacker News). La plupart de ces fichiers n'atteignent jamais GitHub et restent du JSON en clair sur la machine ; ils peuvent aussi sortir dans un paquet, une image Docker, une archive ou un dossier synchronisé (Apiiro).

Des utilisateurs l'avaient déjà signalé

Des utilisateurs de Claude Code décrivent le même mécanisme sur GitHub depuis août 2025. Apiiro cite quatre signalements, dont la issue #5544, selon laquelle des commandes bash approuvées contenant des identifiants étaient stockées telles quelles dans settings.local.json. Les chercheurs, comme The Hacker News au 7 novembre 2026, indiquent qu'aucun de ces signalements n'a reçu de réponse d'Anthropic, et qu'une partie a été fermée automatiquement (Apiiro).

Ce que recommandent les chercheurs

Le conseil d'Apiiro à quiconque utilise Claude Code est de chercher, dans son organisation GitHub et dans l'historique git de chaque dépôt, les fichiers .claude/settings.local.json et .claude/settings.json. Si un fichier contient un identifiant, il faut d'abord renouveler ce mot de passe, ce jeton ou cette clé. Supprimer le fichier n'efface ni l'historique git, ni les forks, ni les clones des autres (Apiiro).

Ils recommandent aussi de retirer le fichier local du suivi git, de l'ajouter au .gitignore du projet, de supprimer toute règle d'autorisation qui contient encore un secret, de référencer les secrets par des variables plutôt que de les saisir dans les commandes, et d'approuver des motifs plutôt qu'une commande exacte (Apiiro, The Hacker News). Pour les équipes de sécurité, ils suggèrent de traiter les dossiers d'agents tels que .claude/, .cursor/, .gemini/ et .specstory/ comme porteurs de secrets, à l'image des fichiers .env, sur les ordinateurs portables comme dans les dépôts (Apiiro).

Pourquoi c'est important

Les agents de code sont désormais au milieu du travail quotidien : vérifier une base, appeler une API, lancer une migration. Un clic censé éviter une invite répétée peut écrire la commande entière — secret compris — dans un fichier facile à publier. L'écart documenté par Anthropic (une exclusion globale sur une machine, pas un .gitignore de projet) et les chiffres d'Apiiro montrent à quelle fréquence ce fichier a déjà quitté l'ordinateur. La réponse pratique, selon les chercheurs : chercher le fichier, renouveler tout ce qu'il a contenu, et cesser de placer des secrets dans les commandes qu'un agent peut mémoriser.