Does Claude Code Send Your Email to Websites? What to Do

The questions are: does it really happen, why is my email in the context, which version fixes it, is the fix working, how do I check my sessions, and how do I protect myself today? Official facts, user reports and our opinion are kept apart.

Official facts

Checked on 6 November 2026. Anthropic has not published a news post on this; its statements are staff comments on GitHub and Hacker News, so we label them as such.

Item	Fact	Source
Cause, per Anthropic staff	Claude Code adds the account email to the model's context for signed-in users; when Claude writes a command itself, it sometimes puts it in the User-Agent as a contact address	HN comment by lydia_hallie
Fix 1, in 2.1.317	Built-in mod cc-plugin-privacy, on by default; the changelog says it "asks before a web or shell tool call sends your account email address to the network"	changelog
Fix 2, announced	Remove the account email from the context in the next release, "early next week"; no version number given	HN comment
Release channels, 6 Nov	stable serves 2.1.311, latest serves 2.1.318	downloads.claude.ai stable, latest
Channel meaning	stable is typically about a week old and skips releases with major regressions; latest ships immediately	setup docs

Does Claude Code really send my email to websites?

Yes, in some cases, and Anthropic staff say so. The issue's author (taylor-edwards, Claude Code 2.1.318 on macOS) reports a User-Agent header carrying their address during web searches and says they get dozens of scam emails a day. A Hacker News poster showed the shape: a header like my-session-slug/1 <my.name@example.com>. An earlier report, issue 101659 (13 October 2026, version 2.1.285), shows a research subagent running curl -A "...(<email>)" against liquipedia.net, which answered 403; the model added the contact because that site asks API clients for one.

Anthropic's explanation (staff replies, 5 and 6 November): it is not a designed feature but a model behaviour. In the words of mpoteat, "Claude apparently tends to decide that this policy is worth following". It does not happen on every request; it happens when a site asks for a contact and the address is in context.

Why do sites ask for an email?

Because their own rules ask scripts to identify themselves. The Wikimedia User-Agent policy says scripts should send an informative User-Agent "with contact information", given as an email address, a website or a wiki user. The SEC's webmaster FAQ asks callers to "declare your user agent" and shows a sample with a company name and an admin contact address. A human running a bot should do that on purpose, with an address meant for it. The problem here is a model picking your personal one.

Why is my email in the model's context?

Anthropic's answer: users had reported Claude hallucinating names for things like @author tags, so the account email was added for signed-in users. A July issue (81138) already described the injection: the reporter, after reading a shipped build, says it comes from the oauthAccount.emailAddress field in ~/.claude.json, has no setting to turn it off, and that the model once wrote the address into git commits. An April issue (53231) asked for an opt-out; it was closed on 25 April. We have not read the code ourselves; on our own server the field is present in ~/.claude.json (check below).

Which version fixes it?

Two layers, and neither is complete today:

1. 2.1.317 and later: the shell check. Present in the changelog entry of 2.1.317. Anthropic's staff say it is on by default.
2. Next release: email out of the context. Announced, not shipped when we checked. That one removes the cause rather than blocking one symptom.

The catch: on 6 November the stable channel still serves 2.1.311, per Anthropic's own download endpoint and the staff comment ("update to 2.1.317 or later"). If you left the default stable channel in place, or installed with the Homebrew claude-code cask (which tracks stable), you do not have the check. Switching means setting "autoUpdatesChannel": "latest" in your settings (or the claude-code@latest cask), as the setup docs describe; note that latest also means getting other new builds immediately.

What does the privacy mod block?

The mod's own README is blunt: it is "a courtesy, not a boundary, and it covers one shape".

• Refused: a Bash, PowerShell or Monitor call whose input contains your address (any case, or percent-encoded once) and names a User-Agent (User-Agent, --user-agent, curl -A, wget -U, UA=). The refusal raises no prompt.
• Not checked: WebFetch, WebSearch and MCP tools; the address in a URL, a request body, curl -u or a From: header; a value computed at run time such as $(git config user.email); a script that already holds the address; other clients or ways of setting the header.
• Turned off by: /plugin disable, or "cc-plugin-privacy@builtin": false under enabledPlugins in user or managed settings.

One mismatch is worth noting. The changelog says the check "asks before" a web or shell call; the README says shell calls are refused with no prompt and that WebFetch and WebSearch are not checked. We could not tell which describes the shipped 2.1.317 build; the staff comment says it "asks you before Claude runs a web tool call or a curl-style command".

Is the privacy mod working?

Unclear. Anthropic says it is on by default from 2.1.317, but three users report otherwise (next section): a test command was not refused, and the mod did not appear in /plugins for two of them on 2.1.318. We could not test it. To see whether it is active, open /plugins and look for cc-plugin-privacy marked as built-in; if it is missing on 2.1.317 or later, say so in the issue.

What users report

These are user statements, not verified facts. Reddit blocks our tools, so this covers GitHub and Hacker News only.

• The fix may not fire. In the issue, love540 reports that on macOS the mod did not refuse an echo 'User-Agent: test <account email>' command on the 2.1.317 desktop app or on 2.1.318 in a terminal, even though /plugins showed cc-plugin-privacy enabled. BigBalli wrote that on 2.1.318 the mod was not listed and "logs confirmed my email was sent to other domains", and francescor could not see it in /plugins either. Anthropic had not answered these when we checked.
• A workaround from a user. xSetech shared a CLAUDE.md section that allows the address in a User-Agent only for an approved site list and otherwise asks first. It relies on the model following it, which the July issue argues is the weak point.
• Spam stories. tobinfekkes (GitHub) and mk89 (Hacker News) say spam jumped after they started using Claude. Others doubt a link: crazygringo wrote it "almost certainly" does not explain it, b112 uses a unique address per site and saw none, and copirate says few sites harvest User-Agent addresses. Nobody has shown the chain from a header to a spam list.
• Not the first report. The same problem was raised on Hacker News on 24 October and 29 October, and in the July and October issues above. AlexErrant argued that the July report took five months to produce a fix; Anthropic staff wrote that they were aware "a few days ago" from Reddit.
• Other agents. matheusmoreira said that Codex does not do this, based on asking a model; other commenters (lukan, hendiatris, cadamsdotcom) objected that a model's answer is not a check and suggested pointing the agent at a local web server and reading its log. We did not test Codex.
• A question nobody answered. ConnorJC3 asked why the model gets the address at all. Anthropic's later reply (the @author reason) answers it for the context, but not why it was on by default and undocumented.

How do I check my own sessions?

Claude Code keeps session transcripts under ~/.claude/projects/ as .jsonl files. A plain search for your address is useless: it is in the context of every session, so every transcript contains it (1,160 of ours do). Search for it next to a User-Agent flag instead. This needs GNU grep (-P); on macOS use ggrep from Homebrew or ripgrep, which we did not test.

EMAIL="you@example.com"   # your Claude account address
grep -rlP -i "(user-agent|curl.{0,80} -A|wget.{0,80} -U).{0,200}${EMAIL}" \
  ~/.claude/projects --include='*.jsonl'

A file name in the output means a command in that session had your address after a User-Agent flag. It does not tell you the request went through or which site got it; open the file and look. It also finds shell commands only; the WebFetch and WebSearch tools do not show their headers.

On our own server this printed 4. The files are transcripts of our own agents (modified 17, 24, 24 and 28 October), and the matches are curl -s -A "<tool name>/1.0 (<address>" commands that our agents wrote. We did not inspect which sites received them, and Anthropic has not said which versions were involved. The server runs 2.1.302, below the fix, on the default channel. The point is not that we were "hacked"; it is that the behaviour in the issue is easy to find in real transcripts.

How do I protect myself until the fix?

None of these is a guarantee. Steps 1 and 2 come from Anthropic's statements and docs; the rest are our own reading.

1. Update past 2.1.317 now. Run claude --version. On the stable channel, move to latest as above, then update to the release that removes the email from the context when it ships. Anthropic says stable users are not covered by the check.
2. Keep the check on. Do not disable cc-plugin-privacy. It only covers one shape, so keep reading what runs.
3. Do not auto-approve network commands. The permissions docs show deny rules for curl and wget plus an allow rule such as WebFetch(domain:github.com). Note the docs' own warning: a deny rule does not match the same program by path or inside sh -c, so pair it with the sandbox allowlist if it must hold. The sandbox restricts which hosts a command can reach, not what headers it sends, so for this issue it only limits who could receive the address.
4. Add a CLAUDE.md rule like the one xSetech posted. It can reduce the behaviour but is not a control: it governs use, not presence.
5. Review web commands before they run, especially anything with -A, -H or a User-Agent.
6. If you are exposed already, treat the address as public: expect more phishing, use a mail alias going forward if your setup allows it (we did not check whether the account email can be changed), and tell your security team if this is a company account.

Does demo mode hide my email from the model?

Not according to the July issue. The docs say IS_DEMO "hides your email and organization name from the header and /status output". The issue's author read the shipped build and says its gates guard display only, not what the model is given. That is one user's reading of a build from July (2.1.220), not a current test; we did not try it.

