Anthropic says it will remove signed-in users’ account email addresses from the context Claude Code gives its model. The planned change follows an acknowledgment that Claude sometimes copied those addresses into outbound User-Agent headers when generating requests to third-party websites.
In a November 6, 2026 Hacker News comment, lydia_hallie, who identified herself as working on Claude Code, said the change would arrive in the next release, expected early the following week. She also advised users to update to version 2.1.317 or later for an interim, default-on privacy mod.
The announcement describes a planned release, not a completed rollout. The account’s employment was self-identified in the public comment and was not independently verified in the available evidence.
The immediate takeaway is to update, but keep inspecting outbound requests and generated scripts. Anthropic’s published privacy-mod documentation describes a narrow check, and it differs materially from the broader protection described in the staff comment.
Why Claude Code Had the Account Email
Claude Code received the email address to help identify the person using it. According to the staff explanation, users had reported that Claude invented names for things such as @author tags. Anthropic added the signed-in account email to model context to reduce those mistakes.
Model context is information available to the model while it generates responses and tool calls. Putting an email there makes it usable across tasks, including tasks unrelated to identifying a code author.
The explanation described how that became a privacy problem: when Claude wrote a command, such as a curl request, it sometimes used the email as a contact address in the request’s User-Agent header. Some websites ask automated clients to supply contact information, and Claude sometimes filled that requirement using the address already available to it.
A User-Agent is HTTP request metadata commonly used to identify client software. If an email appears in that header, the destination receives it along with the request. The user need not have deliberately filled out a form or asked Claude to share their identity.
That mechanism requires no elaborate attack. A website’s request for contact information can be enough for an agent to reuse identity data supplied for another purpose. The acknowledged behavior concerns model-generated requests; the sources do not show that every Claude Code request included an email.
The proposed remedy targets the original input:
“We're removing the account email address from the context Claude Code gives the model.”
That is the central product change in the November 6 statement.
The Report That Brought Renewed Attention
A GitHub issue opened on November 5 alleged that Claude Code had disclosed the reporter’s account email to third-party websites in User-Agent headers without permission. The report listed macOS, the tmux terminal environment, and Claude Code 2.1.318.
The reporter also blamed the disclosure for receiving scam emails. That causal claim is unverified: the published issue does not independently establish where those senders obtained the address.
The issue timeline references an earlier report about a subagent sending an email from session context, so the latest discussion should not be read as proof that the behavior began in November.
The story circulated widely. Its Hacker News discussion drew more than 1,500 points and 500 comments. One commenter, T-R, reported catching a personal email in requests made while working with SEC data. Other participants debated whether website contact policies encouraged the behavior.
Those comments document individual reports and reactions. They are not representative testing of Claude Code, and they do not establish how frequently the disclosure occurred.
What Version 2.1.317 and Later Try to Block
The interim protection is a built-in mod called cc-plugin-privacy. A response in the GitHub issue timeline said it was introduced in 2.1.317, enabled by default, and intended to block the behavior.
The published privacy README describes a tool.check hook that examines inputs to Bash, PowerShell and Monitor calls. Its check looks for two things together:
- The signed-in account’s email address.
- Text identifying a
User-Agentsetting or a recognized client flag.
Recognized forms include common User-Agent spellings, curl -A, wget -U, and certain PowerShell web-command flags. The address can be matched regardless of letter case or when percent-encoded once.
The mechanism is deliberately simple. It searches the whole tool input for matching text instead of parsing the command and determining exactly where each value goes.
That choice catches some unrelated uses too. A command can be refused if it mentions both the email and a user-agent setting even when the email would be sent somewhere else, or when the relevant words are merely present in the input. The README explicitly accepts those false refusals in exchange for simplicity.
The Staff Comment and README Describe Different Behavior
The November 6 staff comment says the mod asks before a web tool call or curl-style command containing the email.
The README describes something narrower and more forceful: matching shell-style calls are refused without a prompt, regardless of permission mode. It also says WebFetch and WebSearch are not checked.
Those are meaningful differences. Asking permission, automatically refusing a request, and leaving a tool unchecked produce very different user experiences.
The available README is on the repository’s main branch, not pinned to the original 2.1.317 release. It therefore cannot settle exactly what every installed build does. It does, however, provide the clearest published description of the check’s mechanics and explicitly documented limits. This is analysis of those sources, not a reproduced test.
The Paths the Privacy Mod Leaves Open
Anthropic’s staff comment acknowledged that the mod could miss a script Claude writes and then runs. The README lists a wider set of uncovered paths.
| Request path | Documented limitation |
|---|---|
Email in a URL, request body, authentication argument or From: header | It can pass when no recognized user-agent setting is named. |
| WebFetch, WebSearch or MCP tools | These tools are outside the described check. |
| A generated script containing the address | Running the script by filename can leave its contents outside the inspected input. |
| A variable, runtime lookup or file sent by name | The address may not appear literally in the tool input being checked. |
| Other clients or header-setting methods | Unrecognized forms can escape the pattern match. |
| Other encodings | Coverage does not extend to every transformation or encoding of the address. |
The script example makes the boundary especially clear. A visible command may contain only a script filename, while the email and network-request code sit inside the file. A text check of the execution command cannot reliably inspect that later behavior.
The same problem applies when a command obtains an email at runtime. The README specifically identifies a Git configuration lookup as an example: the tool input can contain an instruction to retrieve an address without containing the address itself.
Frequently Asked Questions
3 questions
1Will Anthropic Delete My Account Email?
The announced change removes the email from context supplied to Claude Code’s model. It is not an announcement that Anthropic will delete the address from account records.
