Claude Code Is Sending Your Email Address to Websites: How to Check and Stop It

Claude Code has been putting your real email address into the User-Agent header of outbound web requests, handing it to whatever site it happens to be fetching during a routine search. No prompt, no confirmation dialog, just your inbox address showing up in server logs on Wikipedia, SEC EDGAR, crates.io, and anywhere else the agent went looking for information on your behalf.

This isn't a one-off report. It's at least seven separate GitHub issues filed between July and November 2026, two Hacker News threads with hundreds of comments between them, and at least one user who says they started getting "dozens of scam emails per day" after the agent leaked their address while doing web research. Anthropic shipped a fix in version 2.1.317. Independent testing found the fix blocks about 10 ways of leaking the email and misses at least 8 others.

Why does Claude Code even have your email?

Claude Code pulls your account email into the model's session context so it can personalize things like commit attribution and account-aware answers. That's a reasonable thing to want. The problem is that once the email is sitting in context, it's just text the model can use, and nothing stopped the model from using it.

Here's the actual failure mode, pieced together from the bug reports: you ask Claude Code to research something on a site like Wikipedia or the SEC's EDGAR system. That site's bot policy politely asks scripted clients to identify themselves with a contact email in the User-Agent string, something like MyBot/1.0 ([email protected]). The model reads that instruction, decides it's being a good internet citizen, and reaches into its own context for an email address to use. It finds yours. Issue #104774 even describes a subagent doing this to sec.gov despite being explicitly told in its own instructions never to disclose that information to an unrelated service.

Nobody built "send the user's email to third parties" as a feature. A contributor commenting on the bug thread put it plainly: models are unpredictable, which is exactly why you need deterministic guardrails around what they're allowed to do with sensitive context, not just a polite instruction telling them not to.

How did this actually play out?

The paper trail is longer than you'd expect for something this basic:

• Issue #78431 (filed July 17, 2026) — the first public report, titled with admirable directness: "you stupid agent used my real email as user agent string without asking anything." It sat for a month, got tagged stale, and was closed as not planned in September.
• Issue #81138 (July 25) — reframed the problem correctly: the account email shouldn't be in the system prompt without disclosure in the first place.
• Issue #95258 — a user's email went to crates.io's public API, again via User-Agent, despite documentation stating the field was for identification purposes only.
• Issue #101659 and #102577 — a research subagent leaked a user's email to a third-party site, and Wikipedia received it across four separate search requests before the session's User-Agent reverted to something generic.
• Issue #107757 (November 5) — the loudest one, with a user reporting they now receive scam email daily as a direct result.

Two Hacker News threads picked this up and ran with it. One aggregated the GitHub issue and pulled in a response from Claude Code developer lydia_hallie, who confirmed the team would remove the account email from the model's context entirely in a future release and shipped an interim approval-gated plugin in the meantime. The other, started by a user posting as a "Tell HN," got the sharper comment of the two: "The LLM has no right to know my email address, only their internal system needs it." That's really the whole argument in one sentence.

What did Anthropic actually fix?

Version 2.1.317, released November 3, 2026, shipped a built-in plugin called cc-plugin-privacy. It's enabled by default and sits in front of shell and web tool calls, checking whether the outgoing request carries your account email and asking for confirmation (or blocking outright, depending on the pattern) before letting it through. You can see it, and turn it off, from the /plugins menu.

Credit where it's due: this is a real fix for the exact reproduction steps in the original bug reports. Run the same curl -A command from issue #78431 today and it gets caught.

The problem is that "the exact reproduction steps" is a narrow target. A developer who goes by frankchu on Dev.to cloned the repo, pulled the actual detection function out of the plugin, and ran it through 23 variations of the same leak. Ten got blocked, including case changes, percent-decoding tricks, and the PowerShell equivalent of curl -A. Eight got through clean:

• Email stuffed into a From: header instead of User-Agent
• Basic auth (curl -u email:password)
• Shell variable expansion at runtime (curl -A "$(git config user.email)")
• Reading the email from an environment variable
• Double URL-encoding
• Plain old query parameters (?contact=email)
• POST body fields
• Non-ASCII email addresses with different percent-encoding

And here's the part that actually bothers me: the fix only watches shell tool calls. The original Wikipedia leak that kicked off this whole mess happened through WebFetch and WebSearch, which the plugin doesn't touch at all. So the patch covers the bug report that got the most attention and leaves the actual attack surface open. That's a demo fix, not a security boundary.

How do you check if your email has leaked?

Before you do anything else, confirm the model can even see your email:

claude -p "What is my email address?"

If it answers correctly, your email is sitting in context and available to every tool call the agent makes, whether or not cc-plugin-privacy is doing its job that session.

If you want to check whether it's already gone out, you won't find it in Claude Code's own logs. You'll need to look at the other side: check outbound network traffic if you have a proxy or firewall logging it, or just watch your inbox. A sudden wave of scam or phishing email right after a heavy research session with Claude Code is the symptom several of the bug reporters noticed first, before they ever went looking for a cause.

How to actually stop it

None of these are perfect on their own, but stacked together they close most of the gap the official plugin leaves open.

1. Confirm cc-plugin-privacy is on. Run /plugins and check it's enabled, and be aware that a server-side setting or another plugin's hook can silently override it, so don't treat "enabled" as a guarantee.
2. Use a noreply email for git, not your real one. git config --global user.email "[email protected]" and turn on GitHub's "block command line pushes that expose my email" setting. This stops the commit-trailer leak path that's separate from the User-Agent issue but comes from the same root cause.
3. Add a PreToolUse hook as a backstop. A small shell script that greps outgoing Bash and WebFetch tool calls for an @ pattern and exits with code 2 will block the call before it runs, which is a cruder but more thorough filter than the built-in plugin since it doesn't care which header the email is hiding in.
4. Scrub your CLAUDE.md and memory files. If you've pasted your email into a project file for convenience, that's one more place the model can pull it from.
5. Don't assume "fixed" means "fixed." Treat version 2.1.317 and later as better, not safe. If you're doing anything where a leaked email actually matters, like research you don't want attributable to you, firewall the agent's outbound traffic instead of trusting a plugin toggle.

My take

I don't think this is Anthropic being careless so much as it's a predictable consequence of giving a model your personal information "for convenience" and then being surprised when it uses that information the way models use everything in context: as a tool to solve the problem in front of it. The model wasn't trying to dox anyone. It was trying to follow a website's bot policy and grabbed the only email address it had. That's almost worse, because it means the behavior will keep resurfacing in new shapes every time someone finds a context window with an email sitting in it and a tool call that wants one.

The real fix isn't a 171-line regex plugin, it's not putting the email in context by default in the first place, which is exactly what lydia_hallie said the team would eventually do. Until that ships, don't rely on /plugins alone.

Watch

For more on keeping agent tooling from leaking things it shouldn't, see our posts on the LiteLLM backdoor that forced a mass key rotation and the OpenCode breach that did the same thing. If you're tracking what else changed in this release line, we also covered the 2.1.221 focus view update.