Fuite de secrets dans Claude Code via « Yes, and don’t ask again »

Le 5 novembre, les chercheurs d’Apiiro Shmulik Cohen et Matan Giladi ont publié un rapport sur une fuite de secrets de Claude Code vers GitHub. Dans 104 185 copies publiques du fichier .claude/settings.local.json, ils ont trouvé 1 122 fichiers contenant au moins un secret, soit au total 1 379 mots de passe, clés d’API et jetons différents.

En quoi consiste la fuite de secrets de Claude Code ?

Quand Claude Code demande l’autorisation d’exécuter une commande dans le terminal, on peut choisir « Yes, and don’t ask again ». D’après la documentation de Claude Code, cette autorisation est enregistrée comme règle allow dans le fichier .claude/settings.local.json du projet.

Le problème, c’est que la règle enregistre toute la commande approuvée, avec tout ce qu’on y a tapé. Si la commande contenait un mot de passe, par exemple PGPASSWORD=… psql … ou un curl avec une clé d’API dans l’en-tête, ce mot de passe se retrouve en clair dans le fichier.

Fait intéressant, ce n’est pas une nouvelle découverte. En août 2025, quelqu’un a signalé exactement ce problème dans l’issue #5544 (avec des exemples de clés d’API et de jetons Jira). Un bot l’a fermée le 3 janvier 2026, après 60 jours sans activité, avec le statut « not planned » et sans correctif.

Si le fichier est local, comment s’est-il retrouvé sur GitHub ?

En principe, le fichier est privé. La première fois qu’il l’écrit, Claude Code ajoute **/.claude/settings.local.json au fichier d’exclusions global de git pour qu’il n’entre pas dans les commits (c’est ce que décrit la documentation).

Mais cette protection a plusieurs failles :

1. L’exclusion globale ne fonctionne que sur une seule machine et ne voyage pas avec le dépôt.
2. Si on a créé le fichier à la main, Claude Code ne l’exclut pas, et il faut l’ajouter soi-même au .gitignore.
3. Les règles d’exclusion ne s’appliquent pas aux fichiers déjà suivis par git : un fichier commité une fois continue d’entrer dans les commits suivants.
4. Supprimer le fichier du dépôt ne l’efface ni de l’historique ni des forks.

Selon iTWire, dans 539 des 1 105 dépôts examinés, le fichier a été modifié par des commits dont Claude était co-auteur.

Quelle est l’ampleur ?

Les chiffres du rapport (données collectées sur le GitHub public du 1er au 3 novembre) :

1. 104 185 copies publiques de settings.local.json, dont 1 122 (environ 1,1 %) contenaient au moins un secret.
2. Ces fichiers contenaient 1 379 valeurs différentes.
3. En ajoutant l’historique git, le fichier partagé .claude/settings.json et les conversations enregistrées avec l’agent, on arrive à 2 539 secrets dans 1 994 dépôts.
4. Apiiro a prévenu les entreprises les 2 et 3 novembre, et l’une d’elles a confirmé que la clé exposée était active.

Une réserve : Apiiro n’a pas vérifié si les identifiants trouvés fonctionnaient. Les candidats ont été triés avec des filtres anti-faux positifs et l’évaluation d’un modèle de langage, donc une partie d’entre eux était peut-être déjà périmée.

Pourquoi en parle-t-on autant ?

Samedi soir, le rapport est arrivé en première page de Hacker News. L’option « don’t ask again » sert à ce que l’agent ne repose pas sans cesse la même question, donc on oublie facilement ce qui a réellement été enregistré.

C’est aussi un exemple de plus montrant qu’aujourd’hui les secrets ne fuient pas seulement du code des applications, mais aussi des fichiers de configuration des agents (comme lors de la fuite d’OpenCode). Pour l’instant, les articles de presse ne mentionnent aucune réponse d’Anthropic.

À quoi faire attention à l’avenir ?

1. Révoquons et remplaçons d’abord tout mot de passe ou toute clé qui s’est un jour trouvé dans ce fichier dans un dépôt public. Ensuite seulement, nettoyons l’historique.
2. Vérifions si le fichier est suivi : git ls-files .claude. Si c’est le cas, arrêtons de le suivre (git rm --cached .claude/settings.local.json) et ajoutons-le au .gitignore du dépôt lui-même, pas seulement en global.
3. Passons aussi en revue l’historique (git log --all -- .claude/settings.local.json), le .claude/settings.json partagé et les conversations enregistrées avec l’agent.
4. Ne tapons pas de mots de passe directement dans les commandes. Mieux vaut les transmettre par des variables d’environnement ou un gestionnaire de secrets et, dans les règles allow, utiliser des motifs comme Bash(npm run test *) tiré de la documentation.

J’explique plus en détail comment tenir les clés d’API à l’écart des agents dans le guide sur la sécurité des agents IA, et les bases de l’outil sont dans le tutoriel Claude Code.

FAQ

Claude Code envoie-t-il lui-même mes mots de passe sur GitHub ?

Non. Le fichier settings.local.json reste sur notre disque. La fuite ne se produit que lorsque le fichier entre dans un commit puis dans un dépôt public.

Comment vérifier si mon settings.local.json est dans le dépôt ?

Il suffit de lancer git ls-files .claude dans le dossier du projet. Si settings.local.json apparaît dans la liste, git le suit. Il vaut aussi la peine d’ouvrir le fichier et de chercher des mots de passe, jetons et clés dans les règles allow.

Suffit-il de supprimer le fichier du dépôt ?

Non. Le fichier reste dans l’historique git et dans les forks, c’est pourquoi le plus important est de révoquer et de remplacer les identifiants exposés.