A GitHub Issue Claims Claude Code Puts Your Email in the User-Agent Header. It Is Unverified. Here Is How I Would Check My Own Traffic.
On November 5, a user opened issue 107757 on the Claude Code repository titled "Bug Report: Privacy violation in User-Agent header". The claim: during web searches, Claude Code puts the user's email address into the User-Agent header, and the reporter links that to a flood of scam email. It hit the front page of Hacker News the same day. As of when I read it, the issue is open with labels but no comments from Anthropic.
What the report does and does not show
I would separate three things. The issue, filed against Claude Code 2.1.318 on macOS, says the email went out to third parties during web searches. It does not name the tool involved, does not include a captured request, and does not describe how the reporter found it. The header format, something like a session slug followed by the email in angle brackets, appears in a Hacker News comment by the same account that submitted the story. So the shape of the claim is a self-report, plus a link between the header and the scam email that is inferred, not demonstrated.
Nobody else has confirmed it in what I read. One commenter said Codex CLI sent no email, and noted they could not check OpenAI's hosted search, which makes that a weak comparison. I could not find an Anthropic statement, a fix or a changelog entry, and I have not reproduced the behavior myself.
Why I still care
Even if this turns out to be a misreading, the question underneath it is real. Agent CLIs run with your identity, your network and your keys, and a web search tool exists to send requests to servers you did not choose. A User-Agent string is one of the cheapest places for a client to leak something, and nobody reads those logs on your behalf. If you work alone, you are the privacy review.
It is also true that the email in the scam inbox could have come from anywhere. Addresses leak through breaches, public commits and mailing lists constantly. A correlation between "I used a tool" and "I got spam" proves very little, which is exactly why the report needs a capture, not an argument.
The ten-minute test
I would run a local intercepting proxy, point the agent at it through the standard proxy environment variables, trigger a web search and a web fetch, and read the User-Agent on the outgoing requests. mitmproxy does this, and so do Charles and Proxyman. Two practical notes: you may need to trust the proxy's certificate for the tool to connect over HTTPS, and a tool that bundles its own certificate store may ignore your settings, in which case that is itself a finding. Run the same test on every agent CLI you use, not only the one in the headline, because the interesting result is the comparison.
If the header contains your email, I would first check whether it is the address on the account you signed in with, and whether the request goes to the target site or to the vendor's own search backend. Those two facts decide whether this is a privacy bug or a design choice nobody documented. I would then add what I found to the existing issue, with the capture, because a reproducible report is the thing that gets fixed.
What I'd actually do
Today, run the test. If I cannot, I would assume the claim might be true and avoid using agent web search on an account tied to an address I care about, using a separate address for tool sign-ins. A throwaway alias costs nothing and makes the whole question moot.
I would not cancel anything or declare the tool unsafe on one report. I also would not wait for the vendor, because the check takes less time than reading the comment thread.
Where I could be wrong
The reporter may be right and the leak may be exactly as described, in which case a patch is likely coming and the test just tells you whether you were exposed. Or the header may be a session identifier with no email and a misread. Both are plausible from what is public. What I am confident about is the method: the claim is checkable, so check it.
Author
Lukas
@lukcombinator