Le 7 novembre 2026, The Hacker News a rapporté qu’Apiiro avait repéré 1 122 copies publiques de .claude/settings.local.json contenant au moins un secret, parmi 104 185 copies examinées dans 103 617 dépôts GitHub. Apiiro a compté 1 379 secrets dans ces fichiers. L’entreprise n’a pas vérifié si la plupart étaient encore utilisables ; une société contactée a confirmé qu’une clé exposée avait été active.
Comment une commande peut conserver un secret
Le mécanisme rapporté concerne l’approbation persistante d’une commande shell exacte. Quand l’utilisateur choisit « Yes, and don’t ask again », Claude Code peut enregistrer cette commande comme règle d’autorisation dans .claude/settings.local.json. Si elle contient un mot de passe ou un jeton écrit en toutes lettres, cette valeur peut se retrouver en clair dans le fichier. Une règle fondée sur un motif ne contient pas nécessairement de secret littéral.
The Hacker News indique aussi que Claude Code ajoute le fichier aux exclusions Git globales de l’utilisateur lorsqu’il l’écrit pour la première fois dans un dépôt Git. Cette exclusion reste liée à la configuration Git de cette personne : elle ne suit pas le dépôt et ne retire pas une version déjà envoyée sur GitHub.
Deux périmètres derrière les chiffres
Les chiffres ci-dessous sont ceux d’Apiiro, rapportés par The Hacker News. Les 1 379 secrets concernent les copies publiques actuelles de settings.local.json. Le total élargi inclut aussi d’anciennes versions, des fichiers settings.json partagés et des journaux de conversation d’agents sauvegardés.
| Périmètre | Fichiers et dépôts concernés | Secrets rapportés |
Copies publiques actuelles de settings.local.json | 104 185 copies examinées dans 103 617 dépôts ; 1 122 copies contenaient au moins un secret | 1 379 |
| Corpus élargi | Anciennes versions, fichiers settings.json partagés et journaux de conversation d’agents sauvegardés ; 1 994 dépôts | 2 539 |
Parmi les catégories recensées figuraient 379 mots de passe de bases de données, 43 identifiants SSH pour des serveurs publics, 42 jetons pour GitHub, GitLab et npm réunis, ainsi que 23 clés AWS. Apiiro a aussi signalé 734 secrets dans d’anciennes versions réparties sur 509 dépôts et les mêmes secrets dans 211 forks de 74 dépôts.
Pourquoi supprimer le fichier ne suffit pas
Une suppression dans la version actuelle du projet n’efface pas les copies déjà présentes dans l’historique Git ou dans des forks. La présence d’une règle d’exclusion locale n’annule pas non plus un envoi antérieur.
Apiiro a également comparé deux outils de détection sur les 1 122 fichiers contenant des secrets. Ces analyses ont été effectuées sans l’étape de vérification des outils ; les résultats des deux scanners peuvent se recouper.
| Résultat du scan | Fichiers concernés | Condition |
| Signalés par gitleaks | 564 sur 1 122 | Analyse sans étape de vérification de l’outil |
| Signalés par TruffleHog | 643 sur 1 122 | Analyse sans étape de vérification de l’outil |
| Non signalés par l’un ou l’autre | 215 sur 1 122 | Analyse sans étape de vérification des outils |
Que faire si un secret a pu être publié
Apiiro recommande de commencer par repérer le fichier dans le projet et dans l’historique Git. Si un identifiant a pu être exposé, renouvelez-le avant le nettoyage. Ensuite, retirez le fichier du suivi Git, ajoutez-le au .gitignore du dépôt et supprimez les règles locales qui contiennent le secret. Examinez aussi l’historique et les forks : ils peuvent conserver d’autres copies.
Pour les commandes à venir, Apiiro recommande d’utiliser des variables provenant d’un gestionnaire de secrets plutôt que d’inscrire une valeur secrète directement dans la commande, et de privilégier des motifs d’autorisation plutôt que des commandes exactes. Un participant à une discussion Reddit a par ailleurs rappelé que des variables d’environnement peuvent rester accessibles à un processus qui dispose des droits nécessaires ; elles ne constituent donc pas, à elles seules, une garantie absolue.
Si un identifiant a pu entrer dans un dépôt public, renouvelez-le avant le nettoyage : supprimer le fichier courant ne purge ni l’historique ni les forks.
Bloquer la lecture des fichiers est un contrôle distinct
Un participant d’une discussion Reddit consacrée à Claude Code, citant sa documentation, indique que les chemins sensibles peuvent être bloqués par des règles deny pour l’outil Read et que .claudeignore ne contrôle pas l’accès des outils de fichiers. Ces règles concernent la lecture de fichiers ; elles ne retirent pas un secret déjà enregistré dans une commande ou dans l’historique Git.
