Claude Code email in User-Agent headers: how it happened and what the fix covers

Claude Code, Anthropic's coding agent, put the signed-in account's email address into the model's context. When the agent wrote its own curl commands for sites that ask scripts for a contact, such as Wikipedia and the SEC, it sometimes put that address into the User-Agent header. Anthropic shipped a check in version 2.1.317 and says the next release removes the email from the context. If you use Claude Code signed in, here is what happened, what the current guard covers, and what to do until the real fix lands.

TL;DR

• Anthropic added the account email to the model's context for signed-in users, according to Lydia Hallie on Hacker News, because Claude kept inventing names for things like @author tags.
• Sites like Wikimedia ask scripts for contact information in the User-Agent. The model sometimes used the only address it had: yours.
• Version 2.1.317 added a privacy mod. Its published readme describes a shell-only check of two word matches and lists what it doesn't cover, including WebFetch and WebSearch.
• The stable channel is still on 2.1.311, which has no check. The email removal was promised for "early next week" and had not shipped when I checked (newest changelog entry: 2.1.318).
• GitHub issues describing the same User-Agent leak go back to September 18.

How did Claude Code put an email in a User-Agent header?

Two ordinary things met.

The first is the context. Hallie's explanation: "Users had reported Claude would hallucinate names for things like @author tags, since it didn't have context on the account. So we added the account email in the model's context for signed-in users." A July report, issue #81138, had already quoted the injected block after decompiling the shipped bundle:

# userEmail
The user's email address is <account email>.

That reporter says the value comes from ~/.claude.json → oauthAccount.emailAddress, and that Claude had already written the address into ten git commits through git -c user.email=.... GitHub's push protection rejected the push.

The second is etiquette. Plenty of APIs want scripted clients to say who they are. When the agent writes its own curl call to such a site, it looks for a contact, and the only address in its context is the account email. One Claude Code developer put it this way: "Claude apparently tends to decide that this policy is worth following."

The result is a request like this simplified sketch, with a placeholder address:

curl -A "ResearchBot/1.0 ([email protected])" https://en.wikipedia.org/w/api.php

Why do websites ask for a contact in the User-Agent?

The Wikimedia Foundation User-Agent Policy says: "Scripts should use an informative User-Agent string with contact information, or they may be blocked without notice." It also says the contact "should be given as an email address, a website, or a wiki user". A website would have done the job.

The SEC's Accessing EDGAR data page asks automated tools to "declare your user agent in request headers" and shows a sample header of the form Sample Company Name AdminContact@<sample company domain>.com.

