Claude Code : secrets dans settings.local.json

Pourquoi settings.local.json peut contenir vos secrets

Le fichier .claude/settings.local.json de Claude Code peut contenir des mots de passe et des jetons en clair. Quand vous répondez « Yes, and don't ask again » à une commande Bash, Claude Code y enregistre une règle allow tirée de cette commande. Si cette commande contenait un secret, il peut se retrouver dans le fichier, et le fichier peut se retrouver sur GitHub.

Ce guide explique où se trouve ce fichier et ce qui le protège. Il montre aussi les chemins qui passent à côté de cette protection. Ensuite, quatre commandes vous disent si un dépôt est touché. La réparation suit un ordre précis : on révoque d'abord chaque secret. La réécriture de l'historique git vient après, et elle reste facultative. Pour un développeur en France, la dernière question est juridique : une fuite de ce type est-elle une violation de données au sens du RGPD (règlement général sur la protection des données) ?

Le libellé « Yes, and don't ask again » est celui de la documentation anglaise. La page française des permissions le traduit par « Oui, ne pas demander à nouveau ». La référence complète des fichiers existe en français sur code.claude.com/docs/fr/settings et code.claude.com/docs/fr/permissions.

Les fichiers de réglages de Claude Code, et celui qui reste personnel

D'après la page settings lue le 9 novembre 2026, Claude Code lit ses réglages à plusieurs niveaux. Trois fichiers nous intéressent ici :

• ~/.claude/settings.json, le fichier utilisateur. Il s'applique à vous, dans tous les projets de cette machine.
• .claude/settings.json, le fichier partagé du projet. Il s'applique à tous ceux qui travaillent dans ce dossier. Dans un dépôt git, la doc conseille de le commiter pour que toute l'équipe en profite.
• .claude/settings.local.json, le fichier local du projet. Il ne s'applique qu'à vous, et seulement dans ce projet.

Voici l'ordre de priorité, du plus fort au plus faible : réglages gérés par l'organisation, ligne de commande, fichier local, fichier partagé, fichier utilisateur. Les listes comme permissions.allow ne s'écrasent pas d'un fichier à l'autre : elles se fusionnent. Une règle écrite dans le fichier local s'ajoute donc aux règles des autres fichiers.

Le fichier local est créé la première fois que vous donnez une approbation permanente à une demande de permission. Quelques options de /config, comme Show tips, y écrivent aussi.

Comment une approbation devient une règle allow

La page permissions décrit ce qui se passe quand vous choisissez « Yes, and don't ask again » pour une commande Bash. Claude Code enregistre une règle allow dans .claude/settings.local.json. Cette règle vaut pour les sessions futures, partout dans le dépôt. Pour Bash, la durée indiquée est « permanente, par dépôt et par commande ».

Pour une commande composée, comme git status && npm test, Claude Code n'enregistre pas la ligne entière. Il enregistre une règle par sous-commande qui demande une approbation, dans la limite de 5 règles. Les sous-commandes en lecture seule ne reçoivent pas de règle. Dans cet exemple, seule npm test est enregistrée.

La doc ne dit pas comment Claude Code traite, dans la règle, un préfixe comme PGPASSWORD=… placé devant psql. Ce qu'on sait vient du terrain. L'éditeur de sécurité Apiiro a trouvé dans ces fichiers publics des mots de passe de bases de données, des clés cloud, des jetons d'API et des identifiants SSH root. Les approbations de modification de fichiers ne sont pas enregistrées dans le fichier : elles durent jusqu'à la fin de la session.

Où Claude Code range settings.local.json depuis la v2.1.211

Depuis la version 2.1.211, publiée le 15 juillet 2026 d'après le journal des modifications, les règles « always allow » sont enregistrées à la racine du dépôt git. Dans un worktree, Claude Code utilise la racine du dépôt principal.

Avant cette version, le fichier était créé dans le dossier où la session avait démarré. Claude Code lit encore un fichier laissé à cet endroit par une ancienne version. Si les deux fichiers définissent la même clé, c'est la valeur du fichier racine qui l'emporte. En revanche, les règles de permission des deux fichiers s'appliquent toutes. Un vieux dépôt peut donc contenir plusieurs copies, par exemple backend/.claude/settings.local.json en plus de celle de la racine.

Dans quelques cas, le fichier reste à côté de .claude/settings.json au lieu d'aller à la racine : hors d'un dépôt git, quand la racine du dépôt est votre dossier personnel, sous Windows, ou quand la racine, son .git ou son .claude ne vous appartient pas.

L'exclusion git globale ne protège qu'une seule machine

Voici la protection actuelle telle que la doc la décrit. La première fois que Claude Code écrit le fichier dans un dépôt qui ne l'ignore pas encore, il ajoute la ligne **/.claude/settings.local.json à votre fichier d'exclusions git global. Ce fichier est :

• la valeur de core.excludesFile, si votre configuration git globale lui donne un chemin absolu ou un chemin qui commence par ~ ;
• sinon $XDG_CONFIG_HOME/git/ignore ;
• ou ~/.config/git/ignore quand XDG_CONFIG_HOME n'est pas défini.

La doc parle de ce fichier global, et pas du .gitignore du dépôt. La différence est importante. Le fichier global se trouve dans votre dossier personnel, sur votre machine, et il ne suit pas le dépôt. Selon la documentation de gitignore, c'est aussi la source la moins prioritaire : les fichiers .gitignore et .git/info/exclude passent avant lui. Surtout, la même page précise qu'un fichier déjà suivi par git échappe aux règles d'exclusion.

La doc de Claude Code ajoute une consigne simple. Si vous avez créé le fichier à la main et que Claude Code n'y a pas encore écrit, ajoutez-le vous-même au .gitignore.

Huit chemins qui contournent l'exclusion globale

L'exclusion globale ne couvre qu'un seul cas : un git add normal, sur la machine où Claude Code a écrit cette ligne. Voici les cas qu'elle ne couvre pas.

• Un fichier créé à la main ou par une ancienne version. Tant que Claude Code n'a écrit dans aucun dépôt sur cette machine, la ligne d'exclusion n'existe peut-être pas. L'entrée 2.1.211 du journal des modifications ne mentionne pas cette exclusion. Ne supposez donc pas qu'elle existait avant.
• git add -f. Cette option force l'ajout d'un fichier ignoré. Un git add -f .claude/ lancé pour commiter le fichier partagé embarque aussi le fichier local.
• Un clone sur une autre machine, ou en CI. Le dépôt cloné ne contient aucune exclusion pour ce fichier. Si quelqu'un le crée à la main sur cette machine, rien ne l'ignore.
• npm publish. La doc de npm ne cite que .npmignore et .gitignore. Si un .npmignore existe, le .gitignore n'est même pas lu. La liste des fichiers toujours exclus contient par exemple .git, .npmrc et node_modules, mais pas .claude.
• Une image Docker. La doc du contexte de build indique qu'un contexte local inclut tous ses sous-dossiers. Seul .dockerignore en retire des fichiers avant l'envoi au builder. La page ne parle pas de .gitignore.
• Un déploiement par rsync, scp ou tar vers la racine web d'un VPS. Ces outils copient l'arborescence que vous leur indiquez. Ce ne sont pas des outils git : ils ne connaissent vos exclusions que si vous leur passez vous-même des règles. Si le serveur web sert les chemins qui commencent par un point, le fichier devient téléchargeable.
• Un dépôt de dotfiles qui synchronise ~/.claude. Il publie ~/.claude/settings.json, le fichier utilisateur, qui contient vos règles pour tous les projets. Un éventuel ~/.claude/settings.local.json ne sert que dans les sessions lancées dans le dossier personnel lui-même, mais il est publié lui aussi.
• La carte d'approbation de l'extension VS Code. Elle vous laisse choisir le fichier de destination, y compris le fichier partagé du projet. La règle change alors pour toute l'équipe, et elle part dans un fichier fait pour être commité. Dans la CLI, Claude Code n'écrit que dans votre fichier local.

Deux points rassurants. D'abord, si .claude/settings.local.json est suivi par git, ou si .claude est un lien symbolique, Claude Code le considère comme fourni par le dépôt. Il met alors ses règles allow en attente jusqu'à ce que vous accordiez votre confiance au dossier. Un clone n'active donc pas ces règles à votre insu. Ensuite, une session cloud de Claude travaille sur un clone frais et ne lit pas le fichier local. Le vrai danger d'un fichier publié est donc le texte du secret lui-même, pas l'activation des règles.

Ce que disent Apiiro, Check Point et Anthropic

Apiiro a publié son étude le 5 novembre 2026. Du 1er au 3 novembre 2026, ses chercheurs ont interrogé la recherche de code et de commits de GitHub, en lecture seule, sur les branches par défaut. Ils ont téléchargé 104 185 fichiers .claude/settings.local.json répartis dans 103 617 dépôts. Parmi eux, 1 122 contenaient un vrai secret. Apiiro précise n'avoir utilisé ni testé aucun des identifiants trouvés. L'étude affirme aussi que Claude « a souvent commité le fichier lui-même ».

Boris Cherny, d'Anthropic, a répondu sur Hacker News le 7 novembre 2026. Selon lui, Claude Code n'a historiquement pas fait de nettoyage de secrets (« has not done secret scrubbing »). Il a aussi écrit que Claude Code ajoute le fichier aux exclusions git quand il le crée, et donc que les fichiers exposés ont été créés et commités à la main. Les deux versions se contredisent : attribuez chacune à sa source. Dans un second message, il évoque des pistes, comme faire en sorte que le mode auto repère ce cas ou ajouter une détection simple des secrets. Ce sont des pistes, pas une fonction disponible.

Le AI Security Report 2026 de Check Point donne un chiffre côté npm. Ses chercheurs ont examiné environ 46 500 paquets publiés et ont trouvé le fichier local, publié par erreur, dans 428 d'entre eux. Environ un sur 13 de ces fichiers contenait des identifiants valides : jetons npm, clés GitHub et Hugging Face.

Ce guide décrit le comportement documenté au 9 novembre 2026. Avant de vous fier à un détail, relisez le journal des modifications. Un correctif futur pourra changer la façon dont un secret arrive dans le fichier. Il n'effacera pas un secret déjà poussé.

Vérifier un dépôt en quatre questions

Le scénario ci-dessous se déroule dans un dépôt jetable, sous Ubuntu, avec git et jq. Le fichier contient un faux secret, facile à reconnaître. Une fois la méthode comprise, posez les mêmes questions à vos vrais dépôts.

Préparer un dépôt de test

sudo apt update && sudo apt install -y git jq
mkdir -p ~/demo-fuite && cd ~/demo-fuite
git init -q
git config user.name "Demo"
git config user.email "demo@example.com"
mkdir -p .claude
cat > .claude/settings.local.json <<'EOF'
{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(PGPASSWORD=FAUX-mdp-0000 psql -h db.example.com -U app)",
      "Bash(curl -H \"Authorization: Bearer FAUX-jeton-0000\" https://api.example.com/v1/me)"
    ]
  }
}
EOF
jq . .claude/settings.local.json
git add -f .claude/settings.local.json
git commit -qm "ajout des reglages (erreur volontaire)"

jq . doit afficher le JSON sans erreur. Une erreur parse error signifie que le fichier n'est pas du JSON valide. Le git add -f reproduit l'erreur réelle : il commite le fichier même si une règle d'exclusion le vise.

