Claude Code et settings.local.json : auditer les règles « don't ask again » et renouveler les clés exposées

GitGuardian a recensé 5,343 secrets encore fonctionnels au moment de leur détection, tous présents dans des copies publiques d'un seul fichier de projet Claude Code, .claude/settings.local.json. Les identifiants y atterrissent parce que Claude Code demande une autorisation avant d'exécuter une commande shell, et l'une des réponses proposées, « Yes, and don't ask again » (« Oui, et ne plus demander »), écrit la commande approuvée dans ce fichier. GitGuardian et une seconde équipe de recherche, Apiiro, ont chacun publié des décomptes montrant un grand nombre d'identifiants, des mots de passe de bases de données aux jetons d'API, dans des copies publiques de ce seul fichier.

Si vous êtes engineering manager, responsable plateforme ou DevSecOps, ou CTO d'une équipe dont les développeurs utilisent Claude Code, ce guide vous donne une séquence opérationnelle : trouver chaque copie exposée, neutraliser les identifiants, nettoyer les dépôts et les artefacts, puis fermer les chemins par lesquels le fichier s'échappe.

Ce que « Yes, and don't ask again » écrit réellement sur le disque

Lorsqu'un développeur choisit « Yes, and don't ask again » pour une commande Bash, deux choses se produisent. D'après GitGuardian, Claude Code exécute la commande et écrit une règle d'autorisation dans .claude/settings.local.json, dans le dossier du projet, et cette règle n'est autre que la chaîne de commande elle-même, clé d'API comprise. Pensez aux commandes qu'un développeur approuve lors d'une journée de travail ordinaire : un appel PGPASSWORD=... psql vers une base de données de préproduction, une connexion sshpass -p '...' ssh, une session mysql -p... ou un curl portant un jeton bearer. Approuvez l'une d'elles de façon permanente et l'identifiant est enregistré avec la commande.

La documentation d'Anthropic le confirme. La documentation des paramètres indique que choisir « Yes, and don't ask again » pour une commande Bash enregistre cette approbation sous forme de règle d'autorisation dans settings.local.json. La documentation des permissions précise que les approbations permanentes sont écrites dans .claude/settings.local.json à la racine du dépôt git, résolue à travers les worktrees jusqu'au checkout principal.

Anthropic dispose d'un signalement public de ce comportement depuis août 2025.

L'ampleur de l'exposition : deux décomptes de recherche, lus côte à côte

Apiiro a publié ses travaux le 6 novembre 2026. L'équipe a constaté que 1,122 des 104,185 copies publiques du fichier sur GitHub contenaient au moins un secret. Ces fichiers renfermaient 1,379 secrets distincts, dont 379 mots de passe de bases de données, 43 identifiants SSH pour des serveurs publics et 23 clés AWS. Lorsque Apiiro a élargi la recherche aux anciennes versions du fichier, au fichier de paramètres partagé que les équipes commitent volontairement et aux transcriptions de conversations d'agents enregistrées, le total a atteint 2,539 secrets répartis sur 1,994 dépôts.

L'analyse de GitGuardian a relevé 31,088 secrets distincts dans .claude/settings.local.json sur GitHub public, répartis sur 23,276 dépôts, dont 5,343 encore fonctionnels au moment de la détection. Les secrets valides présents dans le seul settings.local.json comprennent 1,955 chaînes de connexion Postgres distinctes, 292 mots de passe SSH et 941 clés d'API Google. Selon notre lecture de cette répartition, une grande partie du risque actif se situe dans les bases de données et les serveurs, les comptes d'API tiers n'étant qu'une partie du tableau.

Les deux études diffèrent par leur périmètre, leur fenêtre temporelle et leur méthode de détection : lisez-les donc comme deux mesures distinctes d'un même problème. Les additionner reviendrait à compter deux fois, et aucune ne doit être considérée comme une correction de l'autre.

GitGuardian a également suivi la tendance. Les fuites mensuelles dans settings.local.json ont culminé à 12,535 occurrences en avril 2026 avant de tomber à 959 en octobre. GitGuardian affirme ne pas encore savoir ce qui a changé.

Pourquoi la protection intégrée et vos scanners passent à côté

Claude Code intègre bien une protection. Selon la documentation des paramètres, la première fois qu'il écrit le fichier dans un dépôt git qui ne l'ignore pas déjà, il ajoute **/.claude/settings.local.json au fichier d'exclusions git global de l'utilisateur. Cette entrée réside sur la machine du développeur et reste absente du .gitignore du projet. La note de recherche de la Cloud Security Alliance explique pourquoi cela ne suffit pas : une exclusion globale protège un développeur sur un poste de travail, et elle ne suit pas le dépôt vers le clone d'un collègue, un runner de CI, un nouvel ordinateur portable, une image de conteneur ou une archive npm.

La détection constitue la seconde faille. Dans le jeu de données d'Apiiro, gitleaks a signalé 564 des 1,122 fichiers concernés et TruffleHog en a signalé 643, mais aucun des deux outils n'a signalé 215 d'entre eux, principalement parce que les secrets étaient des mots de passe intégrés dans la syntaxe de commandes comme PGPASSWORD=, sshpass -p ou mysql -p. Les chiffres de GitGuardian vont dans le même sens. Les détecteurs génériques (mots de passe, chaînes à forte entropie, JWT, jetons bearer, paires nom d'utilisateur et mot de passe) ont produit 63% de toutes les occurrences dans settings.local.json : 44,755 sur 71,525.

Au-delà de GitHub : images Docker, paquets npm et CLAUDE.md

Le fichier ne reste pas dans git. GitGuardian a examiné des images publiques sur Docker Hub et y a trouvé 613 secrets distincts dans des fichiers de paramètres Claude Code, dont 99 valides au moment de la détection, répartis sur 543 dépôts d'images et 7,625 tags.

Ces nombres de tags montrent comment une seule erreur se multiplie. Un même jeton d'API Cloudflare valide apparaissait dans 559 tags d'une seule image, et un mot de passe de base de données figurait dans 643 tags répartis sur sept dépôts d'images. Selon GitGuardian, supprimer le fichier du dépôt ne change rien pour les images déjà publiées.

Les registres de paquets présentent le même risque. Une étude de Check Point, citée dans la note de la CSA, a recensé 428 paquets npm publics livrant un fichier .claude/settings.local.json, et 33 de ces fichiers, répartis sur 30 paquets, contenaient des identifiants. L'audit doit aussi aller au-delà des fichiers de paramètres. GitGuardian a constaté que les fichiers CLAUDE.md contenaient 6,155 secrets distincts, dont 2,537 valides, soit le taux de validité le plus élevé de tous les fichiers examinés.

Le playbook Trouver, Neutraliser, Nettoyer, Verrouiller

L'ordre des étapes compte davantage que n'importe quelle commande prise isolément. Trouver couvre les étapes 1 à 3, Neutraliser correspond à l'étape 4, Nettoyer couvre les étapes 5 à 7, et Verrouiller désigne le travail de prévention décrit dans la section suivante. Neutraliser passe avant Nettoyer, car le nettoyage ne peut pas rappeler les copies qui existent déjà ailleurs : les forks et les images déjà publiées conservent le secret, quel que soit le soin apporté à la réécriture de l'historique, et seule la rotation rend ces copies inutilisables.

Étape 1 (Trouver) : inventaire

Listez chaque dépôt, registre de conteneurs et paquet publié que contrôle votre organisation, y compris les dépôts archivés, les miroirs internes et les forks personnels utilisés pour le travail. Tout ce qui manque à la liste ne sera pas nettoyé.

Étape 2 (Trouver) : explorer les arborescences actuelles et l'historique git complet

Recherchez .claude/settings.local.json, .claude/settings.json, CLAUDE.md et toute transcription d'agent exportée. Explorez l'historique complet en plus de la branche courante, car le décompte élargi d'Apiiro provenait d'anciennes versions du fichier, de fichiers de paramètres partagés et de transcriptions. Une recherche filtrée par chemin sur votre plateforme d'hébergement de code constitue une première passe rapide. Pour une passe dépôt par dépôt, nous suggérons une commande de ce type, qui recherche aussi les fichiers .jsonl au cas où les transcriptions de votre équipe auraient été enregistrées dans ce format :

git log --all --name-only --pretty=format: | grep -E '[.]claude/|CLAUDE[.]md|[.]jsonl$' | sort -u

Considérez ce résultat comme un point de départ pour les transcriptions. Celles enregistrées hors de git, ou sous d'autres noms de fichiers, nécessitent une recherche distincte.

Étape 3 (Trouver) : lire les fichiers, pas seulement la sortie des scanners

Ces fichiers sont assez courts pour qu'une personne les ouvre et lise directement les règles d'autorisation. Pour une recherche sur tout l'historique de dépôts volumineux, nous suggérons de passer les révisions à git grep une par une plutôt que toutes à la fois :

git rev-list --all | while read -r rev; do
  git grep -nE 'PGPASSWORD=|sshpass -p|mysql[^|]*[[:space:]]-p[^[:space:]]|Authorization: Bearer' "$rev" -- '*.json' '*.jsonl' '*.md'
done

Les équipes trouveront peut-être une boucle de ce genre lente sur de longs historiques, et ce type de recherche par motif tend à produire des faux positifs. Traitez chaque résultat comme un véritable identifiant jusqu'à ce qu'une personne confirme le contraire.

Étape 4 (Neutraliser) : renouveler ou révoquer chaque identifiant en premier

Selon GitHub, si la donnée sensible est un secret, la première étape consiste à le révoquer ou à en effectuer la rotation. Concrètement, cela signifie changer le mot de passe de la base de données, réémettre le jeton et remplacer l'identifiant SSH, puis vérifier que chaque ancienne valeur ne fonctionne plus. Tant que vous n'avez pas confirmé qu'un identifiant est inactif, considérez qu'il est actif.

Étape 5 (Nettoyer) : ne plus suivre les paramètres locaux et revoir les paramètres partagés

Cessez de suivre le fichier local et ajoutez la règle d'exclusion au .gitignore du projet lui-même, afin qu'elle accompagne chaque clone et chaque runner de CI :

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore
git commit -m "Stop tracking Claude Code local settings"

Nous suggérons aussi de demander à chaque développeur d'élaguer, dans sa propre copie locale du fichier, toutes les règles contenant des identifiants.

Étape 6 (Nettoyer) : réécrire l'historique, reconstruire les images, republier les paquets

Une fois la rotation confirmée, réécrivez l'historique là où c'est utile, reconstruisez les images concernées et republiez des versions propres des paquets, en acceptant qu'une part d'exposition subsiste. GitHub avertit que si le commit ayant introduit la donnée sensible existe dans des forks, il y restera accessible. Nous suggérons de considérer les anciennes versions de paquets comme toujours accessibles, sauf confirmation contraire.

Étape 7 (Nettoyer) : consigner ce que vous avez fait

Tenez un court journal d'incident. Pour chaque identifiant trouvé, notez son propriétaire, la date de rotation et toute exposition résiduelle impossible à supprimer, comme les forks, les images déjà téléchargées et les anciennes versions de paquets. Ce journal transforme un nettoyage ponctuel en quelque chose que les auditeurs et les futures équipes peuvent vérifier, et il vaut la peine de l'intégrer à votre runbook d'incident pour les agents afin que la prochaine fuite suive un chemin déjà connu de tous.

Checklist à remettre aux équipes

• [ ] Trouver : dépôts, registres et paquets listés, y compris les dépôts archivés et les forks
• [ ] Trouver : arborescences et historique complet explorés à la recherche des fichiers de paramètres, de CLAUDE.md et des fichiers .jsonl ; transcriptions hors de git recherchées séparément
• [ ] Trouver : fichiers lus par une personne, avec des vérifications personnalisées pour PGPASSWORD=, sshpass -p et mysql -p
• [ ] Neutraliser : chaque identifiant renouvelé ou révoqué, ancienne valeur confirmée inactive
• [ ] Nettoyer : settings.local.json retiré du suivi et ajouté au .gitignore du projet ; settings.json débarrassé des identifiants et relu dans les pull requests
• [ ] Nettoyer : historique réécrit là où c'est utile, images reconstruites, paquets republiés
• [ ] Nettoyer : journal d'incident complété, avec les forks et les anciennes versions de paquets listés comme exposition résiduelle
• [ ] Verrouiller : les mesures de prévention ci-dessous en place

Verrouiller : garder les secrets hors des commandes approuvées

La règle d'autorisation étant la chaîne de commande littérale, la prévention revient à garder les identifiants hors de cette chaîne.

• Utilisez des variables plutôt que des valeurs. Transmettez les identifiants via des variables d'environnement ou un gestionnaire de secrets, afin que la commande approuvée contienne un nom de variable plutôt que le secret. Définissez la variable en dehors de la commande approuvée, dans la session shell ou via un wrapper de gestionnaire de secrets, car un VAR=secret cmd en ligne écrit toujours le secret dans la règle d'autorisation. Avant : approuver PGPASSWORD=s3cret psql -h staging-db -U app enregistre le mot de passe. Après : avec PGPASSWORD déjà défini dans l'environnement, approuver psql -h staging-db -U app n'enregistre aucun secret. Pour une approche plus robuste, voyez comment un proxy d'identifiants garde les clés d'API hors des agents IA.
• Lisez avant de cliquer. Avant d'accorder une approbation permanente, nous suggérons de lire la commande exacte et, si elle contient un identifiant, de l'approuver une seule fois. La même habitude de lire avant d'approuver s'applique aussi aux approbations d'agents à distance.
• Commitez la règle d'exclusion et relisez le fichier. Placez .claude/settings.local.json dans le .gitignore de chaque projet au lieu de compter sur les exclusions globales, et élaguez régulièrement les règles dont les développeurs n'ont plus besoin.
• Bloquez-le en pre-commit et en CI. Rejetez les commits qui ajoutent le fichier de paramètres locaux, et signalez la syntaxe de commande porteuse d'identifiants que les scanners standards risquent de manquer.
• Fermez les chemins de packaging. Ajoutez les chemins .claude/ au .dockerignore, et utilisez une liste explicite de fichiers autorisés ou une liste d'exclusion pour les paquets npm afin que le fichier ne puisse pas être embarqué.

Ce qu'Anthropic a déclaré jusqu'ici

Le signalement de bug initial a connu un parcours inégal. La note de la CSA rapporte qu'il a été marqué « not planned » le 3 janvier 2026, sans réponse visible d'un mainteneur sur la page. Le signalement avait été déposé en août 2025, et les sources examinées ici n'expliquent pas l'écart entre ce dépôt et la date de clôture de janvier.

Anthropic a depuis réagi publiquement, sans toutefois livrer de correctif. Boris Cherny, responsable de Claude Code, a déclaré à iTnews : « Historiquement, Claude Code n'a pas fait de nettoyage des secrets (il existe de nombreux bons outils pour cela), mais nous étudions ce que nous pouvons faire pour éviter cela. » Sur Hacker News, Cherny a énuméré des approches possibles, notamment s'assurer que le mode auto détecte ce cas et intégrer une analyse de secrets de base. Il a indiqué que l'équipe prototyperait plusieurs d'entre elles pour en comprendre les compromis avant de livrer quoi que ce soit.

Réserves et limites de ces recommandations

• La validité est un instantané. Les 5,343 secrets valides de GitGuardian reflètent le moment de la détection. Certains ont peut-être été renouvelés depuis, d'autres non.
• La baisse reste inexpliquée. GitGuardian ne sait pas pourquoi les occurrences mensuelles ont diminué après avril 2026 : cette baisse ne prouve donc pas que le problème est résolu.
• Les dépôts privés sont hors périmètre. Les recherches portent sur des dépôts, images et paquets publics. Les dépôts privés présentent la même exposition partout où des fichiers sont partagés ou intégrés à des artefacts.
• Le comportement peut évoluer. Consultez de nouveau la documentation officielle de Claude Code sur les paramètres et les permissions avant de finaliser votre politique interne.
• Les commandes sont des points de départ. Les extraits de recherche ci-dessus sont des suggestions à adapter et à tester dans votre propre environnement, et non des outils de détection complets.