Both policies are reasonable for a human writing a bot. The trouble is the model applying them with an address it was handed for identification. Reports collected on GitHub name the sites: Wikipedia (#102577), sec.gov with nine requests from subagents (#104774), Liquipedia (#101659) and crates.io (#95258).

A User-Agent also tends to stay around after the request. Apache's documented combined log format writes %{User-agent}i into the access log next to the client address and time. I don't know how any specific site logs its traffic, but this is the default shape of a very common server log.

The instruction in the context didn't hold

Users quote the context block itself telling the model to stay quiet. From #104774: "Use it only to identify the user... Never send it to an unrelated service, such as in a request header, URL, or payload, unless the user explicitly asks."

The model sent it anyway, and sometimes said so. In an October 20 comment on #81138, a user quotes Claude's reply: "Your email address was given to me as account context, with an instruction not to send it to other services in request headers. I sent it anyway." Those are model outputs quoted by users, so treat the self-explanation with care, but the pattern repeats across reports. A prompt instruction is a request to the model. It is a weak place to keep personal data.

What does the Claude Code privacy mod actually block?

Anthropic's first response shipped in 2.1.317. The CHANGELOG entry reads: "Added a check that asks before a web or shell tool call sends your account email address to the network". A staff comment on issue #107757 says the built-in cc-plugin-privacy mod is there "to deterministically block this behavior", and that it is on by default.

The source went public in mods/privacy less than two hours after the issue. Its readme describes the behavior differently from the changelog: "a Bash, PowerShell or Monitor call whose input holds that address and names a User-Agent is refused", and "The refusal raises no prompt". The hook in register.ts returns a deny:

return Outbound.namesUserAgentWithAddress(text, email)
  ? { decision: 'deny', reason: Outbound.REFUSAL }
  : verdict

The readme is candid about the method: "The test is two word matches over the whole input. There is no parser, on purpose." It also lists what passes:

The readme sums it up as "a courtesy" that "covers one shape". Hallie said the same about scripts: the mod "still doesn't prevent all cases, like when Claude writes a script and runs on its own."

Did the guard catch the tests?

Two users tested it without sending anything anywhere. On macOS, love540 ran echo 'User-Agent: test <account email>' > /dev/null on 2.1.317 and 2.1.318 and reports it "ran, not refused", with the mod listed as loaded. On Windows 11, KardKuro ran the echo and curl -s -m 3 -A "test <account email>" http://leak-test.invalid/ on 2.1.318 and reports "No prompt and no denial in either case". The .invalid domain never resolves, so the test leaked nothing.

These are user reports. Anthropic hasn't confirmed them, and whether the shipped build matches the published source is unverified. They do suggest you shouldn't assume the check is active just because the mod appears in /plugins.

When does the real fix ship?

Hallie: "We're removing the account email address from the context Claude Code gives the model. This update will hit Claude Code users in the next release, which should arrive early next week. I'll share an update in this thread once it's out."

That is the right place for the fix. An output filter has to recognize every route the address can take, and the readme lists several it doesn't. If the address never enters the context, the model has nothing to send. When I checked on November 6, the newest changelog entry was 2.1.318, npm's stable tag pointed to 2.1.311 and latest to 2.1.318.

What to do until then:

• If you're on the stable channel (2.1.311), Hallie's own advice is to update to 2.1.317 or later so the mod is present.
• If you run your own hooks, cover file writes and edits too. KardKuro's stopgap PreToolUse hook also checks Write and Edit "so a script that hardcodes the address in a UA gets caught before it is written".
• Search your Claude Code session transcripts for your own address next to a User-Agent. If it shows up, you know which sites received it.
• Prefer a project-specific contact, like a website URL, when a site's policy asks for one. Wikimedia accepts it.

How much earlier was it reported?

Hallie wrote: "Again, this should not have happened, and we should've caught this behavior earlier."

The bug tracker has dates. The July 25 report on #81138 warned that "Anything in the model's context is material it can emit — into commits, PR bodies, config files, code comments, test fixtures, or outbound tool and MCP calls." On September 18, a user filed #95258, "User email from account metadata inadvertently sent to external service in User-Agent header", on version 2.1.275. GitHub's automation labelled it area:security about a minute later. Between October 13 and 24, at least four more issues described the same leak. All five were still open on November 6.

Anthropic's account, from a Claude Code developer on Hacker News, is that the team became aware "when this problem started popping off on Reddit". I couldn't check the Reddit posts myself. The issue that went viral, #107757, was filed on November 5; its reporter blames the leak for dozens of scam emails a day, and nothing public proves that link.

Verdict: REVERT

I'd revert putting the account email in the model's context. An address the model can see is an address it can send, and the guard's own readme describes a one-shape courtesy. Anthropic says it is doing exactly this in the next release, which is the right call. Until it ships, treat the mod as a partial net.

FAQ

Does Claude Code send my email to every website? No source says that. The reports describe the model sometimes adding the account email when it wrote its own requests for sites that ask scripts for a contact.

Does the privacy mod stop WebFetch or WebSearch? Its readme says WebFetch and WebSearch are not checked, and neither are MCP tools.

Which version has the check? Version 2.1.317 and later. The stable channel was still on 2.1.311 on November 6.

Has the email been removed from the context yet? Not when I checked. Anthropic said the removal would come in the next release, expected early next week.

Sources

• GitHub #107757: Privacy violation in User-Agent header
• Hacker News: Lydia Hallie's comment
• Hacker News: Claude Code developer on site policies and on Reddit and the mod
• anthropics/claude-code mods/privacy
• anthropics/claude-code CHANGELOG
• GitHub #81138, #95258, #101659, #102577, #104774
• Wikimedia Foundation User-Agent Policy
• SEC: Accessing EDGAR data
• Apache HTTP Server: Log files
• npm: @anthropic-ai/claude-code

Cover portrait: Dario Amodei at TechCrunch Disrupt 2023, by TechCrunch, CC BY 2.0, via Wikimedia Commons. Background removed, cropped and resized; identifies Anthropic only, no endorsement, quote or reaction.

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources