Claude Code Leaked User Emails in Request Headers, Users Say

A bug report on the Claude Code repository has drawn attention to a quiet but serious privacy problem in AI coding agents. The reporter says the tool included their email address in the User-Agent header of outgoing web requests, and that they have since received dozens of scam emails per day. A maintainer responded in the same thread that a fix is already shipping.

What the report says

The issue, filed on the anthropics/claude-code repository and tagged as a macOS security bug, describes a simple chain of events. While Claude Code performed web searches during a session, requests to third-party sites allegedly carried the user's email address inside the User-Agent string. Any site receiving those requests could log it, and the reporter argues that is how their address ended up in scammers' hands.

The reporter's demand goes beyond a toggle. They argue the behavior should be removed from the harness entirely rather than offered as an opt-in or opt-out setting, saying it does not help services that dislike agentic traffic, does not protect anonymity, and is valuable mainly to spammers. They also say they are moving their company to Pi with OpenRouter as a result. It is worth noting that the causal link between the header and the spam is the reporter's own inference. The thread, as presented, does not include independent proof that the header was the source of the leak.

Anthropic's response

A contributor replied that a built-in mod called cc-plugin-privacy now deterministically blocks this behavior in v2.1.317 and later. It is enabled by default and can be switched off through the /plugins menu. The contributor asked users to report any gaps in the checks and said they would try to publish the mod's source, as is done for other built-in mods.

Two details stand out. First, the fix is a mod layered on top of the harness, not a removal of the underlying behavior, which is exactly what the reporter objected to. Second, the mod being on by default is the right call, but the existence of an off switch means the original criticism is only partly answered.

Why developers should care

User-Agent headers are a classic place for identifying data to leak. They are sent with nearly every HTTP request, they are routinely logged by servers, and they often end up in analytics tools and third-party log pipelines. Anything placed there should be assumed to be public to every site the agent touches.

Agentic tools make this worse because they act autonomously. A developer who types a prompt does not necessarily know which sites will be contacted or what metadata travels with each request. Web search and fetch tools expand the number of unknown recipients quickly.

A few practical takeaways:

• Update to v2.1.317 or later and confirm the privacy mod is active in /plugins.
• Route agent traffic through a proxy you control and inspect outbound headers, at least once, to see what your tools actually send.
• Treat account-linked identifiers in client metadata as a risk, especially when the same address is used for work and public sign-ups.
• Consider using a dedicated or aliased email address for tools that need an account identity.

What to watch next

The key open question is transparency. Publishing the source of the built-in mod would let the community verify what it blocks and whether it covers other request paths, such as fetch tools, MCP servers, or telemetry. The fact that this behavior was discovered by a user reading their own spam folder, rather than by documentation, suggests outbound request metadata deserves a clear public specification.

There is also the competitive angle. Open alternatives that let users see and control every request, such as agent harnesses paired with routers like OpenRouter, benefit whenever a closed tool is found doing something unexpected. For vendors, the lesson is straightforward: identity data should stay out of headers by default, and users should be able to audit that claim.