Claude Code enregistre les jetons dans un fichier, et 1 122 dépôts les ont exposés publiquement

Une situation familière : l'agent demande l'autorisation de lancer une commande shell, vous en avez assez de confirmer sans cesse la même chose et vous cliquez sur « Yes, and don't ask again ». Claude Code mémorise ce choix et inscrit la commande dans le fichier .claude/settings.local.json à l'intérieur du projet. Le problème est que la commande est enregistrée telle quelle. Si vous avez appelé une API via curl avec un en-tête PRIVATE-TOKEN, le jeton se retrouve en clair dans ce fichier.

Pourquoi le fichier finit dans le dépôt

Pour que le fichier n'arrive pas dans git, Claude Code l'ajoute à l'exclude global personnel du développeur, et non au .gitignore du projet. Cette protection vit sur un seul ordinateur portable et n'est pas transmise avec le dépôt. Un collègue, un environnement CI ou un second ordinateur ignorent cette exclusion. git add . prend le fichier, qui part alors là où se trouve le dépôt.

L'ampleur du phénomène a été évaluée par la société Apiiro début novembre 2026. Dans les dépôts publics, 104 185 copies du fichier ont été trouvées, et 1 122 d'entre elles contenaient au moins un secret. Des centaines d'autres secrets ne subsistent que dans l'historique, dans des fichiers déjà supprimés. Supprimer le fichier n'annule pas la fuite : le jeton reste dans les anciens commits.

Le guide de GitLab s'adresse à ceux qui hébergent leur code chez eux, mais la logique s'applique à n'importe quel hébergeur git. GitLab affirme par ailleurs que ses propres secrets d'infrastructure sont protégés.

Comment combler la faille : quatre couches

Le groupe se configure une seule fois, puis la protection fonctionne d'elle-même. Les couches vont du plus simple au plus complexe.

1. .gitignore. L'option la moins coûteuse : la ligne .claude/settings.local.json dans chaque dépôt. Avec les offres Premium et Ultimate, on peut l'ajouter au .gitignore du projet modèle du groupe, et tous les nouveaux projets en hériteront automatiquement.

2. Règle de push (Premium et Ultimate). Dans les paramètres du groupe, dans la section des noms de fichiers interdits, on indique l'expression régulière (^|/)\\.claude/settings\\.local\\.json$. Tout push contenant ce fichier, à la racine ou dans un sous-dossier, sur n'importe quelle branche, sera rejeté, et le développeur verra un message avec le motif.

3. Secret Push Protection (Ultimate). Cette couche ne regarde pas le nom du fichier mais le contenu du push. Si un jeton d'un format connu est détecté, le push est rejeté. Cela protège aussi lorsque le secret a atterri dans un fichier portant un autre nom.

4. Politique d'analyse (Ultimate). Une politique au niveau supérieur du groupe lance Secret Detection dans chaque projet, même sans .gitlab-ci.yml, et les projets pris isolément ne peuvent pas la désactiver. Une règle se déclenche à chaque pipeline, l'autre selon un calendrier hebdomadaire. Avec la variable SECRET_DETECTION_HISTORIC_SCAN: 'true', la planification analyse tout l'historique, et non les seuls nouveaux commits.

Pièges à éviter

Les règles de push connaissent deux limites. Premièrement, elles ne vérifient que l'ajout de fichiers, et non les modifications de fichiers déjà suivis ; il faut donc d'abord supprimer les copies existantes. Deuxièmement, la règle de groupe n'est copiée que dans les projets créés après son apparition. Pour les anciens projets, il faut la définir séparément, par exemple via l'API : POST /api/v4/projects/<id>/push_rule avec le paramètre file_name_regex. Si le projet a déjà ses propres règles, utilisez PUT, sinon vous obtiendrez l'erreur 422 Project push rule exists.

Comment savoir si vous êtes concerné

Il faut d'abord dresser la liste des dépôts touchés. Il existe trois méthodes :

• GitLab Duo Agentic Chat. Vous demandez au chat de trouver tous les projets du groupe où ce fichier a existé, y compris les copies supprimées et les autres branches. Pour un groupe d'environ cent projets, cela prend quelques minutes. En revanche, il trouve ce que la recherche ne voit pas.
• Recherche de code (Premium et Ultimate). Rapide, mais elle ne voit que la branche par défaut dans son état actuel. La syntaxe dépend du moteur : pour l'exact code search, file:\\.claude/settings\\.local\\.json$ avec des expressions régulières ; pour l'advanced search, filename:settings.local.json path:.claude. Dans l'API, conservez exclude_forks=false, sinon les forks disparaissent des résultats.
• Commits API (toutes les offres). La requête repository/commits?path=.claude/settings.local.json&all=true pour chaque projet indique si le fichier a existé sur une branche quelconque. Une réponse vide signifie que le fichier n'a jamais existé. Les forks se vérifient comme les projets ordinaires.

Que faire en pratique

Commencez par une recherche dans l'historique, et non dans l'état actuel : les fichiers supprimés sont les plus dangereux, car on les oublie. Tout ce qui a été trouvé dans le fichier doit être considéré comme compromis et réémis, même si le dépôt est privé. Activez ensuite la protection : au minimum .gitignore et règle de push, et avec Ultimate, également l'analyse du contenu.

Une réflexion à part pour les équipes qui déploient des agents : le bouton « ne plus demander » transforme une autorisation ponctuelle en enregistrement permanent des commandes, et les secrets de ces commandes y atterrissent avec elles. Ne transmettez pas de jetons à l'agent en arguments de ligne de commande ; utilisez des variables d'environnement ou un gestionnaire de secrets, et la commande enregistrée sera sans danger.

Limite : dans le texte fourni, le guide s'interrompt avant la section sur le nettoyage en masse ; la procédure de nettoyage de l'historique est donc à consulter dans l'original.