Claude Code email in User-Agent: what happened, how to check
Claude Code's model put signed-in users' emails in User-Agent headers. What Anthropic confirmed, what is fixed, and how to check what your clients send.
Quick summary · TL;DR
- If you're signed in, the model knows your email, and that's the root of it. Claude sometimes wrote that address into the User-Agent of its own
curlcall or script, for sites that ask for a contact. Anthropic staff confirmed this on 2026-11-06. - Update past the stable channel for now. Anthropic staff say to run 2.1.317 or later, which has the check. On 2026-11-07 npm's stable tag still pointed at 2.1.311.
- The check is narrow, by its own README. It covers shell calls that name a User-Agent, and skips WebFetch, WebSearch, MCP tools and scripts. Staff say it "doesn't prevent all cases" and that the email leaves the model's context in the next release.
- A proxy won't scrub this. Inside an HTTPS tunnel a normal proxy only forwards bytes, so what your client puts in its headers is what the site gets.
While you are signed in to Claude Code, your account email sits in the model’s context. Writing its own curl call or script, the model sometimes put that address in the User-Agent as a contact. Anthropic staff confirmed this on 2026-11-06. Version 2.1.317 shipped a partial check, and the address is due to leave the context in the next release.
The person who filed issue #107757 (2026-11-05, Claude Code 2.1.318) says it happened during web searches and that scam email followed.
What the Claude Code email user agent leak was
Issue #81138 (2026-07-25, still open) quotes the 2.1.220 bundle. It shows the block Claude Code adds to the model’s context for signed-in users, with a userEmail line read from oauthAccount.emailAddress in ~/.claude.json.
An Anthropic engineer on Hacker News (2026-11-06) said the email went in because Claude invented names for things like @author tags. Some sites ask scripted clients for a contact, and when Claude wrote a command itself it sometimes supplied the address it had.
Which tool sent it is less clear. Staff point to model-written commands such as curl. One commenter had his own Claude scan his transcripts, and it reported 53 calls over 8 sessions, almost all from subagents writing their own curl -A, not WebFetch. No primary source shows WebFetch or WebSearch adding the email on their own.
Timeline: dates and versions
Release dates are npm publish times. On 2026-11-07 npm’s latest is 2.1.319 and stable is still 2.1.311, which predates the check.
What Anthropic has changed so far
The 2.1.317 changelog says it asks before a web or shell tool call sends your account email. The privacy mod’s README (published 2026-11-06) describes something narrower. It refuses, without a prompt, a Bash, PowerShell or Monitor call that holds the address and names a User-Agent. It calls itself “a courtesy, not a boundary” and lists what passes:
- WebFetch, WebSearch and MCP tools
- a
From:header, a URL or a request body - a script that holds the address, or
$(git config user.email)
Two commenters on macOS and Windows report that the mod was loaded on 2.1.317 and 2.1.318 and still let their test commands run, and a third saw the same on 2.1.319. Staff on Hacker News say the mod “doesn’t prevent all cases”, and that the email leaves the context in the next release, which the changelog does not list as of 2.1.319.
Why an agent writes contact info into a User-Agent
Because some sites ask for it. The Wikimedia User-Agent policy wants scripts to carry contact information, which can be an email, a website or a wiki user. EDGAR’s access page at the SEC (reviewed 2024-06-26) shows a company name plus an admin email.
HTTP has a header for exactly this. RFC 9110 section 10.1.2 says a robot should send From so its operator can be reached. It also says a user agent should not send From without explicit configuration by the user, because of privacy. Filling in a user’s address unasked is the case the RFC warns against.
Check what your own clients send
You don’t need the Claude Code email user agent bug to leak an identity, since any client sends whatever it was told to. Run a one-shot listener on loopback, point the client at it, and read the head.
python3 -c 'import socket;s=socket.socket();s.bind(("127.0.0.1",8765));s.listen();c,_=s.accept();print(c.recv(65536).decode());c.sendall(b"HTTP/1.1 204 No Content\r\n\r\n")'
curl -s http://127.0.0.1:8765/ # in a second terminalOn macOS on 2026-11-07, the listener printed these defaults:
- curl 8.7.1:
User-Agent: curl/8.7.1 - requests 2.32.5:
User-Agent: python-requests/2.32.5 - urllib on Python 3.9:
User-Agent: Python-urllib/3.9
To audit an agent, point its tool at the same address.
Set a neutral User-Agent
RFC 9110 section 10.1.5 asks senders to limit product identifiers to what identifies the product and warns that overly detailed values make fingerprinting easier. Keep it to a tool name and version, with no project or client names, which the same commenter found the model writes in too.
curl -A "mytool/1.0" https://example.com/requests.get(url, headers={"User-Agent": "mytool/1.0"})
context = browser.new_context(user_agent="mytool/1.0") # Playwright, not tested hereFor the rest of each client, see the curl proxy, Python requests proxy and Playwright proxy guides. Where a site needs a contact, a project page is safer than a personal inbox, and Web Bot Auth signs requests without one.
Proxies and headers inside HTTPS tunnels
A proxy can’t clean this up for you. For HTTPS the client sends CONNECT, and per RFC 9110 section 9.3.6 the proxy then only forwards bytes blindly. Unless it intercepts TLS with a certificate you installed, the request headers inside never pass through it in readable form. Whether the exit is datacenter proxies or residential, header hygiene is the client’s job.
Our own loopback run (curl 8.7.1, macOS, 2026-11-07) showed one more leak path. Given -A and -x, curl put the custom User-Agent into the CONNECT request to the proxy as well, while -H headers stayed inside the tunnel. That is what we saw, not documented behaviour. Wiring an agent through a proxy is covered in proxies for AI agents.
What Claude Code users can do now
- Update to 2.1.317 or later, since the stable channel lacks the check.
- Keep
cc-plugin-privacyenabled in/plugins. - Search your transcripts:
grep -rl 'you@example.com' ~/.claude/projects(put your address in; not run here). - Add your own PreToolUse hook if you want web tools and written scripts checked too.
Frequently asked questions
Sometimes, through the model. The signed-in account email sits in the model's context, and Anthropic staff say Claude sometimes put it in the User-Agent as a contact while writing its own command, such as a curl call. Staff confirmed this on Hacker News on 2026-11-06 and said it should not have happened.
Any signed-in version with the email in context, which issue #81138 shows in the 2.1.220 bundle. Versions before 2.1.317, including stable 2.1.311, also lack the check. The promised removal is not in the changelog as of 2.1.319, the latest on 2026-11-07.
Partly. 2.1.317 added a built-in mod, cc-plugin-privacy, that refuses shell calls holding your address and naming a User-Agent. Its README says it does not cover web tools, MCP tools or scripts. Staff said on 2026-11-06 the email leaves the model's context in the next release, due "early next week".
The reporter says it happened during web searches. Anthropic staff describe model-written commands like curl, and one commenter's transcript scan found almost all cases were subagents running curl -A, not WebFetch. No primary source shows the web tools adding the email themselves.
Run grep -rl with your address over ~/.claude/projects to search your local transcripts. For what a client sends right now, point it at a one-shot listener on 127.0.0.1 and read the request head.
So operators can reach whoever runs a script. Wikimedia asks scripts for contact information (an email, website or wiki user), and the SEC's EDGAR page shows a company name with an admin email. RFC 9110 puts robot contact in the From header and says a client should not send it without the user's explicit setup.
Not a normal one. In an HTTPS CONNECT tunnel the proxy only forwards encrypted bytes, so it can't read or change the headers unless it intercepts TLS with a certificate you installed. In our own curl 8.7.1 test, a -A value also appeared in the CONNECT request to the proxy itself. Fix the header in the client.
Researched and drafted with AI tools, then checked against our publishing rules before it went live: 8 outside links, 6 links to other proxymint pages, no prices and a fact-check pass against our product records. How we write.