Claude Code a laissé des secrets dans 1122 fichiers publics sur GitHub à cause de « Don't ask again »

Vous demandez à l’agent d’appeler une API. Il vous demande l’autorisation d’exécuter une commande et, lassé de cliquer sur « Yes » pour la dixième fois, vous choisissez « Don't ask again ». Pratique. Mais Qodo a découvert un effet secondaire de ce bouton : 1122 fichiers de configuration publics sur GitHub contenaient des secrets enregistrés par Claude Code lui-même.

Comment un secret se retrouve dans la configuration

Claude Code dispose d’un système d’autorisations. Lorsque vous acceptez qu’il ne vous demande plus confirmation pour une commande précise, l’agent ajoute une règle à un fichier de configuration dans le dossier .claude. Il existe un fichier partagé, settings.json, généralement commité avec le projet, et un fichier local, settings.local.json, destiné aux règles personnelles.

Le problème, c’est que la règle reprend littéralement la commande, avec tous ses arguments. Supposons que vous ayez demandé à l’agent d’envoyer une requête avec curl et inséré le jeton directement dans l’en-tête. L’agent mémorisera toute la ligne, et le jeton se retrouvera en clair dans le fichier. Il s’agit d’une illustration du mécanisme, pas d’une citation du rapport. Mais la logique est bien celle-ci : vous n’avez rien « enregistré », vous avez cliqué sur un bouton pratique.

La suite relève de l’inertie humaine habituelle. Quelqu’un commite tout le dossier .claude parce qu’il contient des « paramètres utiles pour l’équipe ». Le dépôt devient public, et le secret se retrouve à la vue de tous.

Pourquoi ce n’est pas un détail

Nous avons l’habitude de voir des secrets fuiter depuis des fichiers .env, des configurations cloud ou des chaînes inscrites en dur dans le code. Les fichiers de configuration des agents ne faisaient pas partie de ce paysage : on les considérait comme des « préférences personnelles de l’éditeur », au même titre qu’un thème visuel. Pourtant, ils contiennent déjà des autorisations d’exécution : ce que l’agent peut lancer sans poser de question. Le fichier remplit donc deux fonctions à la fois : politique de sécurité et réserve potentielle de secrets.

Un autre point est encore plus important. Ces fichiers sont écrits par un outil, pas par une personne, en réponse à un clic plutôt qu’à une décision délibérée d’« enregistrer la configuration ». Personne ne relit ce qu’il n’a pas écrit lui-même. D’où la conclusion de Qodo : la configuration d’un agent doit être revue comme du code.

Que faire dès maintenant

• Vérifiez vos dépôts. Recherchez dans .claude/ les chaînes qui ressemblent à des clés, des jetons et des mots de passe, y compris dans l’historique git. Supprimer le fichier du dernier commit ne suffit pas : l’historique reste accessible.
• Renouvelez tous les secrets trouvés. Si un jeton a figuré ne serait-ce qu’une fois dans un dépôt public, considérez-le comme compromis.
• Excluez le fichier local. settings.local.json doit figurer dans .gitignore. Ne supposez pas que quelqu’un s’en est déjà chargé.
• Retirez les secrets des commandes elles-mêmes. Transmettez-les via des variables d’environnement ou un gestionnaire de secrets : la règle contiendra alors le nom de la variable, pas sa valeur.
• Automatisez les contrôles. Installez un outil de détection de secrets en pre-commit et dans la CI, et activez aussi la protection des envois, ou push protection, sur GitHub. Ajoutez .claude à CODEOWNERS pour que les modifications des autorisations de l’agent soient systématiquement soumises à une revue.
• N’abusez pas de « Don't ask again ». Pour les commandes comportant des arguments sensibles, mieux vaut confirmer à chaque exécution ou écrire manuellement une règle strictement ciblée.

Limites et réserves

Le rapport a été publié par Qodo, un éditeur d’outils de revue de code. Le sujet est au cœur de son activité, et sa présentation s’en ressent. Par ailleurs, l’annonce ne précise pas combien des secrets trouvés étaient encore actifs. Enfin, les 1122 fichiers correspondent à ce qu’une recherche publique a permis de trouver, pas à un état des lieux exhaustif : les dépôts privés n’ont pas été comptabilisés.

Cela dit, le problème ne concerne pas un seul produit. Le même mécanisme de mémorisation des commandes existe dans d’autres outils agentiques, qui soulèvent les mêmes questions. Il serait raisonnable d’attendre des développeurs d’agents qu’ils masquent ou n’enregistrent pas les valeurs ressemblant à des secrets, et qu’ils avertissent l’utilisateur avant de les écrire dans un fichier.

Bilan

Les outils agentiques créent une nouvelle catégorie d’artefacts : des configurations qui s’écrivent toutes seules, s’exécutent avec vos droits et se retrouvent facilement dans git. Traitez-les comme du code : revue, détection de secrets, .gitignore. Cela coûte moins cher que de gérer les conséquences d’une fuite de clé.