Claude Code Email Leak: Who's Affected and What to Do Now

The Claude Code email leak hit #2 on Hacker News this week, with 1,507 points and 472 comments. The trigger was GitHub issue #107757, opened November 5 by a developer on version 2.1.318. They say Claude Code sent their account email to arbitrary 3rd parties in the User-Agent request header while conducting web searches.

It's real. Anthropic confirmed it.

A real fix isn't out yet, though. The built-in privacy mod that's supposed to stop it misses whole classes of the problem, and we can show exactly where. Here's who's exposed, what the mod really checks, and what you can do before the fix ships.

We read the issue thread, the release notes, the mod's source and Anthropic's replies on Hacker News. We haven't reproduced the leak ourselves.

What the Claude Code Email Leak Actually Is

When Claude Code fetches a web page with curl or writes a script that does, it picks a User-Agent string. Sometimes it puts your account email in it. That's the whole Claude Code User-Agent email problem. Servers log User-Agents, so your address ends up in logs you'll never see.

Why would a coding agent do that? Anthropic's Lydia Hallie explained on Hacker News that the account email was added to the model's context to stop Claude inventing fake @author names. The model then reused it in places it didn't belong.

It's not new, either. Issue #78431, an earlier report of the same behavior, was opened July 17 on v2.1.212 and closed in September. One commenter on the new issue went back through their logs and found 53 such calls across 8 sessions, from August 9 to November 1.

The original reporter also says they now get dozens of scam emails per day. That's their claim. Nobody has shown the leak caused it.

Technical Breakdown: What cc-plugin-privacy Really Blocks

In the thread, contributor poteat pointed to a built-in mod called cc-plugin-privacy. They said it blocks this behavior from v2.1.317 onward, is on by default, and can be switched off under /plugins. That's the closest thing to a Claude Code privacy setting for this right now.

The v2.1.317 release notes (November 3) describe it as a check that asks before a web or shell tool call sends your account email address to the network. So it's described as a prompt. The source code just refuses the call.

Here's the part most write-ups skip. The rule lives in mods/privacy/hooks/outbound/names-user-agent.ts. It refuses a shell call only when both of these appear in it:

your signed-in account email, plain or percent-encoded
a User-Agent marker: user-agent, user_agent, UA:, UA=, curl -A, wget -U, or a -UserAgent/--user-agent flag

That's a narrow net. It doesn't catch:

Other headers. Put the email in From: or a custom header and the rule never fires.
Scripts written first, run later. A commenter showed Claude writing mailto:<email> into a Python file with the Edit tool, then running python3 fetch.py. The shell call contains neither the email nor a marker.
Other addresses. Only the account email is checked, so the one in your git config isn't.

That explains some of the bypass reports. Others are stranger, because the rule should have caught them. Users on 2.1.317 and 2.1.318, on macOS and Windows 11, said the mod loaded but didn't stop curl -A or an echo 'User-Agent: …' call. Two others couldn't find the mod at all on 2.1.318.

There's one more catch. Hallie said the stable channel is still on 2.1.311, which predates the mod. If you're on stable, you have no check at all.

When the Claude Code Email Fix Lands

The fix that matters is removing the email from the model's context. Hallie said that's coming in the next release, which should arrive early next week. She also admitted the mod still doesn't prevent all cases, like when Claude writes a script and runs on its own.

No release note we've seen says the email's been removed yet. Issue #107757 is still open, labeled bug and area:security.

Real-World Use Cases: Who Should Care

Agencies and freelancers. Claude doesn't only leak your email. One commenter found it inventing User-Agents from project and client names, like <project-name>-site-build/1.0. That can tell a third-party server who your client is.

Anyone scraping or calling third-party APIs. Every request to a site you don't control is a log line you can't delete.

Teams on company accounts. A work email in a stranger's logs is phishing material. It also tells them which company uses which tools.

People on the stable channel. You're the most exposed and the least likely to know it.

Hard Limitations and Flaws

The mitigation is a string match. It looks for two patterns in one shell command. Anything indirect slips through.

The docs and code disagree. The release note says asks. The code refuses. Small, but it doesn't build confidence.

The fix is a promise. Early next week isn't a version number. Check the release notes before you relax.

Third-party guards aren't audited. There's also whoami-guard, a hook whose author says it cut leaks from 8 in 60 runs to 0 in 60. That's self-reported, and we haven't reviewed the code.

Verdict: Your Developer Action Plan

Check your version. Run claude --version; below 2.1.317, you don't have the mod. Update to 2.1.317 or later, which means leaving the stable channel until the fix lands.
Confirm the mod is on. Open /plugins and look for cc-plugin-privacy. Two users couldn't find it.
Add your own hook. PreToolUse hooks are an official feature, and exit code 2 blocks the tool call. A blunt version that catches more than the built-in mod:

#!/bin/sh
# ~/.claude/hooks/no-email.sh
# Blocks any Bash, Write or Edit call that contains your email.
# Misses percent-encoded or split-up addresses.
EMAIL="you@example.com"
if grep -qiF "$EMAIL"; then
  echo "Blocked: tool call contains account email" >&2
  exit 2
fi

Make it executable with chmod +x ~/.claude/hooks/no-email.sh, then add this to ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/no-email.sh" }]
      }
    ]
  }
}

Covering Write and Edit is the point. That's the path the built-in rule misses.

It's blunt on purpose, and that has a cost. It'll also block legitimate edits, like adding yourself as author in a package.json. Make those edits by hand, and know that a hook that times out doesn't block unless you set onFailure: block.

Audit what already went out. Claude Code keeps session transcripts as JSONL files under ~/.claude/projects/. This lists the sessions that mention both your email and a User-Agent:

grep -rlF --include='*.jsonl' "you@example.com" ~/.claude/projects | xargs grep -liE 'user-agent|user_agent|curl -A|wget -U'

Open those files and check which domains the requests hit. If client names show up in made-up User-Agents, tell the client.

Watch the release notes. When a version says it removed the email from context, update and test it.

The bug is small. The fix is easy. Until it ships, the built-in guard only checks one door, so lock the others yourself.

Claude Code Email Leak: Who's Affected and What to Do Now