Claude Code puts the account email in every model prompt; users report it in git commits, headers and web requests (issue #81138)

View raw markdownEdit on GitHub ↗

TL;DR

Claude Code reads the signed-in account's email address from ~/.claude.json and places the sentence "The user's email address is …" in the model's context on every request, with no setting to turn it off; the open issue #81138 (2026-07-25) has reports from fifteen commenters, including the model writing the address into ten git commits as user.email, into an HTTP User-Agent header, and handing it to a web service from a subagent, and no reply from Anthropic as of 2026-10-29. If your commits, logs or outbound requests from agent sessions carry an address you did not configure, this is where it came from; API-key authentication is the only reported path that omits it. Update 2026-11-06: a second issue, #107757 (2026-11-05, 1,380 Hacker News points), reports the address in the User-Agent of web requests and a flood of scam mail; Anthropic shipped a default-on check in 2.1.317 (2026-11-02) that covers shell calls naming a User-Agent, its README calls it "a courtesy, not a boundary", and a Claude Code team member on Hacker News says the address will leave the model context in the next release. Upgrade off the stable tag (2.1.311 on 2026-11-06, no check), and keep the git and header checks below.

What happened

The behaviour. The issue's reporter (skflowne) decompiled the bundle: when ANTHROPIC_UNIX_SOCKET is unset, the client reads oauthAccount.emailAddress and adds a userEmail field to the user-context block. In 2.1.220 the text was the bare address; 2.1.246 appended "Use it only to identify the user… Never send it to an unrelated service… unless the user explicitly asks"; a 2.1.289 report places it inside a <system-reminder> attached to every outbound Messages API request, including the requests that follow tool results within a turn. The reporter found no consumer of the value in the bundle other than a telemetry flag recording its presence (has_user_email). IS_DEMO=1, documented as hiding the email, gates seven display surfaces and not the context builder. None of the documentation pages (environment variables, authentication, data usage, settings) mention it.

The reports. All are self-reported in the thread; they come from different accounts across three months:

  • The reporter: the model passed git -c user.email=<private address> on ten commits, overriding a configured noreply identity; GitHub push protection blocked the push and the address stayed in the local reflog.
  • inigohidalgo (2026-09-01) and Goofables (2026-09-07, 2.1.263): the agent used the subscription email as the git identity.
  • mootari (2026-10-20): the model placed the address in a User-Agent header on the web harness (Opus 5.5).
  • markblundeberg (2026-10-27): a subagent gave the address to a web service.
  • Coice (2026-08-20): the model drew inferences from the address that changed its output.
  • The model has also volunteered the sentence to the user unprompted ("My system prompt tells me your email address is…").

The vendor. No Anthropic or maintainer comment is on the thread; the issue carries the bug label and no assignee. The reporter's tag of a maintainer on 2026-08-20 drew no visible reply. Earlier issues on the same behaviour were closed: #53231 and #50702 as not planned after inactivity, #67605 as a duplicate of #58081, which was then locked. A Hacker News thread of 2026-10-29 ("Tell HN: Claude Code adds your email to the prompt, the LLM sends it to websites", TekMol) links the issue and a Reddit thread this run could not open.

Why it matters here. The address is a stable personal identifier inside every prompt, which makes it available to any content the agent reads: a prompt-injected README or web page that asks the model to include "the user's email" in a request gets it. The git reports are the concrete harm so far: a private address in commit metadata on a public repository is a disclosure that survives a force-push. The vendor's instruction sentence governs use, not presence, and the reports after 2.1.246 show the sentence is not sufficient.

Am I affected?

grep -o '"emailAddress":"[^"]*"' ~/.claude.json 2>/dev/null       # the field the client reads; present means it is injected
git log --all --format='%ae%n%ce' | sort -u                          # addresses in your commits; look for one you did not configure
CLI=$(readlink -f "$(which claude)"); grep -ao 'userEmail:`[^`]\{0,200\}' "$CLI" | head -1   # the construction site, from the issue
  • Signed in with a Claude account: affected on every reported version from 2.1.220 to 2.1.289.
  • Using an API key, Bedrock or Vertex: a commenter (yurukusa) reports no oauthAccount and therefore no injection; this file has not verified it.

If you are affected

  1. Check public repositories you pushed to from agent sessions for the address in author or committer fields; GitHub's push protection catches it only when enabled for the repository.
  2. Set and verify a repository-level user.email and watch for -c user.email= in the agent's git commands; the reports show the model overriding the configured value.
  3. Reported workarounds, each partial: a CLAUDE.md instruction not to use the address (governs use, not presence); API-key authentication (no setting, changes billing); a local relay via ANTHROPIC_BASE_URL that strips the block (the relay sees your bearer token; a third-party relay is a worse exposure than the address).
  4. Treat the address as a known-injected value when assessing a prompt-injection incident: if your local AI agent was exploited.

Prevention

  • Agent sandboxing: egress controls limit where an injected identifier can go.
  • Credential hygiene: what the client puts in context is part of your data footprint; know the fields.

Update 2026-11-06 — issue #107757 reaches the Hacker News front page; a default-on check in 2.1.317 covers one shape; Anthropic says the address leaves the context next release

The second issue. On 2026-11-05 taylor-edwards opened #107757 ("Bug Report: Privacy violation in User-Agent header", Claude Code 2.1.318, macOS): Claude Code "divulged my email to arbitrary 3rd parties in the User-Agent request header while conducting web searches without my permission", with "dozens of scam emails per day" as the stated consequence, and a request that the behaviour "be removed from the harness entirely". The issue carries bug, area:security and area:tools, 571 thumbs-up on the first post, 423 Hacker News comments and 1,380 points (item 50385272, 2026-11-05). No CVE. The mechanism is the one this file describes: the address is in the model's context, and when the model writes its own curl command and a site asks automated clients for a contact, it sometimes supplies the address. A commenter (demegire) points to sites that ask for exactly that, such as Wikimedia's User-Agent policy and SEC EDGAR, and the tin.computer write-up (2026-11-06) says the same while noting that a header shows receipt by the site, not which agent or model sent it.

The vendor's two statements. On GitHub, poteat (labelled Contributor, not Member) replied on 2026-11-05: "We introduced a built-in mod called cc-plugin-privacy to deterministically block this behavior in v2.1.317 and later", enabled by default, switchable off via /plugins. A Hacker News commenter says poteat's own site names a different employer, so this file treats the reply as a contributor's statement that the changelog corroborates. On Hacker News, a commenter under the handle lydia_hallie, who says "I work on Claude Code", wrote: "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", and explained the origin: users had reported hallucinated names in @author tags, so the account email was added to context for signed-in users, and "when Claude wrote a command itself, like a curl call, it sometimes put your email address in the User-Agent as a contact address." That is a forum comment under an unverified handle, quoted as such; the removal had not shipped when read (2.1.319 was on the next tag only, published 2026-11-06 00:58 UTC, and a commenter running it still got the address back from "what's my email"). No comment on the GitHub issue comes from an account marked as Anthropic staff.

What 2.1.317 actually ships, three readings that do not agree. The CHANGELOG line for 2.1.317 is "Added a check that asks before a web or shell tool call sends your account email address to the network." The published mod at mods/privacy in the repository (README read 2026-11-06) describes something narrower and stricter: one tool.check hook on Bash, PowerShell and Monitor calls that refuses, with no prompt and in every permission mode, a call whose input holds the account address and also names a User-Agent (User-Agent, UA=, curl -A, wget -U, -UserAgent); it does not inspect WebFetch, WebSearch or MCP tools, misses an address read from a variable or file, and its README says "This is a courtesy, not a boundary, and it covers one shape." Yunus Aydın's analysis (2026-11-06) compared the published source with the 2.1.318 binary and found the shipped guard differs: it also watches the web tools, recognises more network clients, prompts instead of refusing, and registers behind a server-side flag (tengu_wise_newt), which matches a GitHub commenter who found the mod absent from /plugins on 2.1.318. The repository copy is not the shipped copy; audit the artifact you run. The mod can be turned off with "cc-plugin-privacy@builtin": false under enabledPlugins in user or managed settings.

The registry channels. npm view @anthropic-ai/claude-code dist-tags on 2026-11-06: latest 2.1.318 (2026-11-03), next 2.1.319 (2026-11-06), stable 2.1.311 (2026-10-26). A reader on the stable tag has no check at all; the first version with one is 2.1.317 (2026-11-02 23:57 UTC). Versions 2.1.313 and 2.1.315 have no changelog entries.

The older report nobody answered. Issue #55743 (2026-05-03) described the ~/.claude.json to # userEmail path and predicted the User-Agent outcome; a bot closed it as not planned on 2026-06-02 and locked it on 2026-08-04 with no maintainer reply. Issue #37201 (2026-03-21) reported a model writing an address into git config --global user.email; it was labelled invalid by a bot because the tool was Antigravity, and closed the same way. This file's git checks still apply; the 2.1.317 check does not look at git commands.

Status. ongoing to mitigated: a default-on control exists from 2.1.317 and the vendor has said, through a team member's forum comment, that the address will be removed from context. It is not patched: the address is still in every prompt on 2.1.318, the published check covers one command shape, and the stable channel ships without it. Re-check after the release the comment promises; if the address leaves the context, this file moves to patched for signed-in users.

Update 2026-11-07 — 2.1.319 is latest and carries no removal; stable is still 2.1.311

npm view @anthropic-ai/claude-code dist-tags time on 2026-11-07: latest 2.1.319 and next 2.1.319 (published 2026-11-06 00:58 UTC), stable 2.1.311 (2026-10-26). The CHANGELOG entry for 2.1.319 lists auto-mode, MCP-task, gateway and permission changes and no line about the account email; the only email line in the file is still 2.1.317's "Added a check that asks before a web or shell tool call sends your account email address to the network". The removal a Claude Code team member promised on Hacker News for "early next week" has not shipped in any channel as of this read, and the stable channel still has no check. Status stays mitigated. Separately, a second Claude Code on-disk store carrying user secrets was reported this week: the .claude/settings.local.json approved-command file.

Update 2026-11-10: 2.1.321 narrows the check to a silent refusal of one command shape; the address is still in context; stable is still 2.1.311

npm view @anthropic-ai/claude-code dist-tags time on 2026-11-10: latest and next 2.1.322 (published 2026-11-10 01:58 UTC), stable 2.1.311 (2026-10-26). 2.1.321 was published 2026-11-09 19:02 UTC. The registry has no 2.1.320.

The CHANGELOG entry for 2.1.321 carries one line on this issue: "Changed the account email check to refuse only a shell command that holds your email and names a User-Agent, without asking, so other commands and scheduled runs no longer stop at its prompt". That is a narrowing. The 2.1.317 line said the check "asks before a web or shell tool call sends your account email address to the network"; from 2.1.321 the changelog's own description matches what the published mods/privacy README said on 2026-11-06: a refusal with no prompt, for shell commands that both contain the address and name a User-Agent. By the changelog's wording, a web tool call, a shell command that sends the address somewhere other than a User-Agent, and a git identity change are outside it. The 2.1.322 entry has one line, about fast mode on Vertex.

Neither entry removes the account email from the model's context. The removal that a commenter who says they work on Claude Code promised on Hacker News for "early next week" (written 2026-11-05) is not in the changelog for any version through 2.1.322. The stable channel is still six versions before the first check. Status stays mitigated, for the same reason as before, and the affected range in this file's header now runs through 2.1.322.

Two other 2.1.321 lines are security fixes with no advisory on the vendor's tab when read on 2026-11-10: "Fixed MCP OAuth requests sending secrets such as refresh tokens to another host when a server redirected them" and "Fixed a case where a read-only Bash command ran outside the sandbox without a permission prompt". 2.1.319 has the same kind of line: "Fixed a Bash permission bypass where a crafted environment prefix could hide part of a command from permission checks" and "Fixed a sandbox escape when creating a worktree". They are quoted here as changelog lines. No CVE, affected range or reporter is published for any of them, and a reader on stable (2.1.311) has none of the four.

Sources