Claude Code Users Report the Signed-In Email in User-Agent Headers; the Default Privacy Mod Leaves Reported Gaps
A verified GitHub issue reports Claude Code sent the signed-in account email in User-Agent headers. A user documents model-composed paths the default v2.1.317 privacy mod may miss - here is a bounded fleet check.
On Nov. 5, a user opened issue #107757 reporting that Claude Code included their account email in the User-Agent header while it performed web searches, and that they now receive dozens of scam emails per day as a result. The report drew hundreds of reactions from other users. Note what this evidence is and is not: it is a user report of model-composed requests on their own machine, not an independently reproduced audit, and it does not establish that every server the agent contacted received the address.
An Anthropic contributor (poteat) responded in the thread: a built-in mod named cc-plugin-privacy, shipped in v2.1.317 and later, “deterministically blocks this behavior.” The mod is enabled by default and can be turned off via /plugins. The v2.1.317 release notes describe the underlying control as “a check that asks before a web or shell tool call sends your account email address to the network.” No Anthropic commitment to remove the email from model context appears in the fetched thread, and the only disable mechanism the evidence documents is the /plugins toggle.
What one user found in their own transcripts
A follow-up commenter (mkubenka) reported scanning their own transcripts under ~/.claude/projects/ and finding two model-composed outbound patterns. In their words, when Claude writes its own curl -A or a script, it “also makes up a descriptive product token from the session,” such as the project or task name:
curl -sf -A "<project-name>-site-build/1.0 (<account email>)" "https://<public geocoding API>/search?q=<address query>"
# the user says the model wrote this via Edit, then ran it against a public API
headers = {'User-Agent': '<tool-name>/0.1 (mailto:<account email>)'}
Per the user’s account, the first request carried a project name and the account email in the User-Agent header, while the address query sat in the URL’s query string - the same request, but not the same header. The user reports two limitations: the mod “matches only the account address,” so a descriptive product token with no email passes, and in the second case the model wrote the address into a script file and then ran it, so no checked shell input ever contained it. These are one user’s reported findings about their own setup, not verified implementation details of the mod.
The same user reports that on v2.1.319 with the mod enabled, echo 'User-Agent: test <account email>' > /dev/null still runs rather than being refused. That command sends no network traffic, so it shows only that the check did not fire on that shell input - not that any data left the machine. v2.1.319, released Nov. 6, adds no changelog entry addressing this issue.
Bounded checks for your fleet
1. Record the mod’s state. Check /plugins on each machine - that is the only toggle the evidence documents - and keep a fleet manifest of it, as our Claude Code mods fleet extension manifest guide recommends.
2. Search transcripts with an explicit address. Supply the email yourself rather than deriving it from a command whose output format is not verified, and search recursively without assuming shell globstar:
EMAIL="you@example.com"
grep -rF -- "$EMAIL" ~/.claude/projects
grep -rF -- "mailto:$EMAIL" ~/.claude/projects
-r walks subdirectories, -F matches the literal address, and there is no head to truncate results. Treat every hit as a lead, not a verdict: it may be session context, generated code, a refused call or a command that never executed. Open the surrounding transcript, read the tool results, and confirm the request actually ran and what it sent before classifying a disclosure - a string match alone cannot tell you which host, if any, received the data.
3. Bound the remaining paths. The shipped check covers web and shell tool calls; on the user’s report it does not inspect the contents of files the model writes and then executes. None of the measures below is verified against the reported disclosure paths, so treat them as risk-reduction recommendations, not proven fixes: run sessions inside the Claude Code sandbox with a tight network policy, and review agent-written scripts before execution. You can also prompt agents to use a generic User-Agent when they compose HTTP calls, but prompting is not enforcement - the model can ignore it. And note that a tight network policy is in effect a host allowlist: it does not stop sensitive headers from reaching the hosts you permit. If you want header rewriting at the network layer, it requires an HTTP-aware inspection point such as a TLS-terminating gateway that you control - an ordinary HTTPS forwarding proxy cannot rewrite headers inside encrypted traffic.
The structural lesson stands regardless of how the reports settle: any string in the model’s context can ride out in whatever HTTP client the model composes. Transcript search finds the candidates; execution evidence identifies the disclosures. Removing the email from context entirely - proposed by the commenter in the thread - remains a user recommendation, not an announced Anthropic change. The issue stays open under area:security.
The same egress-audit discipline we described after the agent screenshot leak applies here: map every path that can publish data off the machine, then prove what each one actually sends.