1. Le fichier est-il ignoré, et par quelle règle ?

git check-ignore -v --no-index .claude/settings.local.json
echo "code de sortie : $?"
git config --global --get core.excludesFile || echo "core.excludesFile non defini"
cat "${XDG_CONFIG_HOME:-$HOME/.config}/git/ignore" 2>/dev/null || echo "pas de fichier d'exclusions global par defaut"

Ici, l'option --no-index est indispensable. Sans elle, git n'affiche rien pour un fichier suivi, parce qu'un fichier suivi échappe aux règles d'exclusion. D'après la doc de git check-ignore, le code de sortie vaut 0 si une règle ignore le chemin, 1 si aucune règle ne s'applique, et 128 en cas d'erreur fatale. Avec -v, la ligne affichée indique le fichier qui contient la règle, le numéro de ligne et le motif. Si la règle vient de votre fichier global, le dépôt n'est protégé que sur cette machine.

2. Le fichier est-il suivi par git ?

git ls-files | grep 'settings\.local\.json$'
find . -path ./.git -prune -o -path ./node_modules -prune -o -name settings.local.json -print

git ls-files liste tous les fichiers suivis. Le grep ne garde que ceux dont le nom se termine par settings.local.json, à n'importe quelle profondeur, ce qui inclut les copies laissées par les anciennes versions. Si une ligne s'affiche, le fichier fait partie du dépôt et part à chaque git push. La commande find liste les copies présentes sur le disque, suivies ou non. Comparez les deux listes.

3. A-t-il déjà été commité ?

git log --all --name-only --format= | grep 'settings\.local\.json$' | sort -u
git log --all --full-history --format='%h %ad %s' --date=short -- .claude/settings.local.json

La première commande parcourt toutes les branches. Elle liste chaque chemin de ce nom modifié par un commit, même si le fichier n'est plus suivi aujourd'hui. D'après la doc de git log, la seconde ne garde que les commits qui modifient ce chemin, sur toutes les références. Lancez-la une fois pour chaque chemin trouvé par la première. Si la branche a été poussée sur un dépôt public, la date du premier commit marque le début de l'exposition. Cette date vous servira pour la question RGPD.

4. Quelles règles ressemblent à un secret ?

find . -path ./.git -prune -o -path '*/.claude/*' -name 'settings*.json' -print0 |
  while IFS= read -r -d '' f; do
    echo "== $f"
    jq -r '.permissions.allow[]?' "$f" |
      grep -Ei 'PGPASSWORD=|sshpass -p|authorization:|bearer |token=|api[_-]?key|secret|password' ||
      echo "   aucune regle suspecte"
  done

La boucle lit le fichier local et le fichier partagé, à toutes les profondeurs. jq affiche chaque règle allow sur une ligne. Le grep ne garde que celles qui contiennent un motif typique de secret. Cette liste de motifs n'est qu'un point de départ : ajoutez-y les noms de variables de vos propres outils. Faites aussi le test sur ~/.claude/settings.json, votre fichier utilisateur.

Retirer settings.local.json du dépôt et supprimer les mauvaises règles

Commencez par retirer le fichier de l'index, sans le supprimer du disque. Ajoutez ensuite la règle au .gitignore du dépôt, pour que chaque clone soit protégé.

git rm --cached .claude/settings.local.json
printf '%s\n' '**/.claude/settings.local.json' >> .gitignore
git add .gitignore
git commit -qm "ne plus suivre settings.local.json"
git ls-files | grep 'settings\.local\.json$' || echo "le fichier n'est plus suivi"
git check-ignore -v .claude/settings.local.json

D'après la doc de git rm, --cached retire le chemin de l'index uniquement. Le fichier reste dans votre dossier de travail. Un code de sortie 0 pour la dernière commande confirme qu'une règle ignore désormais le chemin. Vérifiez que la règle affichée vient bien du .gitignore du dépôt. Lancez un git rm --cached pour chaque copie imbriquée trouvée à la question 2.

