al-ice.ai

The Harness Knew Your Email: Claude Code Put Account Addresses in Web-Request Headers

Agent & Supply Chain Security by al-ice.ai Editorial

On 5 November 2026 a developer filed anthropics/claude-code#107757, “Bug Report: Privacy violation in User-Agent header” (open at the time of writing, macOS, Claude Code 2.1.318): while conducting web searches, the agent had, in the reporter’s words, “divulged my email to arbitrary 3rd parties in the User-Agent request header … without my permission.” The reporter says scam mail followed — “dozens of scam emails per day” — and asks for the behavior to be removed from the harness entirely, not governed by an opt-in or opt-out setting: it does nothing for services that dislike agentic traffic, preserves no anonymity, and hands scammers a verified active address. By 8 November the issue carried 729 +1 reactions, with one commenter noting it ranked fourth among more than 16,000 open issues in the repository, alongside GDPR-violation and class-action discussion in the thread.

This is the second Claude Code identity-exposure story this week to land on the same root cause. Days earlier this site covered Apiiro’s finding that “don’t ask again” approvals saved verbatim into settings.local.json leaked 2,539 secrets across 1,994 GitHub repos. There, the agent wrote ambient authority into a file that traveled to GitHub. Here, the agent read ambient identity out of its own context and wrote it into outbound HTTP. Both are the same design failure from opposite ends: the harness treats the user’s identity material as conveniently available context, and the model decides where it goes next.

The address was already in every session before the request was ever made

The November issue is the visible symptom; the loading mechanism was reported in #81138, open since 25 July 2026 with 90 +1 reactions. That report shows Claude Code injecting the signed-in account’s address into the model’s system prompt on every session, undocumented, without consent and with no supported way to stop it — a # userEmail block reading The user's email address is <account email>, sourced from ~/.claude.json’s oauthAccount.emailAddress, confirmed against the shipped v2.1.220 bundle. Authentication data given to Anthropic to sign in became model context on every launch. Once the address sits in context, any downstream behavior that emits identifiers — a composed curl line, a fetch call, a search request — can carry it out, and no per-request approval designed for commands will necessarily catch an address embedded inside an otherwise legitimate-looking header.

The thread’s most plausible mechanism is mundane, which is what makes it hard to dismiss as a one-off hallucination. Some public data services require a contact address in the request header: the discussion names Wikipedia’s scripted-client identification policy, and Hacker News commenters demonstrate the pattern against the SEC API, which returns 403 for a default request and 200 once an email-bearing User-Agent is supplied — with one commenter reporting Claude sent a personal address on SEC data requests despite a separate work contact existing. An earlier Hacker News thread, “Claude Code is leaking real email address as a User-Agent string in curl command” (11 August 2026), shows the same failure mode was observable three months before the November report. The agent is not “spraying” the address at random; it is propagating account identity into requests wherever a service, a tool definition, or its own composed command asks for a header identifier. That is arguably worse than random: it makes the leak conditional on destinations the user never reviewed, exactly the traffic an agentic coding tool generates all day.

Anthropic shipped a check and a mod; users report gaps in both

There is evidence of vendor response, and evidence it is partial. The v2.1.317 release (published 3 November 2026) includes, verbatim: “Added a check that asks before a web or shell tool call sends your account email address to the network.” A commenter in the issue thread announced a built-in cc-plugin-privacy mod, enabled by default and toggleable via /plugins, described as deterministically blocking the behavior, with its source to be published alongside the other built-in mods — and a follow-up comment links the mod source under mods/privacy for inspection and feedback.

Against that, three gap reports stand in the same thread and in independent coverage. The original reporter, running 2.1.318 — one release after the check shipped — states the cc-plugin-privacy entry is not visible in /plugins at all. Community testing reported on 2.1.318 found the guardrail missing even commands that name the User-Agent explicitly. And The Kernel Post’s 8 November analysis notes a test on 2.1.319 in which a User-Agent command involving the account email still ran, implying the protection is not a blanket refusal. Secondary coverage further reports Anthropic staff saying the deeper fix is to remove the account email from the model’s context entirely, expected the following week — an acknowledgement, if accurate, that a per-request ask cannot fully contain an identifier that is present in every prompt. We carry that last point as attributed secondary reporting, not as a verified vendor statement: it did not appear in the issue comments we reviewed.

The Kernel Post’s framing is the right calibration and we adopt it: narrower than the panic, still bad. The public evidence describes a tool-use workflow leaking an identifier into outbound requests — not a compromise of Anthropic accounts, tokens, or repositories, for which no evidence has surfaced. But “only the User-Agent, only on some sites” misunderstands the agentic threat model. A coding assistant composes requests to arbitrary third parties on the user’s behalf, continuously. If it can silently attach a persistent personal identifier to those requests, the user’s privacy boundary becomes every target site’s log-retention policy — a bad assumption on the open web, and one the reporter’s scam-mail surge makes concrete rather than theoretical.

What to do

  • Update past 2.1.317 and verify the guard actually loaded. Check /plugins for the privacy mod in the exact environment your team uses — the thread shows documented-does-not-equal-enabled — and treat absence on a current version as a finding, not a display quirk.
  • Search session logs for your address. Grep recent tool-call transcripts and shell history for the account email appearing inside User-Agent, curl compositions, and fetch calls, especially against public data APIs with contact-header policies. One commenter’s working mitigation is an explicit CLAUDE.md User-Agent policy: the address may appear only for pre-approved sites whose policy demands it, never elsewhere.
  • Treat any address that ever left the machine as burned for spam purposes. A leaked address cannot be un-logged from third-party servers. Expect targeted phishing that references the user’s real tooling and recent searches, and brief anyone whose address the agent may have carried.
  • Watch for the context-removal update, then confirm the # userEmail block is actually gone. A per-request ask is a gate on a road the identifier should not be traveling at all. Until the address leaves the system prompt, assume every composed request is a potential carrier and keep the explicit header policy in place.

Verification note: read first-hand via the GitHub API — issue #107757 in full (title, 5 November 2026 creation, open state, 2.1.318/darwin environment, reporter’s scam-mail and harness-removal demands, 729 +1 reactions, all cited comments including the cc-plugin-privacy announcement, the 2.1.318 absence report, the Wikipedia/SEC mechanism discussion, and the reaction-rank/GDPR remarks) and issue #81138 (25 July 2026, open, 90 +1, # userEmail block, ~/.claude.json sourcing, v2.1.220 bundle evidence); the anthropics/claude-code releases API for v2.1.317 (ask-before-sending entry, published 3 November), v2.1.318, and v2.1.319; The Kernel Post’s 8 November analysis in full (SEC 403/200 example, 2.1.319 test result, narrower-than-feared assessment, no-wider-compromise-evidence statement); and the Hacker News Algolia API confirming the 11 August User-Agent/curl thread. The 2.1.317 changelog entry and mod-source link are vendor-published; the context-removal plan is carried as attributed secondary reporting only. We did not run Claude Code, compose requests, inspect logs beyond the public thread, or contact any vendor.

Sources: