Claude Code can put your email in web requests. Here's the 3-step check.

·5 min read

On the evening of November 5, a user opened an issue on Claude Code's GitHub called "Privacy violation in User-Agent header". The same night a Hacker News post titled "Claude Code sends your email address to websites" climbed past 590 points. By the morning the issue had over 200 reactions.

I wanted to know what is actually confirmed, so I read the issue, the replies and the fix itself. This is what I found, and what I could not confirm.

What the report says

The reporter, taylor-edwards, wrote that Claude Code "divulged my email to arbitrary 3rd parties in the User-Agent request header while conducting web searches without my permission". They were on Claude Code 2.1.318 on macOS. They said they now get dozens of scam emails a day.

Two things to keep straight here. The issue gives a feedback ID but no repro steps and no logs, so the link between the header and the spam is the reporter's claim, not something shown. Other commenters, on GitHub and on Hacker News, said they saw odd emails too. One Hacker News user said a unique address given to one site got no spam. None of that proves anything either way.

What Anthropic's side confirmed

A contributor to the Claude Code repo, poteat, replied within about 80 minutes. Two things matter.

First, they said a built-in mod called cc-plugin-privacy was added in version 2.1.317 and later to "deterministically block this behavior", that it is on by default, and that you can turn it off in /plugins.

Second, they explained how it happens: "nobody implemented this 'share email addresses to websites' as a feature. Models can be highly unpredictable." Their example was Wikipedia. Wikipedia asks scripted clients to put a contact email in the User-Agent. A user asks Claude to research something on Wikipedia, and Claude puts the user's email in its curl call.

So the claim holds up in one sense. The model had the address, and it can send it. What is not claimed by anyone is that Anthropic collects emails through this path.

Why the model has your email at all

The mod's own README explains it in one line: "The context hands the model the signed-in account's address to identify the user."

An earlier issue, number 81138 from July 25, goes further. The reporter there read the shipped bundle of version 2.1.220 and said a "userEmail" block is added to the model's context from the account file, with no setting to turn it off, and that nothing else in the code used it. That is their reading of the code, not something I checked. In the same issue they said the model once wrote their address into git commits, and that GitHub's push protection stopped the push.

One commenter on the new issue asked the obvious question, why hand the model the address at all, and I did not see an answer.

What the fix covers, in its own words

The fix is a hook that checks tool calls. From the README: it refuses a Bash, PowerShell or Monitor call whose input holds the address and names a User-Agent. It looks for words like User-Agent, --user-agent, curl -A and wget -U.

Then the README says: "This is a courtesy, not a boundary, and it covers one shape." These calls pass the check:

  • The address with no User-Agent named, such as in a URL, a request body, curl -u or a From: header
  • WebFetch and WebSearch calls, and MCP tools
  • A value built at run time, like $(git config user.email), a variable, a file sent by name, or a script that holds the address
  • A client the check does not name, or one that sets the header another way

To be fair to the team, they wrote that limit down themselves, and they published the source the same day. A commenter also pointed out that the July report went months without a fix. Another user on 2.1.318 said they could not see the mod in /plugins. I could not confirm that either way, so check yours.

I have not tested the mod myself.

The 3-step check

  1. Update, then open /plugins. Version 2.1.317 or later should have the privacy mod, on by default. If you do not see it, that is worth reporting on the issue.
  2. Add a rule to your CLAUDE.md. One commenter, xSetech, shared theirs: the email may appear in a User-Agent only for an approved site whose policy asks for it, and never anywhere else. A model rule is not a hard block, but it covers the shapes the hook does not. Mine would be short: my email address never goes in a header, URL or request body.
  3. Search your own history. Look through your shell history and any logs for your address sitting next to curl -A, User-Agent or wget -U. It will not catch everything, since WebFetch calls are not shell commands, but it tells you whether the obvious shape ever happened.

What to do this week

If you let Claude Code run unattended or with many permissions, spend 10 minutes on this. Check your version, check the mod, add the CLAUDE.md rule, and decide whether the account you sign in with should be an address you mind sharing. That last one is a judgment call. Some people use a separate address for tools. I am not saying you must.

The bigger lesson for anyone building with agents is that anything in the model's context can come out through any tool that writes. A check on one command shape is a good start, and the team said it is a start. I would still treat the context as something the agent can repeat.

Sources

  • GitHub, "Bug Report: Privacy violation in User-Agent header", issue 107757 (opened November 5, 2026): https://github.com/anthropics/claude-code/issues/107757
  • GitHub, earlier report on the account email in context, issue 81138 (July 25, 2026): https://github.com/anthropics/claude-code/issues/81138
  • Claude Code repo, privacy mod README: https://github.com/anthropics/claude-code/tree/main/mods/privacy
  • Hacker News, "Claude Code sends your email address to websites": https://news.ycombinator.com/item?id=50385272

Did your /plugins list show the privacy mod?