Supprimez ensuite les règles qui contiennent un secret :

f=.claude/settings.local.json
jq '.permissions.allow |= map(select(test("PGPASSWORD=|sshpass -p|authorization:|bearer "; "i") | not))' "$f" > "$f.new" && mv "$f.new" "$f"
chmod 600 "$f"
jq -r '.permissions.allow[]' "$f"

Seule la règle Bash(npm run test *) doit rester. Le chmod 600 réserve la lecture à votre utilisateur (voir les modes chmod numériques et symboliques). Attention : le commit qui retire le fichier ne l'efface pas des commits précédents. Le secret reste dans l'historique, et dans toutes les copies faites avant.

Dans quel ordre réparer : révoquer chaque secret d'abord

L'ordre des étapes est la leçon principale de ce guide. Un secret publié est compromis, quoi que vous fassiez ensuite dans git.

1. Révoquez ou changez chaque identifiant que le fichier a contenu. Mot de passe de base de données, jeton d'API, clé SSH : chacun doit être remplacé auprès du service qui l'a émis. La doc de GitHub en fait la première étape.
2. Vérifiez les journaux du service sur toute la période d'exposition : connexions inattendues, adresses IP inconnues, requêtes inhabituelles.
3. Retirez le fichier du dépôt et ajoutez la ligne au .gitignore, comme plus haut.
4. Supprimez les règles qui contenaient un secret, dans tous les fichiers de réglages.
5. Réécrivez l'historique si vous le souhaitez. Cette étape est facultative, et elle ne remplace jamais l'étape 1.

Réécrire l'historique avec git-filter-repo, si vous le décidez

Le projet git recommande git-filter-repo plutôt que git filter-branch. Sa documentation le présente comme une opération destructive, à ne pas lancer à la légère. L'outil vérifie qu'il travaille sur un clone frais. Sinon, il refuse de continuer, sauf avec --force. Par défaut, il supprime aussi le remote origin. L'option --sensitive-data-removal demande une version récente de l'outil : le paquet git-filter-repo d'Ubuntu 24.04 la refuse avec l'erreur unrecognized arguments. Installez plutôt le script d'une version étiquetée, ici la v2.47.0, puis vérifiez que l'option est reconnue :

sudo apt install -y curl python3
sudo curl -fsSL -o /usr/local/bin/git-filter-repo https://raw.githubusercontent.com/newren/git-filter-repo/v2.47.0/git-filter-repo
sudo chmod 755 /usr/local/bin/git-filter-repo
hash -r
git-filter-repo -h | grep -F -- --sensitive-data-removal

Appelez bien le script sous la forme git-filter-repo -h. La forme git filter-repo --help passe par git help, qui cherche une page de manuel que cette installation ne fournit pas. Lancez ensuite la réécriture dans un clone neuf, jamais dans votre copie de travail :

git filter-repo --sensitive-data-removal --invert-paths --path .claude/settings.local.json

--invert-paths inverse la sélection : l'outil garde tout ce qui ne correspond pas au chemin donné. Ajoutez un --path pour chaque copie imbriquée trouvée à la question 2, et pour chaque autre chemin listé par la première commande de la question 3. Suivez ensuite la procédure de GitHub pour rétablir le remote et pousser l'historique réécrit.

N'oubliez pas les limites de cette opération. GitHub prévient qu'après une réécriture suivie d'un push forcé, les commits sensibles peuvent rester accessibles ailleurs. La réécriture n'atteint ni les clones déjà faits ni les forks. Elle ne touche pas non plus les archives npm déjà publiées, ni les images Docker déjà poussées. C'est pour cela que la révocation passe en premier.

RGPD : la fuite est-elle une violation de données à notifier à la CNIL ?

Un mot de passe qui fuit n'impose pas toujours une notification à la CNIL (Commission nationale de l'informatique et des libertés). La décision suit le texte, en trois étapes. Cette section présente le raisonnement. Pour un cas réel, faites l'analyse avec votre DPO (délégué à la protection des données).

Étape 1 : y a-t-il une violation de données personnelles ? L'article 4(12) du RGPD définit une « violation de données à caractère personnel » comme une violation de la sécurité qui entraîne, de manière accidentelle ou illicite, la destruction, la perte, l'altération ou la divulgation non autorisée de données personnelles, ou l'accès non autorisé à ces données. La page de la CNIL pose deux conditions. Il faut un traitement de données personnelles, et ces données doivent subir une perte de disponibilité, d'intégrité ou de confidentialité. Un jeton qui donne accès à une API météo ne touche aucune donnée personnelle. Un mot de passe qui ouvre la base clients d'une boutique en ligne, si.

Étape 2 : quel est le risque pour les personnes ? Reprenez la période d'exposition trouvée à la question 3. Le dépôt était-il public ? La base était-elle accessible depuis Internet, ou seulement depuis un réseau privé ? Les journaux de connexion montrent-ils un accès inconnu ? Quelles données contient la base : adresses e-mail, données de santé, coordonnées bancaires ? Si un identifiant publié sur un dépôt public ouvrait une base accessible depuis Internet, il est difficile de conclure à l'absence de risque quand vos journaux ne prouvent rien.

Étape 3 : notifier, ou seulement documenter. L'article 33(1) oblige le responsable du traitement à notifier la violation à l'autorité de contrôle dans les meilleurs délais et, si possible, au plus tard 72 heures après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes. La CNIL dit la même chose : la notification concerne une violation présentant un risque, et un incident sans risque pour la vie privée n'a pas à être notifié. Si vous n'avez pas toutes les informations à temps, la CNIL accepte une notification initiale dans les 72 heures, à compléter ensuite (article 33(4)).

Deux obligations s'y ajoutent. Dans tous les cas, vous devez documenter l'incident en interne (article 33(5)), même si vous ne le notifiez pas. En cas de risque élevé, vous devez aussi informer les personnes concernées. En cas de doute, la CNIL conseille de lui notifier la violation : elle vous dira alors s'il faut informer les personnes. La notification se fait par le téléservice de notification de violations de la CNIL, réservé aux responsables de traitement, organismes privés ou publics.

Changer d'habitudes pour ne plus écrire de secret dans une commande

La cause profonde est un secret écrit en clair dans une commande. C'est cette habitude qu'il faut corriger.

• Gardez les secrets hors des commandes. Placez-les dans des variables d'environnement définies avant de lancer Claude Code, ou dans un gestionnaire de secrets auto-hébergé. Une commande comme curl -H "Authorization: Bearer $API_TOKEN" … ne contient que le nom de la variable : le shell la remplace par sa valeur au moment de l'exécution. Le guide pour garder les secrets hors de portée d'un agent IA va plus loin.
• Approuvez des motifs plutôt que des commandes littérales. Une règle comme Bash(npm run test *) couvre toutes les variantes de vos tests. Dans la syntaxe, le joker est précédé d'une espace, et la forme :* n'est reconnue qu'à la fin d'un motif. Une règle écrite pour safe-cmd seule ne couvre pas safe-cmd && other-cmd.
• Bloquez la lecture des fichiers sensibles. Des règles deny comme Read(./.env) et Read(./.env.*) empêchent les outils de lecture de Claude d'ouvrir ces fichiers. D'après la doc, un fichier .claudeignore n'a aucun effet.
• Envisagez le mode auto. Il laisse Claude travailler sans les demandes de permission habituelles. Un modèle classificateur séparé examine les actions avant leur exécution. Lancez-le avec claude --permission-mode auto. Il est disponible sur toutes les offres, sous conditions de modèle et de fournisseur. Depuis la v2.1.283, c'est le mode de départ par défaut si votre compte remplit ces conditions. La doc prévient qu'il réduit le nombre de demandes mais ne garantit pas la sécurité. En mode auto, Claude Code désactive les règles larges comme Bash(*), mais les règles étroites restent actives : une règle littérale qui contient un secret s'applique donc toujours. Supprimez-la quand même. Les détails se trouvent dans le mode auto et les permissions de Claude Code.
• Ajoutez un scanner de secrets qui tourne avant chaque commit. Voici l'exemple que le README de gitleaks donne pour pre-commit :

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

Le README fixe rev: v8.24.2. Au 9 novembre 2026, la dernière version publiée de gitleaks est la v8.30.1 : choisissez une étiquette sur la page des versions et vérifiez qu'elle fournit bien le hook. pre-commit exige une référence fixe, c'est-à-dire une étiquette ou un SHA, et n'accepte pas de nom de branche. pre-commit install installe le hook git, et pre-commit run --all-files exécute tous les hooks sur l'ensemble du dépôt. Un hook ne contrôle que les nouveaux commits. Pour l'historique, lancez aussi une analyse complète avec la commande gitleaks git décrite dans le README.

Pour les deux voies de publication qui ne passent pas par git, ajoutez la ligne **/.claude/settings.local.json à .npmignore et à .dockerignore. Docker reconnaît ** pour un nombre quelconque de dossiers. Avant chaque publication, npm pack --dry-run montre ce que npm mettrait dans l'archive, sans rien modifier. Les attaques sur la chaîne d'approvisionnement npm montrent pourquoi un jeton npm publié est grave. Si Claude Code tourne sur un serveur, lisez aussi comment faire tourner Claude Code sans risque sur un VPS.

FAQ

Claude Code ajoute-t-il settings.local.json au .gitignore du dépôt ?

La doc décrit un autre fichier. La première fois que Claude Code écrit .claude/settings.local.json dans un dépôt qui ne l'ignore pas encore, il ajoute **/.claude/settings.local.json à votre fichier d'exclusions git global : core.excludesFile s'il est défini, sinon ~/.config/git/ignore. Ce fichier reste sur votre machine. Pour protéger chaque clone et chaque collègue, ajoutez vous-même la ligne au .gitignore du dépôt et commitez-la.

J'ai lancé git rm --cached. Mon secret est-il encore exposé ?

Oui. git rm --cached retire le fichier de l'index et des commits qui suivent. Les commits plus anciens le contiennent toujours, tout comme les clones, les forks et les paquets déjà publiés. Révoquez ou changez chaque identifiant que le fichier a contenu. Vous pouvez ensuite réécrire l'historique avec git-filter-repo, mais cela ne remplace pas la révocation.

Faut-il prévenir la CNIL si un mot de passe de base de données a fuité sur GitHub ?

Pas automatiquement. Il faut d'abord savoir si le mot de passe donnait accès à des données personnelles. Il faut ensuite évaluer le risque pour les personnes : dépôt public ou non, base accessible ou non, traces d'accès dans les journaux. S'il y a un risque, l'article 33 du RGPD impose de notifier la CNIL dans les meilleurs délais et, si possible, sous 72 heures. Sans risque, vous documentez l'incident en interne. En cas de risque élevé, vous devez aussi informer les personnes concernées.

Le mode auto empêche-t-il les secrets d'arriver dans settings.local.json ?

Il réduit le nombre de demandes de permission, et donc le nombre de règles que vous approuvez à la main. La doc précise qu'il ne garantit pas la sécurité. Les règles étroites déjà enregistrées restent actives en mode auto, y compris une règle littérale qui contient un mot de passe. Le 7 novembre 2026, sur Hacker News, Boris Cherny, d'Anthropic, a écrit que Claude Code n'a historiquement pas nettoyé les secrets, et il a évoqué des pistes à l'étude. Vérifiez le journal des modifications avant de compter sur une protection intégrée.