Claude Code peut conserver des secrets dans ses règles de permission
Un rapport d’Apiiro montre comment une autorisation enregistrée par Claude Code peut conserver un secret. Plus de mille fichiers publics en contenaient selon l’enquête.
La société de sécurité Apiiro a trouvé des clés et des mots de passe dans des fichiers de permission de Claude Code publiés sur GitHub. Son rapport du 5 novembre 2026 décrit un mécanisme lié à l’approbation de commandes. Quand une commande contient déjà un secret, une règle enregistrée pour éviter de redemander l’autorisation peut conserver sa valeur. Le risque de divulgation apparaît si le fichier quitte ensuite l’environnement local.
Ce qui se retrouve dans le fichier de permission
Claude Code peut demander l’autorisation avant de lancer une commande. Lorsqu’une personne autorise la commande pour les prochaines fois, l’outil ajoute une règle d’autorisation à ses réglages. La documentation des réglages de Claude Code confirme le rôle du fichier local. Apiiro explique que la règle peut conserver le texte de la commande. Une valeur sensible déjà présente dans ce texte peut alors se retrouver en clair dans le fichier.
Le choix d’un modèle plus récent ne suffit donc pas à expliquer ce comportement. Le fichier relève du mécanisme de permission de Claude Code. Apiiro rapporte avoir reproduit l’enregistrement avec plusieurs modèles. Le problème dépend de la présence du secret dans la commande et du devenir du fichier qui la conserve.
Ce que les chercheurs ont compté sur GitHub
Apiiro a étudié 104 185 copies publiques du fichier de réglages local. Selon ses critères, 1 122 fichiers contenaient au moins un secret et réunissaient 1 379 valeurs distinctes. Ce comptage porte sur les fichiers étudiés. Il ne représente ni la part de tous les utilisateurs touchés ni le nombre d’accès confirmés à des systèmes.
Un identifiant exposé peut avoir déjà été désactivé
Les chercheurs ont cherché des formats de clés connus et des identifiants associés à des systèmes publics. Ils ont écarté plusieurs cas manifestement inactifs ou factices. Ils précisent qu’ils n’ont utilisé aucune des valeurs relevées pour accéder à un service. Le rapport présente donc un constat de présence dans les fichiers et non une vérification de leur validité actuelle. Un total plus large prend aussi en compte l’historique et d’autres types de fichiers. Il ne faut pas le confondre avec le chiffre des seules copies actuelles des réglages locaux.
Le rôle de Git et la réponse de l’équipe Claude Code
La documentation explique que Claude Code exclut normalement le fichier local de Git lorsqu’il le crée. Cette protection ne retire pas un fichier déjà suivi. Le rapport décrit aussi des cas où des copies ont subsisté dans l’historique ou dans des dépôts dérivés. Supprimer le fichier dans la version courante ne désactive donc pas le secret qu’il contenait.
Dans sa réponse publique sur Hacker News, Boris Cherny indique que l’équipe Claude Code étudie des moyens de prévenir ce problème. Il rappelle que le fichier doit rester local. La réponse ne confirme pas qu’un correctif a été déployé.
Pour une équipe qui utilise un agent de codage, le cas invite à inclure ses fichiers de réglages et leur historique dans les vérifications de publication. Si une valeur sensible a été publiée, la révoquer ou la remplacer traite le risque que la suppression du fichier laisse subsister. La question rejoint celle des informations que les agents d’OpenAI ont pu placer dans les noms de fichiers d’une évaluation. Les éléments qui entourent un livrable peuvent aussi transporter des données inattendues.