Claude Code Can Send Your Email to Websites. Is It Fixed?
Claude Code can put account emails in outbound headers. What the engineer response, privacy mod, and release notes actually establish about the fix.
Claude Code Can Send Your Email to Websites. Is It Fixed?
A Claude Code engineer acknowledges that generated network commands sometimes put a signed-in user's email address in a User-Agent header. An interim safeguard is not comprehensive protection, and a promised change is not a verified rollout. Before assuming the issue is fixed, separate what the model knows, what a tool sends, and what the receiving website can record.
By OpenVeil Editorial. Published November 8, 2026. Research cutoff: November 8, 2026.
OpenVeil Editorial analyzes AI privacy boundaries using public sources. We reviewed the issue, engineer response, changelog, and published safeguard documentation; we did not reproduce the behavior or inspect anyone's private traffic.
What Is Confirmed
GitHub issue #107757, opened November 5, reports email disclosure during web research on version 2.1.318. The reporter also links it to increased scam mail. That causal connection is an allegation, not an established finding.
In a first-person Hacker News response, Claude Code engineer Lydia Hallie explains that account email was added to model context to help identify the user. When writing commands, the model sometimes used it as a contact address. She says the team is removing it from context in a forthcoming release and acknowledges gaps in interim protection.
The official changelog lists a network-email check under 2.1.317. The source reviewed for this article ends at 2.1.319; it does not confirm delivery of the promised context-removal change.
What Is Still Unclear
The public discussion does not establish a complete affected-user count, a list of recipient sites, or proof that every generated request contains an email. We have not independently verified a complete fix on an installed build.
The main Hacker News discussion showed 1,596 points and 522 comments when checked. Those numbers demonstrate attention, not the number of exposures or victims.
Do not turn this into a claim that Claude routinely sends every conversation to arbitrary websites, that an account password was disclosed, or that the reporter's spam must have come from this mechanism. Each would require additional evidence.
Why a User-Agent Can Become a Privacy Disclosure
The User-Agent header identifies the software making an HTTP request. Its contents travel to the receiving service; they are not confined to the chat window.
If a personal address is inserted into such a header, the destination can receive that identifier alongside the request. Whether it is logged, retained, shared, or later abused is a separate question requiring evidence from that destination.
Some sites legitimately request a contact for automated access. For example, the SEC's EDGAR access guidance asks automated clients to declare a User-Agent and illustrates a company contact address. That is not permission for an assistant to select a user's private account email without appropriate authorization.
A service's access rules and a user's disclosure decision are different boundaries. If no acceptable contact is authorized, the correct outcome may be to stop that request and ask—not silently invent an identity or repurpose a private one.
The Interim Privacy Mod Has Important Limits
The published privacy mod README describes a narrow tool-input check. It refuses certain shell-related calls when their input contains the account address and a recognized User-Agent pattern. It explicitly calls the mechanism a “courtesy, not a boundary.”
The documentation excludes several paths, including web and MCP tools, some computed values, and scripts holding the address. It also documents conditions that can disable or override the check. This is not a general outbound-data filter.
There is a wording difference worth preserving: Hallie's earlier explanation and the changelog describe asking before certain calls; the current README describes refusal without a prompt for matching inputs. Do not assume those descriptions prove identical behavior in your installed version and configuration.
Removing a known identifier from model context and checking a tool invocation solve different problems. Neither should be presented as verified protection for every possible source of identifying information.
A Practical Review: Context, Command, Recipient
Our original worksheet separates the three stages an AI privacy review needs to examine. It is a review aid, not a reproduced test of Claude Code.
| Stage | Question | Evidence worth checking |
|---|---|---|
| Context | Which identity or sensitive values are available to the assistant? | Documented session inputs, configured identities, and approved local sources |
| Command | Which values does the proposed tool call actually transmit? | The request, generated script, headers, URL, and body—not only the assistant's summary |
| Recipient | Who receives the request, and under what retention rules? | The destination, permitted purpose, service policy, and authorized request records |
A tool call can look harmless because the page being fetched is public. That does not mean the request contains no private metadata. Conversely, a model knowing an email address does not establish that a particular request transmitted it.
For a meaningful conclusion, connect the actual value to the actual request and recipient. Keep “available,” “proposed,” “sent,” and “retained” as separate states.
What to Check Before Your Next Agent-Assisted Web Task
First, identify the version and release channel you are running. Read its verified release notes rather than assuming an auto-update or a future-release promise has already changed your setup. Check whether your organization's configuration alters the available safeguards.
Second, decide which contact identity, if any, is approved for automated requests. For professional work, a deliberately configured organization contact may be appropriate when the destination's policy requires one. Do not use somebody else's address, fabricate an identity, or treat a public site as permission to send extra personal information.
Third, review generated network operations and scripts before allowing them to run. An instruction saying “do not disclose my email” can express your preference, but it is not equivalent to enforcement at the network boundary.
For stronger assurance, have an authorized administrator evaluate the relevant execution and egress controls. A check that inspects a command string is not automatically a check of every request that a later program creates. Do not disable TLS verification, expose credentials, or route private traffic through an untrusted inspection service to investigate this issue.
Finally, if you need a demonstration, use a disposable environment, a synthetic identity, and a receiver you own or are explicitly authorized to test. Record the exact build, configuration, request path, and observed result. A successful result for one path is not proof that unrelated paths are covered.
If You Think Your Address Was Already Sent
Preserve relevant evidence you are authorized to access: the request time, destination, proposed command or script, and minimal redacted output. Avoid posting your full traffic captures, account tokens, or private work context in a public issue.
Ask the provider a precise question about the version and path involved. If a destination received personal information, its own handling and deletion process may matter separately. A local configuration change cannot be assumed to erase records already held elsewhere.
An email address is not a password. Do not automatically conclude that an account was taken over. Remain alert to unsolicited messages, and verify unexpected sign-in or support requests through known channels. If credentials or authentication material were also exposed, follow your organization's incident-response process for that specific evidence.
Where OpenVeil Fits—and Where It Does Not
OpenVeil is an 18+ hosted AI workspace for chat, search, files, voice, and creative tools. It keeps private-chat history in the browser and maintains no server-side chat-history record for private chat sessions. It does not use prompts, uploaded content, or AI outputs to train foundation models.
Active requests still require processing by OpenVeil and necessary providers. Account and billing records remain separate. Browser-local history can be lost when browser data is cleared or unavailable on another device.
Those boundaries can fit adults who want hosted conversational help without an ordinary server-stored chat archive. They do not make OpenVeil a Claude Code patch, an email-redaction gateway, or a guarantee against identifiers appearing in every possible outbound path. Do not infer an equivalent privacy control merely from a different product label.
Use our AI privacy-claim checklist to compare specific controls. Read what browser-local history actually covers and how search-enabled AI sends information to providers.
If the documented hosted-workspace boundary fits your task, review OpenVeil's privacy policy and create an account for a ten-action, no-card preview. Paid plans start at $10 per month. Begin with non-sensitive material and keep your organization's sharing rules in view.
Frequently Asked Questions
Is the email issue fully fixed?
We have not verified a complete rollout. Distinguish a released mitigation from a promised design change and a tested result in your environment.
Does this prove the email caused scam messages?
No. Timing alone does not establish the source of an unsolicited-message campaign.
Does a website asking for contact information authorize disclosure?
No. Site requirements do not decide which private identity a user has approved for disclosure. Resolve that choice explicitly before making the request.
Will deleting local chat history remove a recipient's request logs?
Do not assume so. Local history and a destination's records have different owners and controls.
Is a prompt telling the model not to leak information sufficient?
Treat it as an instruction, not proof of enforcement. Important restrictions need controls and verification appropriate to the actual execution path.
Bottom Line
AI privacy includes what leaves the tool, not just what stays in chat history. Review the identity available to the assistant, the actual request it creates, and the recipient's handling separately. Call a fix verified only when the relevant release and behavior have been checked.
Sources
- Claude Code issue #107757, user report.
- Lydia Hallie's first-person response, mechanism and planned response.
- Official changelog and privacy mod README, reviewed at the research cutoff; these source files can change.
- MDN User-Agent reference and SEC automated-access guidance, technical context.
- Hacker News discussion, public-attention evidence, not a victim count.
Research cutoff: November 8, 2026. The worksheet and testing recommendations are editorial analysis, not an independently reproduced exploit or a universal protection guarantee.