The report and the vendor's own caveat

On November 5, a user filed issue #107757 against Anthropic's Claude Code repository, alleging that the coding agent "divulged my email to arbitrary 3rd parties in the User-Agent request header while conducting web searches without my permission." [1] The reporter links the exposure to "dozens of scam emails per day" and says their company is moving to Pi with OpenRouter because they no longer trust Anthropic to preserve their privacy; the spam causation is the reporter's account, not a verified link. [1] The issue was still open at the November 6 snapshot, with 204 upvote reactions and 36 comments. [1] On Hacker News, the same report reached the front page, collecting 691 points and 241 comments. [2]

Two published records confirm the two halves of the exposure chain: the vendor's README states that the context hands the model the signed-in account's address, [3] and a session log shows a curl command sending the address in its User-Agent header. [4] The fix's limits are written by the vendor itself: the same README calls the guard "a courtesy, not a boundary, and it covers one shape." [3] For an IT team, the question is what the fix covers. The verification burden sits with the buyer for now.

The answer: a built-in guard, on by default

The response arrived fast. Accounts presenting themselves as Anthropic staff replied in the issue ("poteat") and on Hacker News ("mpoteat"), the latter just over an hour after the story was posted. [5] [6] "We introduced a built-in mod called cc-plugin-privacy to deterministically block this behavior in v2.1.317 and later," the reply reads; the mod is "enabled by default, you can turn it off via /plugins." [5] On Hacker News, the same account wrote the team had been "initially aware of this a few days ago when this problem started popping off on Reddit." [6]

The response also states the mechanism: "nobody implemented this 'share email addresses to websites' as a feature. Models can be highly unpredictable." [5] As the explanation goes, some sites ask scripted clients to identify themselves with a User-Agent contact email, and "Claude sends the user's email to Wikipedia in its curl call." [5] A published government policy shows the pattern: SEC EDGAR's automated-access rules ask automated clients to declare headers in the form "User-Agent: Sample Company Name AdminContact@<sample company domain>.com". [7] A site requesting contact identity is documented policy; which identity the agent hands over is what the buyer has to control.

What cc-plugin-privacy does not check

The guard's own documentation narrows the "deterministically block" claim. The source-available README says the mod holds one tool.check hook that refuses "a Bash, PowerShell or Monitor call whose input holds that address and names a User-Agent," with the address counted "in any case or percent-encoded." [3] The same document then lists what passes: "a web tool call. WebFetch and WebSearch are not checked, and neither are MCP tools," plus "a request body, curl -u, a From: header" and run-time values like $(git config user.email). [3] The reported scenario was web searches, [1] and nothing published by either side establishes whether the address leaves through WebSearch; that path is currently unknown.

Two facts matter for buyers. The refusal can be switched off in several ways: /plugin disable, a "cc-plugin-privacy@builtin": false line under enabledPlugins in user settings, --settings, or managed settings, a server-side switch read once per session, a hook of an installed plugin that overrules it, or a session where no hooks module loads. [3] And the mod's visibility has already been questioned: one user running 2.1.318 reports that cc-plugin-privacy does not appear in /plugins at all, a single self-report posted hours after the report was filed. [5]

Anthropic's documentation does disclose outbound identifiers, just not this one. The tools reference states WebFetch "sets a User-Agent header beginning with Claude-User." [8] The data-usage page describes a preflight that "sends the requested hostname to api.anthropic.com" before any fetch, disableable with skipWebFetchPreflight and unaffected by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. [9] Neither page, checked on November 6, mentions the account email in any outbound request header. [8] [9]

The address is already in context

The narrowness makes sense once the supply path is visible. Issue #81138, open since July 25 with 83 upvote reactions, documents the injection: a context block reading "# userEmail / The user's email address is <account email>." Its author says the value comes from ~/.claude.json's oauthAccount.emailAddress and located the code by decompiling the shipped bundle; those are user-supplied findings. [10] The vendor's README corroborates the core, though: "The context hands the model the signed-in account's address to identify the user." [3] The #81138 author reports two ways the address already escaped: the model printed it in its own output, and it passed git -c user.email=<address> on ten commits, caught by GitHub's push protection. [10]

The header path has its own record. In July, a user filed issue #78431, "you stupid agent used my real email as user agent string without asking anything." [11] A different commenter, opening "yes same here, curl commands are passing my email address," posted a session log: a Bash tool call running curl against crates.io with the header "User-Agent: ashurbanipal-publish-check (@.*)", the address masked, "5 occurances in a 1 hour session." [4] The report was closed on September 11 by github-actions[bot] as not_planned under a stale label, 56 days after filing. [11] Commenters on the current issue read the pattern as design: "Privacy shouldn't be a plugin. It should be an invariant," one writes; another calls the guard "a bandaid" and asks "why hand the model the user's email address by default?" [5]

Five checks before deploying Claude Code

That chain of context supply, model-composed headers, and a scoped guard gives IT teams five things to verify:

  1. Version and guard presence. Confirm the rollout runs 2.1.317 or later and that cc-plugin-privacy appears under /plugins; know the off switches, including /plugin disable and the enabledPlugins line. [5] [3]
  2. Egress disclosure. Hold the docs against observed traffic: the documented identity stops at the Claude-User prefix and the hostname-only preflight, [8] [9] and neither page accounts for the account email leaving the machine.
  3. The context root. Ask the vendor how to keep the signed-in address out of model context entirely. Today the README confirms the address is handed in, [3] and the issue reporting the injection records no setting or flag to prevent it. [10]
  4. Data defaults. Plan around the published retention: 30 days for users who do not allow model-improvement use, 5 years for those who do; zero data retention is not in the standard Enterprise plan; local transcripts sit in plaintext under ~/.claude/projects/ for 30 days by default; /feedback transcripts are kept 5 years. [9]
  5. Disclosure and defaults as conditions. The July report closed as not_planned, [11] and the current guard is documented as covering one shape. [3] The checkable ask before wider deployment: written disclosure of identifier egress, and a harness-level default instead of a toggleable plugin.

Three documents will show whether the cover widens: the state of issue #107757, the mods/privacy README, and the next release notes. [1] [3] Until then, the vendor's own phrase is the operating assumption: a courtesy, not a boundary.

By SaaS Feeds Editorial