Empêcher Claude Code de fuir des secrets vers GitHub

Vous approuvez une commande utile dans Claude Code et vous passez à autre chose. La commande vérifiait une base de données ou appelait une API, alors elle portait un mot de passe ou un jeton en texte clair. Des semaines plus tard, ce même projet va sur GitHub, et l’approbation que vous avez oubliée se trouve dans le dépôt pour que n’importe qui la lise.

C’est la fuite que ce tutoriel arrête. Comme nous l’avons signalé ce matin dans Claude Code Leak Exposes Passwords in 1,122 Repos, l’entreprise de sécurité Apiiro a trouvé 1 122 copies publiques de .claude/settings.local.json qui gardaient au moins un secret. Le fichier n’est pas un maliciel et aucun attaquant ne l’a mis là. Claude Code l’a mis là quand quelqu’un a choisi l’option de ne plus être interrogé.

Ce que vous allez construire ou apprendre

Vous terminerez avec un dépôt sûr à partager et sûr à continuer d’utiliser avec Claude Code. Le fichier de réglages local restera sur votre machine et hors de git. Aucune règle de permission enregistrée dans aucun des fichiers de réglages ne gardera une valeur secrète. Vos commandes renverront aux secrets par nom de variable, une numérisation locale vérifiera le nouveau travail, et GitHub bloquera une poussée qui porte un schéma de secret pris en charge.

Vous apprendrez aussi comment distinguer les deux fichiers de réglages, ce qui est la compétence qui empêche une répétition. Un fichier est à vous seul. L’autre est construit pour voyager.

La documentation des permissions pour Claude Code dit qu’une approbation Bash enregistrée avec l’option de ne plus demander va dans .claude/settings.local.json à la racine du dépôt git. La documentation des réglages dit que Claude Code ajoute ce fichier à votre fichier global d’exclusions git la première fois qu’il l’écrit dans un dépôt. Ce garde vit sur une machine. Il ne va jamais dans le fichier d’ignorance du dépôt, alors il ne voyage pas vers un nouveau clone, un coéquipier ou un exécuteur.

Avant de commencer

Lisez l’ordre avant de toucher un fichier. La rotation vient avant le nettoyage. Un secret qui s’est trouvé dans un dépôt public, ou dans l’historique git, doit être traité comme public même après que le fichier semble propre. Supprimer la copie actuelle ne retire pas les copies plus vieilles, les fourches ni les clones.

Sauvegardez les deux fichiers de réglages du projet hors du dépôt avant de les modifier. Gardez aussi cette sauvegarde hors de git. Ne collez jamais un vrai secret dans un rapport de bogue, un clavardage, une capture d’écran ou un journal partagé pendant votre vérification. Les commandes ci dessous sont construites pour montrer les noms de fichiers, les numéros de lignes et une sortie expurgée là où l’outil le prend en charge.

Vérifiez d’abord, faites tourner ensuite, nettoyez en troisième. Illustration générée par Dirty Static.

Étape 1 : vérifier les règles enregistrées dans les deux fichiers de réglages

Action : ouvrez .claude/settings.local.json et .claude/settings.json dans un éditeur et lisez chaque règle d’autorisation à l’œil. Lancez ensuite /permissions dans Claude Code. La documentation dit que ce dialogue liste toutes les règles de permission et le fichier de réglages d’où chaque règle vient, ce qui vous aide à repérer une règle que vous ne saviez pas avoir enregistrée.

grep -n "Bash(" .claude/settings.local.json
grep -n "Bash(" .claude/settings.json

Résultat attendu : les recherches listent les règles Bash enregistrées avec des numéros de lignes. Une règle sans caractère générique couvre une commande exacte. Si cette commande exacte garde un mot de passe, un jeton, un chemin de clé privée avec une valeur ou une adresse de base de données avec un mot de passe dedans, marquez cette valeur comme exposée si le fichier a déjà été poussé. Ne copiez la valeur nulle part de nouveau. Notez seulement le nom du service et le genre de secret, comme mot de passe de base de données ou jeton API, pour la liste de rotation à l’étape 3.

Étape 2 : vérifier si le fichier local est suivi et ignoré

Action : posez à git deux questions séparées. Le suivi et l’ignorance ne sont pas la même chose, et une règle d’ignorance ne fait rien pour un fichier déjà suivi.

git ls-files .claude/settings.local.json .claude/settings.json
git check-ignore -v .claude/settings.local.json
git status --short

Résultat attendu : git ls-files affiche le fichier local seulement si git le suit. Cet affichage est un problème, même si la deuxième commande trouve une règle d’ignorance. git check-ignore -v affiche le fichier d’ignorance et le schéma qui a correspondu quand le fichier est ignoré sur cette machine. Aucune sortie signifie que cette machine offrirait le fichier à un ajout normal. Notez de quel fichier d’ignorance la correspondance venait. Une correspondance de votre fichier global d’exclusions protège cette machine seulement.

Étape 3 : faire tourner d’abord si un secret a déjà été dans l’un ou l’autre fichier

