Claude Code reportedly sends user email in User-Agent header

Claude Code reportedly sends user email in User-Agent header

A bug report in the anthropics/claude-code GitHub repository, labeled as a bug on Nov 5, 2026, says Claude Code exposed the reporter's email address to third parties. The reporter writes that Claude Code "divulged my email to arbitrary 3rd parties in the User-Agent request header while conducting web searches without my permission", and says the result is "dozens of scam emails per day". That figure is the reporter's own account, not a measurement.

The reporter does not want a setting. The report says this "should not be a setting with opt-out or opt-in behavior" and "needs to be removed from the harness entirely". The argument: the behavior does nothing for services that dislike agentic traffic, does not preserve the user's anonymity on the web, and is "a goldmine for scammers". The reporter adds that the company is migrating to Pi with OpenRouter, having "no faith in anthropic preserving my privacy". The environment given is macOS (darwin), tmux, Claude Code version 2.1.318.

A reply in the thread, written by someone speaking for the Claude Code team ("We introduced"), says a built-in mod called cc-plugin-privacy was added "to deterministically block this behavior in v2.1.317 and later". The reply asks to be told as soon as possible if the mod's checks have a gap. It says the mod's source is not yet public and the author will try to publish it, as is done for the other built-in mods. The mod is enabled by default and can be turned off through /plugins.

Other commenters piled on. One says a very old, normally quiet email address suddenly started getting a flood of odd spam. Another says unusually specific emails about one of their projects started arriving. A third says they run Claude Code v2.1.318 without cc-plugin-privacy and that their logs confirmed their email was sent to other domains. One commenter says this never happened when using Claude models inside pi, and concludes the problem is in Claude Code itself.

Two technical follow-ups question the fix. One commenter asks why the model is handed the user's email address by default at all, and suggests the plugin is a bandaid: the problem could be solved, or greatly reduced, by not preloading the context with the email. Another reports that on macOS (arm64) the built-in mod does not refuse the case it is documented to refuse. The test command was an echo of a User-Agent line containing the signed-in account's address into /dev/null, which makes no network request. In the 2.1.318 run, the init event lists cc-plugin-privacy among loaded plugins and /plugins shows it as enabled and builtin, yet the input was not denied, even though the published source for the mod should match it. The commenter asks whether the shipped build differs from the published source, or whether something else is needed to activate the tool.check hook.

The visible thread has no reply to that follow-up, so it is unclear whether the mod works as described.

Key facts

  • A GitHub issue in anthropics/claude-code says Claude Code put the reporter's email address in the User-Agent header of web requests made during web searches; the reporter says they now get dozens of scam emails per day.
  • A reply speaking for the Claude Code team says a built-in mod, cc-plugin-privacy, blocks this behavior in v2.1.317 and later; it is on by default and can be turned off via /plugins.
  • Commenters report the problem persists on v2.1.318: one says logs confirmed their email went to other domains, another says the mod does not refuse the case it is documented to refuse on macOS (arm64).
  • The reply says the mod's source is not yet public; the author will try to publish it like the other built-in mods.
  • The reporter wants the behavior removed from the harness entirely, not offered as an opt-in or opt-out setting.

Why it matters

An email address in a User-Agent header is sent to every site a web search touches, so it reaches parties the user never chose. If the report is accurate, a coding agent would be handing out personal data as a side effect of ordinary work. The thread also raises a design question: one commenter asks why the model has the user's email in context by default, and another says privacy should be an invariant, not a plugin.

Who it affects

The reporter runs Claude Code 2.1.318 on macOS. Other commenters describe sudden spam on old or quiet addresses, and one says their logs show their email going to other domains on the same version. The source gives no number of affected users and no date when the User-Agent behavior was introduced.

How to use it

According to the reply, the built-in cc-plugin-privacy mod is enabled by default from v2.1.317 and can be switched off via /plugins, where one commenter saw it listed as enabled and builtin. One commenter who ran 2.1.318 without cc-plugin-privacy saw the email leave in logs, and another saw the mod fail a test command. Checking your own request logs, as that commenter did, is how the thread's reports were made. The reply asks users to report any gap in the mod's checks.

How solid is it

Mixed. The core claim comes from the reporter alone, and the source gives no evidence beyond the reporter's own statement that ties the scam emails to Claude Code. The reply does not confirm that the email address was actually leaked; it only says a mod was introduced to block this behavior. Still, one commenter says logs confirmed the email was sent to other domains, and the reply's description of a mod to block it points to the behavior being real. The mod's source is not yet public.

Risks and caveats

No Anthropic statement says what the email address was used for in the User-Agent header or why it was included. No fix or patched version is named for the case commenters say the mod does not catch, and Anthropic's answer to that follow-up is not in the source. The source does not say whether the issue was closed. Much of the thread is jokes and venting, and the spam anecdotes are self-reported and cannot be traced to one cause.

“Privacy shouldn't be a plugin. It should be an invariant.”

— a commenter in the GitHub issue thread