Is Claude Code leaking your email in User-Agent headers?

• Acknowledged: a Claude Code team member says the model sometimes copied the account email from its context into a curl User-Agent. Read the response.
• Observed: five different email-bearing User-Agent strings requested our aocr article on 31 October. The addresses were already redacted in the records we queried.
• Not proven: that Claude Code generated those five requests, that the addresses were personal, or that they were sent without permission.
• Still limited: Anthropic has shipped a safeguard, but its own documentation says it does not cover scripts and several other routes out.

When a browser or a program asks a website for a page, it sends more than the page address. It also sends headers: named fields that describe the request. A header can say which formats the program accepts, which page linked to it, or which software is making the request.

User-Agent is the software label. An ordinary command-line request might identify itself as curl/8.7.1. A custom scraper can set its own value. Here is a simplified example, not a real address:

GET /blog/aocr-org-referrer-bot HTTP/1.1
Host: tin.computer
User-Agent: ResearchReader/1.0 (contact: [email protected])

The site receives the email even if the visitor never fills in a form, accepts a cookie or runs JavaScript. Its server or CDN may record the header in a log. HTTPS protects the request on its way to the site; it does not hide the header from the site receiving it.

On 5 November, a user reported that Claude Code sent their email to third-party sites during web research. They listed version 2.1.318 on macOS. They also attributed an increase in scam emails to the disclosure. That causal link is their claim; the report does not establish where the scammers obtained the address.

The Hacker News discussion brought the report wider attention. On Reddit, users had already described the same problem with Wikipedia requests and an SEC filing download. These are user reports, not independent measurements of how often it happens.

On X, the discussion includes both broad warnings and more careful descriptions of the safeguard. Cobalt's breakdown points out the gap between the release messaging and the published implementation. We used the implementation to check what the mod actually promises.

The underlying concern is older. A 25 July GitHub issue documented the account email being inserted into model context and reported it appearing in generated output and Git commits. That report concerns the same source of personal data, though it is not itself a reproduction of the November web requests.

In the Claude Code team's response on Hacker News, Lydia Hallie explains that account emails were added to model context to reduce invented names in author tags. When the model wrote a network command, it sometimes reused that address as contact information.

Some sites ask automated clients to identify themselves. Wikimedia's policy asks for a descriptive User-Agent and contact information, which can be a website or a user page as well as an email. That is not permission to use someone's private login address.

The failure can happen in a command or script the agent creates for the task. It does not require every request made by Claude Code to carry an email. A site's request for a contact address can explain the model's choice without making that choice acceptable.

We queried Tin Analytics' retained request records for tin.computer. On 31 October, between 13:20 and 15:46 UTC, five different User-Agent strings fetched our aocr.org crawler investigation. Each contained a redacted email.

Three of the five also requested /robots.txt immediately before the article. We did not find that preceding request for NorthstarResearch or Earthshine in this query. These are five tool names and eight request rows, not a count of five identified people.

Two of the recorded headers show the pattern clearly:

timing-research/1 (contact: [redacted])
NorthstarResearch/1.0 (personal research reader; [redacted])

The names and descriptions are consistent with research tools reading a shared article. They do not establish that a model invented the names, that the tools were used only once, or that Claude Code was involved. A company crawler can deliberately publish a contact address in exactly this way.

We also checked 27 October through 5 November UTC on tin.computer and clawmessenger.com. EYEWORLD-Python-Research/first20 appeared with a redacted contact address on both sites: three requests to Tin and eight to Claw. On 27 October, daytona-signal-engine/0.1 made 11 requests to Tin, including /careers and /jobs, with the same contact-address pattern.

Our query used the stored, sanitized User-Agent field. We did not recover the addresses or try to identify the people behind them. Redaction protects this report; it does not undo the original transmission to the receiving server.

For 27 October through 5 November UTC, we counted requests whose User-Agent starts with Claude-User (claude-code/. There were 71 on tin.computer and 204 on clawmessenger.com. None of those 275 headers contained an email address or an email-redaction marker. One recorded value was:

Claude-User (claude-code/2.1.318; +https://support.anthropic.com/)

That string contains no email. It illustrates the distinction between the standard client label and a custom header written for a task. The absence of an email in that header does not prove that the request carried no personal information elsewhere.

Not every email-bearing header is a leak. The records also include established crawlers with redacted contact addresses. Even Anthropic's crawler-style ClaudeBot/1.0 and Claude-User/1.0 strings can carry a contact address. Those are different from the Claude-User (claude-code/…) form counted above.

We cannot infer the model, the prompt, the software version or consent from the custom tool names. We also cannot count unique exposed email addresses after redaction. Our evidence establishes the receiving side of the pattern, not how common unauthorized disclosure is across Claude Code users.

Anthropic says cc-plugin-privacy is enabled by default in version 2.1.317 and later. Its published README describes a check for certain shell tool inputs that contain both the account email and a User-Agent reference. It says matching calls are refused without a prompt. The release notes describe a broader check that asks before web or shell calls send the email. The published mod documents a narrower scope; we cannot treat that release wording as proof that every route is covered.

The README calls it a courtesy, not a boundary. It explicitly excludes WebFetch, WebSearch and MCP tools, scripts containing the address, values computed at runtime, and emails sent without a User-Agent reference. It is not a general filter for personal information leaving the machine.

Some GitHub commenters report the mod missing or failing their tests on 2.1.318. We have not reproduced those tests. The team's 6 November response says it will remove the account email from model context in the next release, expected early the following week. That is an announced change, not a fix we have verified as shipped.

• Check the version and mod. Run claude --version and look for the built-in privacy mod in /plugins. Updating to a version with the mod does not remove its documented limits.
• Read outgoing commands and scripts. Look at custom headers, URLs and request bodies before allowing network access. A plain-looking script invocation can hide the request in the file it runs.
• Choose the contact yourself. If a site needs contact details, provide a public project address or contact page that you have approved and that meets the site's policy. A login address should not be the agent's default.
• Keep site logs out of public examples. If you find an address in incoming headers, redact it before sharing evidence. A string in a log is neither proof of consent nor proof of which model sent it.