Claude Code a divulgué votre e-mail.

Votre a peut-être dit à des inconnus qui vous êtes. Le 5 novembre, un utilisateur de a signalé que l'agent avait placé l'e-mail de son compte dans l'en-tête User-Agent de requêtes web vers des sites tiers, et qu'il reçoit désormais des dizaines d'e-mails d'arnaque par jour. Personne ne l'avait demandé à l'agent. Il l'a fait de lui-même, comme une précision utile.

Ce qui s'est passé

Le signalement est l' #107757 du dépôt Claude Code, ouverte sur la version 2.1.318 et étiquetée area:security. Son auteur explique que l'e-mail est parti pendant que Claude Code lançait des recherches web sans sa permission. Les e-mails d'arnaque relèvent de son propre récit, pas d'une mesure. Mais un autre commentaire est plus difficile à écarter.

Un commentateur a demandé à son agent d'analyser ses propres journaux de session, chaque sous ~/.claude/projects/. L'agent a relevé 53 appels qui mettaient son e-mail dans un User-Agent, sur 8 sessions entre le 9 août et le 1er novembre. Presque tous venaient de sous-agents qui écrivaient eux-mêmes leur curl -A "<tool>/1.0 (<email>)", et non de l'outil de récupération web intégré. Pour cet utilisateur, ce n'était donc pas un bug rare. C'était une habitude, qui durait depuis des mois.

Pourquoi un agent fait cela

Cette habitude a une raison. Certains sites demandent aux clients automatisés de se présenter. La politique de Wikimedia demande aux robots un User-Agent descriptif avec des coordonnées, « an email address, a website, or a wiki user » (une adresse e-mail, un site web ou un compte wiki), et un en-tête générique comme curl peut recevoir une erreur 403. La SEC demande aux outils qui téléchargent les données EDGAR de déclarer un User-Agent, et son exemple associe un nom d'entreprise à l'e-mail d'un contact administrateur. Un modèle qui a lu ces règles, et qui connaît l'adresse de la personne connectée, comble le vide.

Mais pourquoi connaissait-il votre adresse ? Lydia Hallie, qui travaille sur Claude Code, l'a expliqué sur Hacker News : Claude inventait des noms pour des éléments comme les balises @author, alors l'e-mail du compte a été ajouté au contexte du modèle. Quand un site demandait un contact, Claude donnait parfois celui-là. Le même commentaire indique que l'adresse sortira du contexte du modèle dans la prochaine version, attendue en début de semaine prochaine.

C'est ce point qui, à mon sens, mérite qu'on s'y arrête. L'agent n'a pas été piraté, et il n'a rien fait qu'un auteur de script soigneux ne ferait pas. Il a simplement pris le mauvais contact, le vôtre, et l'a envoyé au site avec lequel il échangeait.

L'agent n'a pas été piraté. Il a été poli, avec votre adresse e-mail.

Ce que couvre le correctif, et ce qu'il ne couvre pas

Un contributeur de Claude Code a répondu dans l'issue : un mod intégré appelé cc-plugin-privacy bloque cela à partir de la v2.1.317. Il est activé par défaut et peut être désactivé dans /plugins. Le changelog de la 2.1.317 décrit « a check that asks before a web or shell tool call sends your account email address to the network » (une vérification qui demande votre accord avant qu'un appel d'outil web ou shell n'envoie l'e-mail de votre compte sur le réseau).

Lisez le du mod avant de vous rassurer. Il refuse les appels Bash, PowerShell ou Monitor qui contiennent l'adresse du compte et qui nomment aussi un User-Agent (User-Agent, curl -A, wget -U). Il se présente lui-même comme « a courtesy, not a boundary » (une courtoisie, pas une barrière), et il ne vérifie pas du tout les outils web, alors que le changelog dit qu'il demande votre accord avant un appel web. En pratique, il refuse les appels shell sans rien demander. Les URL, les corps de requête, les en-têtes From:, les outils de récupération et de recherche web, les outils et les valeurs qu'un script calcule à l'exécution passent tous. Le motif exact relevé dans les journaux est donc bloqué. Un script qui lit votre e-mail dans un fichier de configuration et l'envoie ne l'est pas.

Sur certaines machines, même le motif exact passe. Deux commentateurs ont testé le mod sur les versions 2.1.317 et 2.1.318, l'un sous macOS, l'autre sous Windows. Le mod était chargé, et un echo ou un curl -A contenant leur adresse s'est exécuté sans aucun refus.

Le README est honnête sur ses limites, et c'est ainsi qu'il faut lire tout garde-fou d'agent.

Un garde-fou qui repère deux mots est conçu pour le cas signalé, pas pour le suivant.

La leçon pour les équipes

Nous consacrons notre temps de revue au code que l'agent écrit dans le dépôt. Nous n'en consacrons presque aucun à ce qu'il envoie hors de la machine pendant qu'il travaille. Un curl dans une demande de permission paraît inoffensif, puisqu'il ne fait que lire une page. Mais c'est par l'en-tête que partent les données.

L'e-mail de votre compte n'est que le cas le plus bénin. Le même agent voit votre configuration Git, votre environnement et vos fichiers. Ce qui quitte l'ordinateur portable relève de l'équipe, pas de chaque développeur pris isolément.

Ce qu'il faut faire dès lundi

Vérifiez la version. Lancez claude --version sur chaque machine et passez à la 2.1.317 ou à une version plus récente. Le canal stable en était encore à la 2.1.311 quand Lydia Hallie a commenté : une équipe sur le canal stable n'a donc pas le mod du tout. Ouvrez ensuite /plugins et vérifiez que le mod de confidentialité est activé. Après la prochaine version, vérifiez encore : le correctif annoncé, c'est l'adresse qui sort du contexte du modèle.
Regardez votre propre historique. Faites comme le commentateur. Pour un premier tri approximatif, cette commande compte les endroits de vos journaux de session locaux où votre adresse se trouve à côté d'une option User-Agent (remplacez l'adresse) :

grep -rhoiE '(-A |-U |user.?agent).{0,120}you(@|%40)company\.com' ~/.claude/projects --include='*.jsonl' | sort | uniq -c

Donnez à l'agent un contact à utiliser. Quand un site en demande un, l'agent doit envoyer une adresse d'équipe partagée ou une page de contact, pas un identifiant de connexion. Une ligne dans votre CLAUDE.md ou votre AGENTS.md suffit.
Lisez les commandes réseau avant de les approuver. Regardez les en-têtes et l'URL, pas seulement le domaine. Évitez les règles générales « toujours autoriser » pour curl et wget.
Quand votre équipe en aura le temps, faites passer le trafic de l'agent par une liste d'autorisation en sortie (egress allowlist), pour qu'il puisse joindre votre registre de paquets et votre documentation, et rien d'autre par défaut.

Sources

, anthropics/claude-code, Bug Report: Privacy violation in User-Agent header #107757, 2026
Wikimedia Foundation, Wikimedia Foundation User-Agent Policy
U.S. SEC, Accessing EDGAR Data
Tin, Is Claude Code leaking your email in User-Agent headers?, novembre 2026
Hacker News, commentaire de Lydia Hallie, qui travaille sur Claude Code, novembre 2026
Anthropic, Claude Code CHANGELOG, 2026
Anthropic, mods/privacy README, 2026