Claude Code enregistre les mots de passe dans un fichier après un clic sur « Ne plus demander » : 2 539 secrets ont fuité sur GitHub

Le bouton « Oui, ne plus demander » fait gagner quelques secondes, mais peut ensuite vous coûter vos clés cloud. Les chercheurs d’Apiiro ont découvert qu’après une telle confirmation, Claude Code inscrit l’intégralité de la commande autorisée dans son fichier de configuration. Si cette commande contenait des secrets, ils y restent stockés en clair.

Comment cela se produit

Imaginez que vous demandiez à l’agent de se connecter à une base de données. Il construit une commande telle que psql, avec le mot de passe directement intégré à la chaîne de connexion, ou lance curl avec un jeton dans l’en-tête. Claude Code demande votre autorisation, vous cliquez sur « Oui, ne plus demander » et, pour éviter de reposer la question à l’avenir, l’agent enregistre une règle d’autorisation dans .claude/settings.local.json. Cette règle contient littéralement la commande, mot de passe compris.

La distraction humaine ordinaire fait le reste. Le fichier se trouve dans le projet, le développeur exécute git add . puis git push, et le secret se retrouve dans un dépôt public. Le mot local dans le nom du fichier donne la fausse impression qu’il ne quittera jamais la machine, mais, en pratique, personne ne pense souvent à l’exclure de l’index.

L’ampleur du problème

Apiiro a découvert 2 539 secrets dans 1 994 dépôts. Parmi eux figuraient des mots de passe de bases de données, des accès SSH et des clés AWS. Il ne s’agit pas d’un scénario théorique, mais de fuites qui se sont déjà produites. Or les robots de collecte repèrent très rapidement ce type de données dans les dépôts publics.

Autre difficulté : supprimer le fichier dans le commit suivant ne résout rien. Git conserve l’intégralité de l’historique, et le secret reste accessible dans les anciens commits. La seule solution fiable consiste à considérer la clé comme compromise, à la révoquer immédiatement et à en générer une nouvelle. Nettoyer l’historique avec filter-repo est nécessaire, mais uniquement comme mesure complémentaire.

Ce qu’il faut faire immédiatement

• Vérifiez si vos dépôts contiennent .claude/settings.local.json et examinez ce qui y est enregistré.
• Ajoutez ce fichier à .gitignore, ou mieux encore au fichier gitignore global de votre machine.
• Activez des hooks pre-commit et des scanners de secrets comme gitleaks, ou la push protection de GitHub.
• Ne transmettez pas de secrets dans les commandes : utilisez des variables d’environnement, des gestionnaires de secrets et des profils AWS.
• Si le fichier a déjà été publié, remplacez sans attendre toutes les clés et tous les mots de passe qui y figurent.

Limites et conclusion

Le modèle n’a aucune intention malveillante dans cette affaire : il s’agit d’un défaut de conception d’une fonction pratique, dans laquelle l’autorisation est mémorisée sous la forme d’une ligne complète. Reste à savoir à quelle vitesse Anthropic modifiera ce comportement, par exemple en enregistrant un modèle de commande sans ses arguments ou en masquant les valeurs sensibles. Tant que ce changement n’a pas eu lieu, la responsabilité incombe à l’équipe.

Pour les équipes produit et les fondateurs, la leçon est plus large : tout outil doté d’une fonction « mémoriser mon choix » crée un nouvel artefact susceptible de contenir des données sensibles. Il faut l’intégrer au modèle de menaces au même titre que les journaux, les dumps et les fichiers .env. Nous accordons toujours plus d’accès aux agents, tandis que l’hygiène entourant leurs fichiers de configuration reste à la traîne. Consacrez dix minutes à un audit aujourd’hui, avant que quelqu’un d’autre ne le fasse à votre place.