A Claude Code user opened a report on November 5, 2026 describing how Anthropic’s command-line tool sent the account’s email address in the User-Agent header of certain web requests triggered by the agent. A project contributor confirms a fix shipped in version 2.1.317, but several follow-up reports say it does not cover every case.
The report: an email address sent without consent
The report, filed as issue 107757 on the anthropics/claude-code GitHub repository, describes a User-Agent header containing the account’s email address during web searches run by the agent. The author flags a concrete risk: any outgoing request exposes the address to third-party sites, with a direct effect on spam and targeted phishing. The report asks for the behavior to be removed outright, with no opt-in toggle. The case echoes a recent episode at Postman, where AI agent plugins were installed without clear consent.
GET /search?q=... HTTP/1.1
Host: example.com
User-Agent: ClaudeCode/2.1.311 (contact: [email protected])Anthropic’s response: a privacy mod enabled by default
According to a comment left on the report, a built-in mod named cc-plugin-privacy was added in version 2.1.317 to block the email from being included in outgoing headers. It is enabled by default and can be disabled from the /plugins command. The same thread states that the address had been added to the model’s context to reduce name hallucinations, for instance in auto-generated @author tags, before sometimes being copied into the network header. Anthropic had already started formalizing governance over its agent tooling by handing certain standards to the Agentic AI Foundation.
Limits already observed
The mod does not cover every use case: several comments report it stays inactive when the agent writes and then runs its own network script, outside calls handled directly by the harness. One user reports that on version 2.1.318, a simple test containing a User-Agent header and an email address was not blocked despite the mod showing as active. Another says their address was indeed sent to third-party domains on that same version. An earlier comment links back to a similar report filed five months earlier, which stayed without a definitive fix until this new one. This is not the first security incident tied to the Claude Code ecosystem either: a trapped Claude Code extension on the Cursor Marketplace had already shipped with an SSH backdoor in late October.
| Date | Version | Event |
|---|---|---|
| Around June 2026 | — | First report (#81138) on a similar behavior |
| November 5, 2026 | 2.1.311 (stable) | Report #107757 opened |
| November 5, 2026 | 2.1.317 | cc-plugin-privacy mod added, enabled by default |
| After November 5, 2026 | 2.1.318 | Cases reported where the mod fails to block the leak |
The privacy mod added in version 2.1.317 is enabled by default, but does not cover network scripts the agent writes and runs itself.
The report remains open at the time of writing: no pull request is linked to it and the mod’s code has not been published separately. Teams running Claude Code from the command line should check their installed version and audit outgoing headers on their own scripts, rather than relying solely on the default mod.
What to remember
The incident illustrates a risk specific to coding agents: information added to the model’s context for one precise reason, avoiding a made-up author name, can resurface somewhere unexpected, here a network header visible to any site the agent contacts. The announced fix reduces default exposure, but user reports filed after the fix show it does not cover every execution path.
This kind of leak is a reminder not to place blind trust in the network headers an agent sends, Claude Code or a competitor alike: context supplied to the model for one task can end up copied somewhere else, with no malicious intent from the vendor. Until a more complete fix lands, watching an agent’s outgoing traffic on a sensitive project remains a reasonable precaution, on par with auditing a third-party extension. — Simon Janvier
