# Claude Code Allegedly Put a Real Email in User-Agent **Summary:** A sparse GitHub report alleges Claude Code put a user's real email in an HTTP User-Agent header; my read is that agent tools need separate approval for the data leaving the machine. - Canonical: https://markhuang.ai/news/claude-code-user-agent-email-permission-gap - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-11 - Section: News - Tags: AI, Claude Code, Privacy, Developer Tools, Agent Security - Source: [GitHub Issue](https://github.com/anthropics/claude-code/issues/78431) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![An AI coding agent sends layered network metadata toward a server with one unexpected personal identity token inside the request](https://cdn.markhuang.ai/news/claude-code-user-agent-email-permission-gap/hero.webp) *Approving the connection answers where the agent may go. It does not necessarily answer which pieces of your identity may travel with it.* A [GitHub issue filed against Claude Code](https://github.com/anthropics/claude-code/issues/78431) alleges that the tool placed the reporter's real email address in an HTTP `User-Agent` header without asking. The report was opened on July 17, 2026, names Claude Code version 2.1.212 on macOS inside an IntelliJ IDEA terminal, and says the behavior was a regression. That is the whole public case so far. There is no request capture, redacted header, exact command, or reproduction sequence in the issue. Anthropic has labeled it `area:networking`, `area:security`, `bug`, and `needs-info`. So I am keeping my conclusion narrow. This is not a confirmed Claude Code vulnerability. It does expose a permissions question that coding agents have not answered cleanly: does approving a tool or destination also approve every personal detail the agent puts in the payload? ## The report is an allegation, not a postmortem I cannot tell from the issue where the email address came from. It might have been supplied in the prompt, read from local configuration, added by a script, required by the requested tool, or chosen elsewhere in the product. The issue also does not say which server received the request or which permission mode was active. Those missing details determine whether this was product behavior, model behavior, tool behavior, or a misunderstanding. Before calling this a vulnerability, I would want the exact tool call and a redacted copy of the outbound request. I would also want to know where the email came from, what the user saw before execution, and whether the behavior reproduces on version 2.1.212. Until then, the reported disclosure remains unverified. The missing evidence does not make the permissions question disappear. If the allegation is accurate, the human may have understood the request as permission to analyze a tool while the agent treated it as permission to choose a public-facing identity. I would not expect those two decisions to be bundled together. ## A tool approval does not describe the data leaving Claude Code's [permission-mode documentation](https://code.claude.com/docs/en/permission-modes) says Manual mode asks before shell commands and network requests, while looser modes allow more work to proceed without interruption. Its more detailed [permissions reference](https://code.claude.com/docs/en/permissions) scopes rules around tools, commands, files, and domains. Those are useful boundaries. They still leave a separate question: which values may move from the local machine into an approved request? A user can reasonably approve a request to a domain without approving an email address inside a header. The same distinction applies to repository names, usernames, local paths, customer identifiers, and credentials. Destination control says where data can go. Read control says what the agent can access. Neither automatically expresses which accessed data may be disclosed to that destination. > **Info:** > > I would split agent egress into four checks: may this tool run, may it contact this destination, may it read this local value, and may that value leave in this request? Prompt fatigue makes the gap worse. Anthropic's account of [building Claude Code auto mode](https://www.anthropic.com/engineering/claude-code-auto-mode) says users accept 93% of manual prompts. If almost every box gets approved, the box cannot carry the whole privacy model. Safe defaults matter, and so does a preview that calls out identity-bearing data instead of burying it in a command. ## `User-Agent` should identify the software The HTTP standard gives this complaint more weight. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-10.1.5) defines `User-Agent` around product identifiers and version information. It tells senders to limit those identifiers to what is necessary and warns against needlessly fine-grained detail because it can identify a user against their wishes. The same standard has a separate [`From` request header](https://www.rfc-editor.org/rfc/rfc9110.html#section-10.1.2) for an email address. It says non-robotic user agents should not send that field without explicit user configuration, while a robotic agent should provide valid contact information so a server operator can reach whoever runs it. There is a legitimate reason for a bot to identify its operator. An accountable bot is often a better web citizen than an anonymous one. That makes sense when the operator chose the address. A developer may deliberately configure a service mailbox for automated requests. An agent finding a personal address and deciding it may be repeated in server logs is a different deal. I would want an identity chosen for that job, with the destination and possible logging made clear before the request leaves. ## The permission screen needs an egress diff For a network action, I want the approval surface to show the destination, method, sensitive headers, and local sources used to construct the request. It does not need to expose every byte. It should flag that a field contains an email address and say whether the value came from the current prompt, Git configuration, an environment variable, an account profile, or some other source. Claude Code already has an enforcement point that can help advanced users. Its [hooks reference](https://code.claude.com/docs/en/hooks) says a `PreToolUse` hook runs before a tool call, receives the tool input, and can block execution. That can stop a known command pattern or force a request through a local policy check. It is a useful escape hatch, but ordinary users should not have to write a hook to prevent a personal email from appearing in outbound metadata. The product still needs to separate tool authority from disclosure authority. An allow rule for a network tool can authorize the connection. A separate policy should decide which kinds of personal data may cross it. When the agent introduces a new identity value, the approval should say so plainly and remember the choice only for a scope the user selects. ## My read Issue #78431 does not prove that Claude Code harvested or leaked anyone's email. It does show how little evidence a user may have after an agent makes a surprising request. Anthropic needs more detail from the reporter before it can diagnose this case, and the reporter deserves a way to capture that detail without publishing the address again. If the allegation holds up, removing the email from `User-Agent` is the easy patch. The more important change is making outbound identity a visible product decision. I am comfortable letting a coding agent call an approved tool. I am not comfortable letting it decide who I am to that tool without showing me first.