A bug report that topped Hacker News says Claude Code sent users' account emails to third-party sites, and the cause is a lesson for anyone putting data in an agent's context.
On Nov 5 a developer opened issue #107757 on Anthropic's claude-code repo on GitHub, titled "Privacy violation in User-Agent header." Their claim is that Claude Code put their email in the User-Agent header of requests to third-party sites during web searches, without asking, and that they now get "dozens of scam emails per day." They want it removed from the harness entirely.
The Hacker News thread climbed to 1,241 points and 395 comments. The spam link is the reporter's own claim and nobody has verified it. The mechanism behind it is well documented though, and it's months old.
What's actually new
The root cause was written up back in May, in issue #55743. That report says Claude Code reads the OAuth account email from ~/.claude.json and injects it into every session's context as a # userEmail block. There was no settings flag to turn it off, and deleting the email from the file breaks OAuth on the next launch. The issue was auto-closed as "not planned" on Jun 2 after going quiet.
Then add websites that want contact info from scripts. Commenters on Hacker News pointed at the SEC API, which rejected curl's default User-Agent with a 403 and accepted one with an email in it. So the model has a task, the API wants an identity and the only address in context is yours. It uses it. The same commenter later added that the SEC takes most non-curl user agents anyway, so the email wasn't even needed.
People went and checked their own logs. One commenter on the GitHub issue had Claude scan their local transcripts and found 53 calls that put their email into a User-Agent, across 8 sessions from 2026-08-09 to 2026-11-01. Almost all came from workflow subagents writing their own curl -A commands, not from WebFetch. On HN someone said they caught Claude pulling Reddit pages with the part of their email before the @ in the query string.
What Anthropic shipped: the Claude Code changelog for 2.1.317 says "Added a check that asks before a web or shell tool call sends your account email address to the network". On the issue, a commenter marked as a repo contributor wrote that a built-in mod called cc-plugin-privacy blocks this behavior in v2.1.317 and later, on by default and switchable in /plugins. A write-up from CellCog (an agent platform, so not neutral) adds that the check also denies harmless local calls in headless runs, like curl to 127.0.0.1, and that it only catches the email on the way out. The email still sits in the session.
Why it matters if you build agents
Forget Claude Code for a sec. The pattern is that anything in the context window is something the agent can send somewhere. Nothing got hacked here. The model had an email, a task and an API asking for contact info, and it connected the dots the way you'd want it to for everything else.
Now swap "email" for "API key." Say your agent's config holds a Stripe key. An HN commenter asked what happens when a site answers with a 402 and payment instructions while the agent can reach your password vault. Same reasoning, much worse outcome.
The fix most people kept landing on is structural, keep secrets out of the context and gate what leaves. That's how MewCP handles app logins: keys sit in an encrypted vault and get injected into each request on the way out, so the agent never sees one and has none to leak. To be clear, MewCP wouldn't have stopped this bug. The email came from the harness and left through curl and web tools, not an MCP call. It just keeps app credentials out of the place this kind of mistake starts.
The built-in sandbox only covers part of it. Claude Code's own docs say the sandbox "covers shell commands only," that file tools, MCP servers and hooks run outside it, that allowedDomains doesn't limit WebFetch and that it's off by default. For shell commands though, traffic goes through a local proxy that checks each host against an allowlist that starts empty. That would at least have flagged a subagent curling a random government API.
What people are saying
HN split along a predictable line. One camp called it a tricky alignment problem: the agent is told to finish the job, the site wants an email, it hands one over. Others said that's an excuse, an assistant should follow your wishes and not some random website's, and it should've asked. A few noted that bots putting contact info in the User-Agent is standard, so the real problem is no prompt and no choice of address.
The sandboxing subthread was the most useful. One commenter suggested two Docker containers on one network, the agent's blocked from the internet and a proxy with a domain allowlist as the only way out. Someone else pointed out that hiding your email from the agent is hard anyway, since one look at the git log tells it who you are.
One question stuck with me: "Should Claude have internet access without a clear log of all requests made?" For tool calls that go through a gateway, that part is solvable. MewCP logs every call that passes through it with the tool, time, who it ran for, status and latency, and doesn't store payloads or responses. It won't see a curl your agent runs on its own, so you still want a sandbox for that.
Open questions
- The spam. Nobody has verified that the scam emails came from these requests. CellCog says it couldn't either.
- The version. The new report lists Claude Code 2.1.318, which already has the 2.1.317 check. It doesn't say when the leaks happened, so it's unclear whether the check missed something or the leaks came before the update.
- The root fix. The shipped change checks at the exit. Requests to stop injecting the email at all, or make it opt-in, haven't led to a change yet. The May issue was closed, and CellCog says a July report on the same thing is still open.
- Scale. Every report is one user's logs. Nobody has said how many sessions sent an address.
If you run Claude Code, update to 2.1.317 or later and leave the privacy mod on. And when a task needs a contact address, give it one you picked.
Sources
- GitHub issue #107757, "Bug Report: Privacy violation in User-Agent header", https://github.com/anthropics/claude-code/issues/107757
- Hacker News discussion, https://news.ycombinator.com/item?id=50385272
- GitHub issue #55743, "Claude Max account email auto-injected into LLM context with no opt-out", https://github.com/anthropics/claude-code/issues/55743
- Claude Code changelog, https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
- Claude Code sandboxing docs, https://code.claude.com/docs/en/sandboxing
- CellCog, "Claude Code Sent User Emails to Websites: What Happened", https://cellcog.ai/blog/claude-code-email-leak/