Action : parcourez la liste de rotation de l’étape 1, plus tout secret que vous trouvez dans l’historique. Pour chaque valeur, allez au service qui l’a émise, révoquez ou changez l’ancienne valeur, émettez en une nouvelle, rangez la nouvelle dans votre magasin de secrets, mettez à jour l’endroit d’où l’application la lit et testez l’application une fois.

git log --all --oneline -- .claude/settings.local.json .claude/settings.json

Résultat attendu : le journal liste chaque consignation qui a touché l’un ou l’autre fichier de réglages. Si une consignation listée a atteint un distant public, traitez chaque secret dans cette version comme exposé, même si le fichier actuel est propre. Apiiro a compté des centaines de secrets supplémentaires dans les versions plus vieilles seulement. Pour un dépôt d’équipe, cherchez aussi dans l’organisation GitHub le nom du fichier local, parce qu’un clone de coéquipier peut avoir poussé une copie que vous n’avez jamais vue. La rotation est lente et ennuyeuse. C’est aussi la seule étape qui rend une valeur exposée inutile pour quiconque l’a copiée.

Étape 4 : retirer le fichier local du suivi et l’ignorer dans le dépôt lui même

Action : retirez le fichier local de l’index git seulement, pour que la copie sur le disque reste en place. Ajoutez ensuite son schéma au fichier d’ignorance du dépôt, pour que la règle voyage avec le projet. Utilisez la forme de schéma que la documentation Claude Code utilise pour l’entrée des exclusions globales.

git rm --cached .claude/settings.local.json
echo '**/.claude/settings.local.json' >> .gitignore
git add .gitignore
git status --short
ls -l .claude/settings.local.json

Résultat attendu : le statut montre le fichier local comme supprimé de l’index et le fichier d’ignorance comme changé, alors que la dernière commande prouve que le fichier local existe encore sur le disque pour que Claude Code l’utilise. Consignez le changement d’ignorance et le retrait d’index ensemble, avec un message qui dit ce que vous avez fait et pourquoi. À partir de maintenant, un clone neuf a la règle d’ignorance même sur une machine où Claude Code n’a jamais fonctionné.

Étape 5 : réécrire les règles risquées comme schémas et déplacer les secrets dans des variables

Action : dans le dialogue /permissions, supprimez chaque règle d’autorisation qui garde une valeur secrète, dans les deux fichiers. Reconstruisez ensuite les approbations utiles sous une forme sûre. La documentation des permissions montre la forme. Une règle avec un caractère générique couvre une famille de commandes. Une règle sans caractère générique couvre une commande exacte, secret compris.

Chargez la valeur dans une variable d’environnement par votre gestionnaire de secrets ou votre gestionnaire de mots de passe, hors de tout fichier que vous consignez. Laissez ensuite Claude Code lancer la commande sous sa forme variable :

curl -H "Authorization: Bearer $EXAMPLE_API_TOKEN" https://api.example.com/check

Résultat attendu : si vous approuvez cette commande avec l’option de ne plus demander, le texte enregistré dans le fichier local nomme la variable. Il ne garde pas la valeur. Gardez les schémas étroits. Un schéma qui permet chaque appel curl est une porte plus large que ce dont la plupart des projets ont besoin.

Un autre garde appartient au fichier partagé, après un examen d’équipe. La documentation des réglages utilise un refus de lecture pour les fichiers d’environnement comme exemple, et les règles de refus dans un fichier de projet s’appliquent tout de suite. Ajoutez des règles comme celles ci à .claude/settings.json pour que l’outil de lecture refuse les fichiers secrets par défaut :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Résultat attendu : Claude Code refuse de lire ces fichiers avec son outil de lecture dans ce projet. Traitez ceci comme un garde, pas comme toute la correction. La correction est qu’aucune valeur secrète ne se trouve dans une commande, une règle ou un fichier suivi au départ.

Les numérisations locales et la protection des poussées sont la barrière. La rotation est ce que vous faites quand la barrière était ouverte. Illustration générée par Dirty Static.

Étape 6 : numériser les fichiers actuels et tout l’historique avec Gitleaks

Action : installez Gitleaks depuis son dépôt de projet. Sous macOS, le dépôt liste la voie Homebrew. Numérisez ensuite le dossier de réglages comme des fichiers simples, et numérisez le dépôt avec tout son historique git. Le dépôt documente trois modes de numérisation. Le mode git lit l’historique des consignations. Le mode dir lit les fichiers sur le disque.

brew install gitleaks
gitleaks dir --redact -v .claude/
gitleaks git --redact -v .

Résultat attendu : chaque numérisation affiche des résultats avec un fichier, une ligne et un nom de règle, avec les valeurs expurgées de la sortie. Retournez à l’étape 3 pour tout vrai résultat dans l’historique. Une numérisation propre n’est pas une preuve en soi. Apiiro a passé Gitleaks et TruffleHog sur les fichiers qui fuyaient et a trouvé 215 fichiers qu’aucun des deux outils n’a signalés, le plus souvent parce qu’un mot de passe simple dans une commande normale ne ressemble pas à un format de clé connu. Votre vérification à l’œil à l’étape 1 fait encore partie du système.

