Claude Code enregistre les secrets des commandes approuvées en clair dans 1 122 dépôts GitHub publics

7 novembre 2026. Apiiro, éditeur de sécurité logicielle, publie une recherche sur une fuite de secrets massive et silencieuse. 1 122. C’est le nombre de copies publiques du fichier .claude/settings.local.json qui contiennent au moins un secret. 2 539. Le total de secrets recensés, en incluant les anciennes versions et les journaux d’agent. Pourquoi c’est important : quand un développeur répond « Oui, et ne plus demander » dans Claude Code, l’assistant sauvegarde la commande approuvée mot pour mot — mot de passe ou clé API compris — dans un fichier JSON du projet, et rien n’empêche ce fichier de partir sur GitHub.

Le mécanisme : un « ne plus demander » qui copie le secret

Par défaut, Claude Code demande confirmation avant d’exécuter la plupart des commandes shell. Quand l’utilisateur choisit « Yes, and don’t ask again », l’outil enregistre une règle d’autorisation dans .claude/settings.local.json, à la racine du projet. Les commandes correspondantes s’exécutent ensuite sans confirmation lors des sessions suivantes.

La règle ne couvre que ce que l’invite a proposé. Parfois c’est un motif — par exemple npm test *. Parfois c’est une commande exacte. Et quand c’est la commande exacte, tout mot de passe ou jeton tapé dedans est sauvegardé aussi, en clair.

Les chercheurs ont retrouvé dans les fichiers publics des commandes enregistrées avec le secret toujours présent à l’intérieur, et ont reproduit le comportement avec les modèles les plus récents, Opus 5.5 et Fable 5.1. Une entreprise prévenue par les chercheurs plus tôt dans la semaine a confirmé que sa clé était encore valide.

Claude Code tente d’écarter le fichier de git. La première fois qu’il l’écrit dans un dépôt, il l’ajoute aux exclusions git globales de l’utilisateur — sur cet ordinateur uniquement. Cette protection ne voyage pas avec le projet : le fichier n’est jamais ajouté au .gitignore du dépôt lui-même, et elle ne fait rien pour un fichier déjà committé. Dans 539 des 1 105 dépôts analysés, un commit signé par Claude comme co-auteur a modifié le fichier — signe que l’assistant committe parfois lui-même le fichier sensible.

Ce que les chercheurs ont trouvé

Le scan d’Apiiro sur GitHub public a trouvé 104 185 copies du fichier dans 103 617 dépôts. Environ 1,1 % d’entre elles — 1 122 copies — contiennent au moins un secret, soit 1 379 secrets distincts. Un secret était compté quand il correspondait à un format de clé connu ou qu’un mot de passe côtoyait l’adresse d’un serveur public, avec validation par un relecteur IA.

Plus d’un tiers des secrets ouvrent directement une base de données, dont 379 mots de passe de bases. Le reste se répartit entre 43 logins SSH vers des serveurs publics, 42 jetons GitHub, GitLab et npm, et 23 clés AWS. Parmi les propriétaires figurent 63 organisations, majoritairement des éditeurs de logiciels. Les cas les plus graves incluent une clé cloud de niveau administrateur d’un éditeur de base de données et le mot de passe propriétaire d’une base de dossiers médicaux.

Au lundi 2 novembre, chaque fichier contenant un secret se trouvait encore sur la branche par défaut de son dépôt, et dans la moitié des cas il y était depuis au moins 217 jours. Les anciennes versions en cachent 734 de plus, et 211 forks de 74 dépôts répliquent les mêmes secrets que les originaux.

La surface ne s’arrête pas au fichier local. En ajoutant le fichier partagé .claude/settings.json (committé volontairement par les équipes), les anciennes versions et les journaux de conversation d’agent, le total grimpe à 2 539 secrets sur 1 994 dépôts. Sur 16 agents de code dont la documentation a été comparée, Claude Code est le seul à sauvegarder par défaut la commande approuvée complète dans un fichier de projet.

Pourquoi les scanners classiques passent à côté

