Un audit d'Apiiro montre comment une case d'approbation a transformé des commandes shell en règles permanentes, identifiants compris. Le fichier concerné, lui, voyage avec le projet.
Le bouton « Yes, and don't ask again » de Claude Code
Tout part d'une case que personne ne relit. Quand vous autorisez une commande shell dans Claude Code et que vous choisissez l'option qui promet de ne plus poser la question, l'agent enregistre la commande approuvée, telle quelle, comme règle d'autorisation dans .claude/settings.local.json.
Le problème tient à ce « telle quelle ». Si la commande contenait un mot de passe, un jeton ou une clé, l'identifiant reste dans la ligne sauvegardée. La commodité devient un stockage de secrets, sans que personne l'ait décidé.
Combien de commandes approuvées cachent un identifiant ? Le rapport ne le dit pas, et c'est justement ce qui rend le sujet désagréable.
Un détail de configuration.
Apiiro a publié ses travaux le 5 novembre, et le détail technique est court : la règle d'allowlist garde la commande entière, arguments compris. Rien dans le mécanisme ne distingue un npm install d'un sshpass -p ....
C'est ce dossier que la presse anglophone appelle le Claude Code secrets leak. Le nom est large pour un fichier de réglages. Il décrit pourtant bien ce qui s'est passé.
Ce que l'audit Apiiro Claude Code a compté
Les chercheurs ont regardé les copies publiques de ce fichier sur GitHub, et ils en ont trouvé 104 185, réparties sur 103 617 dépôts. Le fichier de réglages local finit donc régulièrement en ligne, sans que son auteur l'ait voulu.
Parmi ces copies, 1 122 contenaient des secrets, pour 1 379 identifiants distincts. Une copie sur cent environ charrie des clés ou des mots de passe, ce qui n'a rien d'anecdotique pour un fichier censé rester sur un poste de travail.
L'échantillon s'élargit ensuite aux réglages partagés, aux transcriptions d'agents et à l'historique git. Apiiro y trace 2 539 secrets distincts, dans 1 994 dépôts publics. Ces chiffres comptent des identifiants, pas des fichiers. La nuance compte quand on reprend l'étude.
63 organisations sont concernées, mais aucune n'est nommée dans le rapport.
Des Claude Code credentials recopiés par les fourches
Un dépôt public ne reste jamais seul. Les fourches recopient son contenu, y compris les fichiers que personne ne voulait partager.
Apiiro a suivi le trajet : des identifiants venus de 74 dépôts ont réapparu dans 211 copies supplémentaires. Une fourche ne nettoie rien, elle duplique.
L'historique aggrave le tableau. Les versions anciennes des fichiers contenaient 734 secrets qui ne figurent plus dans les copies actuelles. Supprimer la ligne ne suffit donc pas, et supprimer le fichier non plus.
Claude Code ajoute bien ce fichier à la liste d'exclusion git globale du développeur, à condition qu'il soit créé dans un dépôt. Cette protection ne suit pas le projet. Dès qu'un collègue clone le dépôt, la règle locale n'existe plus chez lui.
Le Claude Code secrets leak, catégorie par catégorie
Le mélange dit à quoi ressemble une fuite ordinaire. Des clés au format fournisseur, 636 au total, et 743 mots de passe ou jetons liés à des hôtes publics.
Type d'identifiant | Ce que le rapport relève |
|---|---|
Bases de données | 379 mots de passe |
Supabase | 122 clés service-role, 103 jetons de compte |
SSH | 43 identifiants, dont des connexions root dans des commandes sshpass |
Cloud | 23 clés AWS, six clés privées |
Les clés Supabase service-role méritent un mot : elles contournent les règles d'accès au niveau des lignes. Une clé de ce type dans un dépôt public ouvre la base entière, pas une seule table.
Ce que Gitleaks et TruffleHog ne voient pas
Les scanners de secrets ont fait leur travail, en partie. Gitleaks a signalé 564 des fichiers concernés et TruffleHog 643, mais 215 fichiers n'ont été signalés par aucun des deux. La raison est simple : un mot de passe écrit sous la forme PGPASSWORD=, sshpass -p ou mysql -p n'a pas de préfixe reconnaissable. Les détecteurs cherchent des formats, pas des contextes.
Ce point vaut pour les équipes qui comptent sur un scan automatique avant de publier, et pour celles qui pensent qu'un fichier de réglages local ne regarde personne d'autre que son auteur, alors que le scan attrape seulement les clés qui ressemblent à des clés.
Ce qu'une équipe doit faire cette semaine avec Claude Code
L'ordre des gestes compte plus que la liste. Apiiro recommande de changer les identifiants avant de supprimer quoi que ce soit, parce qu'un secret supprimé reste un secret valide.
Ensuite viennent le retrait du fichier du suivi git, l'ajout de règles d'exclusion propres au dépôt, la vérification des commits anciens, des réglages partagés et des transcriptions d'agents. La dernière étape remplace les valeurs en clair par des variables d'environnement adossées à un gestionnaire de secrets.
Un avertissement de méthode, enfin. Apiiro n'a pas testé les identifiants et n'a contacté aucun des hôtes concernés. Un seul organisme a confirmé qu'une clé exposée était encore active. Le reste est du matériel d'authentification crédible, pas la preuve qu'une connexion aurait abouti quelque part.
La leçon vaut pour tous les agents de code
Le fichier de réglages n'est pas un détail d'implémentation. C'est l'endroit où l'agent range ce qu'il a le droit de faire, et ce qu'il y range inclut parfois de quoi se connecter à vos systèmes.
Les autorités françaises, CNIL en tête, traitent les identifiants de connexion comme des données à protéger. Une clé d'accès à Scaleway ou à OVHcloud dans un fichier public vaut une clé AWS : le fournisseur change, l'exposition non.
Rien dans le rapport ne permet d'accuser un éditeur en particulier, et Anthropic n'a ni confirmé ni commenté les faits à notre connaissance. Le mécanisme, lui, se retrouve chez plusieurs agents : une case « ne plus demander » est une décision de stockage d'identifiants déguisée en préférence d'interface.
La prochaine fois que l'option apparaît, lisez la commande avant de cliquer. C'est elle qui sera enregistrée.
