How the address got into the header

The privacy mod's own README states the starting point in one sentence: the context hands the model the signed-in account's address to identify the user. Anthropic's engineer Lydia Hallie, posting on Hacker News on 6 November as reported in coverage of the thread, explained why: users had reported Claude inventing names for things such as @author tags, so the account email was added to the model's context for signed-in users.

That made the address available for every other use the model could find for it. Some websites ask automated clients to identify themselves with a contact address in the User-Agent header; Wikimedia's policy is the best-known example, and coverage of the reports also names SEC EDGAR and crates.io. A model holding exactly one email address, asked to fill in a contact field, filled it in. An instruction not to send the address to unrelated services existed in current versions, according to the statements reported from the thread. The reports say it did not hold.

The November report was not the first. Coverage of the issue traces the same address in the model's system prompt to a report filed on 25 July (issue #81138, still open), which quoted the injected line, "The user's email address is <account email>", from the shipped bundle, and a User-Agent variant was reported again on 18 September. The November reporter blames the leak for dozens of scam emails a day; that link is his claim, and the report does not prove it. Running a version that already contained the guard, he says the leak reached him anyway, and that he is moving his company to another tool.

What the guard actually does

Read the README before the changelog. The 2.1.317 changelog entry says Anthropic "added a check that asks before a web or shell tool call sends your account email address to the network". The published source documentation describes something else on both counts. The refusal raises no prompt, whoever is there and whatever the permission mode. And web tool calls are not checked at all.

The mod documents a narrow, deterministic matching rule. It checks supported shell-tool inputs for the account email alongside a recognized User-Agent reference, then refuses matching calls. Its published design is specific, but the documentation alone does not establish that the check works reliably in every supported environment. One hook watches Bash, PowerShell and Monitor calls. If the call's text contains the account address, in any case or percent-encoded once, and also names a User-Agent, through a word such as User-Agent or --user-agent or a client flag such as curl -A or wget -U, the call is refused and the model is told to run it again without the address. A saved allow rule does not clear the refusal. Neither does auto mode's classifier.

The test is two word matches over the whole input, with no parser, on purpose. The README accepts the cost openly: a harmless call that merely mentions a User-Agent beside the address is refused too, and so is a call caught by an accidental substring. Simplicity is the design. It is also the limit.

What the Guard Does Not Check

The README identifies paths outside the mod's inspection scope, including web tools, MCP tools, certain shell-command patterns and values computed at runtime. These are documented coverage gaps, not evidence that Claude Code actually disclosed account emails through every one of those paths.

The README's own heading for its limits is the most useful sentence in this story: "This is a courtesy, not a boundary, and it covers one shape." The shapes it does not cover are listed in the same document, and they are not exotic:

  • The address with no User-Agent named: in a URL, a request body, a curl -u credential, a From: header.
  • Any web tool call. WebFetch and WebSearch are not checked, and neither are MCP tools.
  • A value the shell computes at run time, a variable, a file sent by name, or a script that holds the address. That last one matters most, because writing a script and running it is a normal way for a coding agent to make a network request, and Anthropic's engineer acknowledged the same gap in the Hacker News thread, as reported.
  • An encoding other than one pass of percent-encoding, a client the mod does not name, and a plugin hook installed above the mod, which can overrule its refusal.

Two users have also reported, in the issue thread itself, that on version 2.1.318 the mod shown as enabled did not refuse a plain test call of exactly the shape it documents, one on macOS and one on Windows. Anthropic has not confirmed or denied those reports in the thread; the contributor's reply remains the company's only response there. They are worth knowing about, and they are not yet findings.

There is a channel problem underneath this, and it is a different problem from the reporter's. The guard exists in 2.1.317 and later, but the stable channel was still serving 2.1.311 when checked on 7 November: Anthropic's own release manifest returns 2.1.311 for the stable channel, while the latest channel is at 2.1.319. Version 2.1.311 predates the mod entirely, so a user who never switched channels has no mod, no refusal and no indication that anything is missing. The November reporter was not in that position: 2.1.318 already included the mod, which is why the reports above raise a separate question about the mitigation itself.

What to do before the real fix lands

Update to a current release that includes the privacy mitigation, and verify its status against the release notes and installed configuration. Users should check their installed Claude Code version and whether the privacy mod is available and enabled. It can be switched off in user, --settings or managed settings, and by a server-side switch; a repository's settings cannot switch it off. Then assume the guard covers the one documented shape and nothing else. Those running automated web workflows can inspect requests to an endpoint they control to see whether their account email appears in outgoing headers. Such a test checks only the specific tool and request path exercised; it cannot establish that other tools, scripts or future requests are protected.

Anthropic has said it plans to remove the signed-in account email from the model's automatically supplied context in a subsequent release. That would address the reported source of this exposure more directly than the current matching rule. It would not prevent the model from using an email address supplied through another part of a conversation, file or tool result. As of the November 6 statement, the change was expected early the following week; its shipment and effectiveness still need confirmation.

Sources

  1. [1] GitHub issue #107757, "Bug Report: Privacy violation in User-Agent header", anthropics/claude-code, filed 5 November 2026 by a user on version 2.1.318, read in full for this article, including contributor poteat's reply and the two user reports that the enabled mod did not refuse the documented test shape, on macOS and on Windows.Read source
  2. [2] Privacy mod README, anthropics/claude-code, mods/privacy, read in full for this article: the two-word-match test, the refusal with no prompt, the exclusions, the off switches, and the mod's own summary, "a courtesy, not a boundary".Read source
  3. [3] Built-in mods index, anthropics/claude-code: the privacy entry describes a mod that refuses a shell call holding the signed-in account's email address and naming a User-Agent, "so the address does not go out as a client's contact details".Read source
  4. [4] Claude Code CHANGELOG, versions 2.1.317 to 2.1.319 read for this article: the 2.1.317 entry reads "Added a check that asks before a web or shell tool call sends your account email address to the network"; neither 2.1.318 nor 2.1.319 announces the removal of the account email from the model's context.Read source
  5. [5] "Claude Code was mailing your email address to every website it visited", dev.to, 6 November 2026: the mechanics of the July system-prompt report (issue #81138), with the injected line and bundle code, as reported.Read source
  6. [6] "Is Claude Code Handing Your Email to Every Site It Visits?", The Tech Lane, updated 8 November 2026: the Hacker News statements attributed to Anthropic engineer Lydia Hallie and the stable-channel version, as reported.Read source
  7. [7] "Claude Code email in User-Agent headers: how it happened and what the fix covers", Alan West, dev.to, November 2026: Hallie's statements and the changelog wording, as reported.Read source