Apiiro a rapporté qu’une commande approuvée avec « Yes, and don’t ask again » peut être enregistrée dans .claude/settings.local.json. Si la commande contient un mot de passe ou un jeton et que le fichier est publié sur GitHub, l’identifiant peut se retrouver exposé. Dans une étude publiée le 5 novembre 2026, après une collecte menée du 1er au 3 novembre, Apiiro a signalé des secrets dans 1 122 des 104 185 copies publiques examinées.

Comment l’approbation peut enregistrer un secret

Commentaire en anglais de SavvyNik sur le mécanisme rapporté, l’historique Git et les pistes de remédiation

L’option « Yes, and don’t ask again » permet de mémoriser une commande autorisée. Selon le mécanisme décrit par Apiiro, si cette commande contient une valeur sensible écrite en clair, celle-ci peut être conservée avec la règle d’autorisation dans le fichier de configuration local du projet. La publication de ce fichier peut alors rendre cette valeur accessible dans un dépôt public.

Ce que comptent les chiffres d’Apiiro

Les 1 122 désignent des copies de .claude/settings.local.json contenant au moins un secret, et non le nombre total d’identifiants. Ces fichiers contenaient 1 379 secrets distincts. L’échantillon porte sur 104 185 copies publiques trouvées dans 103 617 dépôts GitHub; les fichiers ont été recueillis du 1er au 3 novembre 2026.

Apiiro a aussi rapporté un total plus large de 2 539 secrets dans 1 994 dépôts et 63 organisations. Ce décompte inclut l’historique Git et d’autres fichiers liés aux agents de programmation, en plus des fichiers de paramètres locaux. Il ne correspond donc pas au nombre de fichiers contenant des secrets dans le premier échantillon.

L’étude porte sur des données publiques de GitHub. Apiiro n’a pas testé les identifiants; une entreprise a confirmé qu’une clé était active.

Pourquoi supprimer le fichier ne suffit pas toujours

Apiiro décrit une exclusion Git globale configurée au niveau du poste du développeur. Cette règle ne s’ajoute pas automatiquement au .gitignore du dépôt, ne protège pas un fichier déjà suivi par Git et ne suit pas le projet lorsqu’il est partagé.

Si un fichier a déjà été publié, supprimer sa copie actuelle ne retire pas les versions antérieures de l’historique Git ni les copies conservées dans des forks ou des clones. La suppression du fichier et la révocation de l’identifiant sont donc deux opérations distinctes.

En cas d’exposition possible, révoquez ou renouvelez d’abord l’identifiant; le nettoyage du dépôt vient ensuite.

Les scanners peuvent aussi manquer des secrets

Dans la comparaison rapportée par Apiiro, 215 des 1 122 fichiers contenant des secrets n’ont été signalés ni par Gitleaks ni par TruffleHog. Les mots de passe intégrés à des commandes ou à des en-têtes de requête peuvent ne pas correspondre aux formats habituels de clés de fournisseurs. Un résultat négatif de ces outils ne remplace donc pas l’examen des commandes et des fichiers de configuration concernés.

Que faire en cas d’exposition possible

  1. Révoquez ou renouvelez les identifiants concernés. Retirer le fichier ne désactive pas une clé qui a pu être publiée.
  2. Recherchez le fichier dans le dépôt et son historique Git. Vérifiez aussi les copies et les forks concernés.
  3. Retirez le fichier du suivi Git, puis ajoutez une règle d’exclusion au .gitignore du dépôt afin que la protection accompagne le projet.
  4. Examinez .claude/settings.local.json et évitez d’inscrire des mots de passe ou des jetons en clair dans les commandes approuvées.