Le plus inquiétant n’est pas la présence du secret, c’est son invisibilité. Les chercheurs ont fait tourner gitleaks et TruffleHog sur chaque copie, sans l’étape de vérification. Sur les 1 122 fichiers contenant un secret, gitleaks en a signalé 564, TruffleHog 643 — et ni l’un ni l’autre n’en a signalé 215.

La cause est simple : la plupart des manqués sont des mots de passe tapés dans une commande. Les scanners cherchent des formats de clés connus, or un mot de passe après PGPASSWORD=, sshpass -p ou mysql -p ressemble à un mot ordinaire dans une ligne de commande ordinaire. C’est le talon d’Achille de la détection par motif, et c’est exactement le type de secret que ce fichier concentre.

La vulnérabilité avait pourtant été signalée. Un rapport de bug daté du 11 août 2025 décrivait déjà des commandes approuvées avec clés API et jetons stockées mot pour mot dans settings.local.json. Un bot l’a fermé comme « not planned » le 3 janvier, après 60 jours sans activité. Les quatre rapports connexes cités par les chercheurs ont tous été clos par le même bot, sans réponse d’Anthropic.

Ce qu’il faut faire — dans cet ordre

L’ordre des opérations est la partie critique du rapport, car supprimer le fichier ne répare rien : les anciennes versions restent dans l’historique git et dans les forks. La règle absolue est de faire tourner les identifiants d’abord, puis de nettoyer.

# 1. Retrouver le fichier, y compris dans l'historique (chaque dépôt, chaque branche)
git log --all -- .claude/settings.local.json .claude/settings.json

# 2. Sortir le fichier du suivi git sans supprimer le fichier local
git rm --cached .claude/settings.local.json

# 3. L'ajouter au .gitignore du PROJET (pas seulement aux exclusions globales)
echo ".claude/settings.local.json" >> .gitignore

Pour les développeurs, les chercheurs recommandent de garder les secrets hors des commandes — référencer une variable d’un gestionnaire de secrets, comme $DB_URL, pour que la règle enregistrée contienne le nom de la variable et non la valeur — et d’approuver des motifs (Bash(npm run:*)) plutôt que des commandes uniques. Même les copies qui n’atteignent jamais GitHub comptent : le fichier est du JSON en clair dans le dossier du projet, et peut se retrouver dans un paquet npm, une image Docker, une archive zip ou un dossier synchronisé.

Pour les équipes sécurité, la consigne est de traiter les dossiers d’agent — .claude/, .cursor/, .gemini/, .specstory/ — et les fichiers de mémoire d’agent comme des secrets, au même titre que .env, sur les postes comme dans les dépôts. Il faut les ajouter au scan de secrets en pre-commit et en CI, historique git compris, et s’assurer que le scanner détecte les mots de passe dans les commandes, pas seulement les formats de clés. Vérifier en priorité les identifiants associés à un serveur public : ce sont eux qui donnent accès.

Verdict

Ce n’est pas une faille d’Anthropic au sens classique — c’est un défaut de conception de la fonction « ne plus demander », combiné à une protection git qui ne voyage pas. Le fichier fait ce qu’on lui demande (mémoriser la commande), mais mémoriser la commande entière revient à mémoriser le secret, et la protection .gitignore reste clouée à une seule machine.

Si votre organisation utilise Claude Code, lancez ce soir une recherche de .claude/settings.local.json et .claude/settings.json sur tous vos dépôts — branches et historique compris — puis faites tourner tout identifiant que ces fichiers ont pu contenir, avant de nettoyer. La rotation d’abord n’est pas une précaution de confort : avec des fichiers en place depuis 217 jours en moyenne, le risque de compromission antérieure est réel. Si vous maintenez une politique de secrets, étendez-la explicitement aux dossiers d’agent et aux journaux de conversation — ils contiennent le même matériau que .env, mais personne ne les scanne. Si vous développez ou publiez un agent de code, ne persistez jamais la commande approuvée complète : persistez le motif, jamais la valeur.

Références

• Apiiro — « Claude Code’s “Don’t Ask Again” file exposes secrets in public repos » (6 novembre 2026)
• The Hacker News — « Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub » (Swati Khandelwal, 7 novembre 2026)
• Documentation Claude Code — permissions et règles d’autorisation (Anthropic)