Does Codex do the same?

Unknown. One commenter says no; the method was a model's own answer, which others rightly questioned. If you use Codex or another agent with a signed-in account, a local web server that logs request headers (see Our take) is the reliable way to find out.

Has this been reported before?

Yes: April (issue 53231, the injection), 25 July (81138, the injection and commits), 13 October (101659, a subagent's User-Agent), and Hacker News threads on 24 and 29 October. The 5 November issue is the one that went viral.

Our take

• The cause is a design choice, not just a model quirk. If the address was never in the context, no model could leak it. Anthropic's own plan, removing it, is the right fix; the shell check is a stopgap, and its README says so.
• "Alignment is hard" does not fit this case well. The model followed a real site policy with data it was handed. The control that mattered was what the model gets, and the July issue had asked for exactly that.
• Whether it caused anyone's spam is unproven. Take the timing stories seriously as signals and not as evidence. A header only reaches the site you called.
• If you run agents in a company, treat any personal data in the context as outbound data. Test with a local server that logs headers: it takes a minute and works for any agent.
• Related: the same lesson applies to what an agent can install or call; see our guides on a hostile Claude Code extension and an agent plugin added by another app.

What we did not test

• We did not reproduce the leak, and we did not test whether the mod blocks anything on 2.1.317 or 2.1.318; our server runs 2.1.302.
• We did not verify that the next release removes the email; it was not out when we checked. The "early next week" timing is Anthropic's, not ours.
• We did not test Codex, other agents, IS_DEMO, the ripgrep variant of the search, or whether the account email can be changed.
• We did not find out which sites received the 4 commands on our server.
• Every comment quoted above is unverified. Reddit was not reachable.

FAQ

Does Claude Code send my email address to websites?

Sometimes. Anthropic staff say the account email is in the model's context and that, when Claude writes a curl command itself, it can put that address in the User-Agent because some sites ask scripts for a contact. It is model behaviour, not a feature, and it does not happen on every request.

Which Claude Code version fixes the email leak?

A shell check shipped in 2.1.317, and Anthropic says the email will leave the context in the next release (early next week). On 6 November the latest channel was 2.1.318 and the stable channel was still 2.1.311, so stable users do not have the check yet.

How do I check my Claude Code version and channel?

Run claude --version. The autoUpdatesChannel setting in your settings file controls stable or latest (default is the one your installer chose; Homebrew uses the cask name). The setup docs explain both.

Is the Claude Code privacy mod working?

Anthropic says it is on by default from 2.1.317, but users on 2.1.317 and 2.1.318 report it did not refuse a test command and, for some, did not show in /plugins. Its README says it covers only shell commands that name a User-Agent next to your address.

How do I stop Claude Code from using my email?

There is no documented setting. Update to 2.1.317 or later, keep the built-in mod on, do not auto-approve curl and wget, and wait for the release that removes the address from the context. A CLAUDE.md rule helps but depends on the model.

Is this why I get spam?

Not shown. Some users link their spam to it, others did not see any on a unique address, and a header only reaches the site that received the request. Treat the address as exposed if your sessions contain it after a User-Agent flag.

Is Claude Code safe to use?

For this issue, the risk is a personal email going to sites the model contacts. If your rules forbid that, wait for the release that removes the address, or use network deny rules and review every web command.

Related guides

• Claude Code extension backdoor: are you affected? for how to check your editor and agent for a hostile extension.
• Postman plugin in Claude Code and Codex: how to remove it for another case of config changed behind your back.
• Terraform MCP server: setup, tools and safe use for running an MCP server with limited access.

Sources

• GitHub: anthropics/claude-code issue 107757 (opened 5 Nov 2026, 40 comments read 6 Nov), 81138, 53231, 101659.
• Anthropic: Claude Code changelog, privacy mod README and hook source, setup docs, permissions docs, environment variables.
• Hacker News: Claude Code sends your email address to websites (5 Nov 2026), 24 Oct thread, 29 Oct thread.
• Site policies: Wikimedia User-Agent policy, SEC webmaster FAQ.
• Google autocomplete suggestions for "claude code privacy", "claude code email" and "claude code stable channel" (6 Nov 2026).

Update log

• 6 November 2026: first version, from the GitHub issue (40 comments), Anthropic staff replies, the changelog, the mod README and our own read-only checks. We will update it when the release that removes the email from the context ships, or if Anthropic answers the reports that the mod did not fire.

Last verified: November 2026 (6 November 2026). Software behaviour and vendor statements change; we will update this page and the log above.

Header image: Image: DevOpsCompass.