For signed-in users, Claude Code put the account email into the model's context. The reason was mundane: Claude kept inventing names for things like @author tags, so it was given the real one. Then, when Claude wrote a curl or a script against a site that asks scripted clients for a contact address in the User-Agent (the SEC, Wikipedia), it sometimes used the one it had been handed. Your email could go to sites you never chose to tell. Anything in an agent's context is one tool call away from the network.
An engineer on the Claude Code team (lydia_hallie on HN) confirmed the mechanism in the Hacker News thread: "we added the account email in the model's context for signed-in users," and the model "sometimes put your email address in the User-Agent as a contact address." And, plainly: "this should not have happened."
The Mechanism
Nothing here is a bug in the usual sense. No header was hardcoded, no code path leaked a variable. The model had a fact and a task, and it put them together.
My read of why: the model was given your email so it could stop guessing who you are, and the site asked the client to say who it is. From inside the context window, those look like the same job. Putting the address in the User-Agent reads as identifying the user, which is exactly what the email was there for.
The timeline shows what didn't work. Per FourWeekMBA and the write-ups that collected the GitHub issues, the first report was in July. The response, in v2.1.234 in August, was to change the instructions so the email would only be used to identify the user. Reports kept coming in September and October, including one where the model sent the address even though its context told it not to send it to unrelated services. A sentence in the prompt is a preference, not a control. The model weighs it against everything else it reads, including whatever the page it just fetched asks for.
The One Proof
Version 2.1.317, out November 2, added what the changelog calls a check that "asks before a web or shell tool call sends your account email address to the network." Per the write-ups, it's narrower than that: it refuses shell calls that contain both your address and a User-Agent, and doesn't look at WebFetch, WebSearch or MCP tools. Anthropic is candid about its reach. From the same HN reply: "it still doesn't prevent all cases, like when Claude writes a script and runs on its own." The mod's README, as quoted there, calls it "a courtesy, not a boundary."
A filter on the way out has to recognize the secret in every shape it can take: a header, a query string, a JSON body, a value computed in a script the agent wrote a second ago. A model will produce shapes nobody listed. Anthropic says it is removing the email from the context Claude Code gives the model; I couldn't confirm that has shipped yet. That's the version that holds: the model can't send what it never saw.
The Check
Claude Code keeps session transcripts as JSONL under ~/.claude/projects/. Find the messages where your address and a User-Agent appear together:
EMAIL='you@example.com'
| | |
Each line is a transcript where a single message holds both. Open it and look at the tool call. No output means no hit in the transcripts you still have, not proof it never happened.
Then get to 2.1.317 or later. Per the write-ups, the npm stable tag still pointed at 2.1.311 as of November 6, so "I'm on stable" isn't an answer.
The Fix That Holds
Treat the context window like an outbox. Before something goes into it, ask whether you'd be fine with it showing up in a request to any site the agent might visit, because the model decides what goes where, not you.
- Don't hand it what it doesn't need. Your name and email, a production hostname, a customer ID, a token in an env dump. If the task doesn't require it, it shouldn't be in the session.
- Give it a contact you don't mind sharing. If you run agents that scrape sites with contact rules, tell them to use a role inbox or the project URL. Then the helpful behavior is harmless.
- Put the boundary outside the model. For agents that touch the network unattended, an egress allowlist at a proxy decides where requests can go, regardless of what the model wrote into them.
The tradeoffs are real. Take the email out and the made-up @author names come back. An egress allowlist breaks the open-ended research that makes agents useful, and you'll spend time maintaining it. And a confirmation prompt that fires often enough gets clicked through. I'd still take all three over a prompt that asks nicely.
The Class
This is the same object I wrote about yesterday from a different side: an approval saved as the command it approved, secret included. There, the agent's state leaked into the repo. Here, the user's identity leaked into the network. In both, something sensitive sat in a place the agent reads and writes freely, protected by a convention.
My bet is the same too. Identity is a primitive an agent environment needs, like approvals and secrets. Who you are should be something the environment discloses per destination, on purpose, not a string in the prompt that the model is trusted to keep to itself. Until then, assume the context is public and fill it accordingly.