Étape 7 : ajouter un crochet de consignation pour que le prochain secret s’arrête tôt

Action : ajoutez Gitleaks par le cadre de crochets de consignation que son dépôt documente. Installez d’abord le cadre en suivant le guide d’installation à pre-commit.com, puis créez .pre-commit-config.yaml à la racine du dépôt avec le bloc tiré du dépôt Gitleaks :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

pre-commit autoupdate
pre-commit install
pre-commit run --all-files

Résultat attendu : le crochet s’installe dans ce clone et une exécution complète signale l’arbre actuel. Consignez le fichier de configuration pour que chaque coéquipier reçoive la même installation, et mettez la commande d’installation dans les notes d’installation du dépôt, parce que chaque clone a encore besoin que l’étape d’installation soit lancée une fois. Un crochet local peut être sauté par la personne qui fait la consignation, alors c’est un garde pour les erreurs honnêtes. L’étape suivante est le filet du côté serveur.

Étape 8 : activer la protection des poussées GitHub

Action : ouvrez le dépôt sur GitHub et allez à Settings, puis Advanced Security. La documentation GitHub dit que vous devez d’abord activer Secret Protection si elle n’est pas déjà en marche. Sous Secret Protection, à droite de Push Protection, choisissez Enable. La documentation liste les propriétaires de dépôt, les propriétaires d’organisation, les gestionnaires de sécurité et les utilisateurs avec le rôle administrateur comme les personnes qui peuvent faire cela.

Résultat attendu : GitHub bloque maintenant une poussée qui porte un schéma de secret pris en charge et soulève une alerte quand un contributeur contourne le blocage. La documentation GitHub décrit aussi une forme de compte personnel de protection des poussées qui garde vos poussées vers tout dépôt public. Activez la aussi si votre compte l’offre, parce que la fuite dans cette histoire commence sur un portable, pas sur un serveur. La protection des poussées couvre les schémas connus. Elle ne remplace pas l’habitude des variables de l’étape 5 pour les mots de passe simples.

Vérification

Parcourez cette liste en ordre. Chaque ligne doit tenir avant que vous déclariez le dépôt propre.

git ls-files .claude/settings.local.json
git check-ignore -v .claude/settings.local.json
git add .claude/settings.local.json
gitleaks git --redact .

La première commande n’affiche rien, alors le fichier local n’est pas suivi. La deuxième affiche votre fichier d’ignorance du dépôt comme la source de la correspondance, pas seulement votre fichier global d’exclusions. Une tentative d’ajout normale signale le fichier comme ignoré. Dans Claude Code, /permissions ne montre aucune règle qui garde une valeur secrète, et une approbation neuve pour une commande sûre sous forme variable enregistre une règle qui nomme la variable seulement. La numérisation de l’historique peut encore lister de vieux résultats pour des valeurs tournées. C’est attendu jusqu’à ce que votre équipe prenne un parti séparé sur l’historique. La rotation est ce qui vous protège entre temps.

Dépannage

Prochaines étapes

Faites la même vérification sur chaque dépôt où vous utilisez Claude Code, en commençant par les publics. Numérisez ensuite les autres dossiers de configuration d’agents que vous utilisez avec le même œil, parce que tout outil qui enregistre des approbations ou des transcriptions dans un dossier de projet peut porter le même risque. Ajoutez la numérisation de l’historique à vos vérifications de construction à un horaire, pour que les nouvelles règles et les nouvelles consignations soient vérifiées sans que personne ait à se souvenir de lancer une commande à la main.

L’habitude à garder est petite. Approuvez des schémas, pas des commandes exactes avec des valeurs. Renvoyez aux secrets par nom de variable. Laissez le fichier local rester local, dans le fichier d’ignorance du dépôt et pas seulement dans votre fichier global. Un clic d’approbation vous fera encore gagner du temps. Il ne publiera simplement pas vos mots de passe pendant qu’il le fait.

Faits vérifiés le 8 novembre 2026, par rapport à la documentation des permissions et des réglages de Claude Code, au dépôt du projet Gitleaks et à la documentation de protection des poussées de GitHub. Ce tutoriel suit les commandes documentées et les résultats de la recherche Apiiro liée ci dessous. Il ne prétend pas que la séquence complète a été exécutée sur un compte réel avec de vrais secrets.

Sources

• The leak, the counts, the scanner misses, and the rotate first order: Apiiro research, Coding agents leaking secrets on GitHub
• Where standing Bash approvals are saved, how wildcard rules work, and the /permissions dialog: Configure permissions, Claude Code documentation
• The local file, the shared file, the global excludes guard, and the hand created file warning: Settings, Claude Code documentation
• Scan modes, install routes, and the commit hook config: Gitleaks project repo
• Who can enable push protection and where the setting lives: Enabling push protection for your repository, GitHub Docs
• Body illustrations: generated for Dirty Static. Hero image: Dirty Static.