Claude Code User-Agent Email Leak Report

Claude Code, Anthropic's coding agent, is a terminal tool that can inspect a repo, run commands, edit files, and help with git workflows. A July 17, 2026 GitHub issue claims “Claude Code is leaking real email address as a User-Agent string in curl command” after a curl request sent an email address in the User-Agent header without explicit confirmation. The issue is thin, but it is still a useful claude code security review prompt: agent-run network commands deserve the same privacy check as file writes and git pushes. The takeaway is simple: inspect outbound headers before an agent calls the network, especially when the header contains identity.

Read the report without over-reading it

The report is short. As of August 11, 2026, the issue is open in the anthropics/claude-code repository, labeled as a bug with security and networking tags, and includes macOS and IntelliJ platform labels.

It does not include a reproducible command, logs, the target URL, or the reason curl was being used. That matters. Some APIs ask clients to include contact details in the User-Agent, usually so operators can reach an abusive or broken client. That convention still does not make it fine for an agent to insert a real email address without asking.

The right reading is boring and useful: this is a plausible privacy boundary failure, not a confirmed exploit report. The trap is treating a sparse bug as either proof of catastrophe or as nothing. Sparse reports are often where good engineering checklists come from.

Treat User-Agent as user data

A User-Agent is an HTTP request header that tells a server what client is making the request. In old browser debugging, it felt like harmless metadata. In agentic coding, it can become identity-bearing data because the agent may compose headers from prompts, repo context, examples, shell history, environment variables, or API documentation it has just read.

A realistic repo workflow looks like this. You ask Claude Code to test an integration against a staging API. It proposes a command like:

curl -H 'User-Agent: my-tool/0.1 [email protected]' https://api.example.test/status

That command may be technically valid. It may even be useful for the API owner. But the consent boundary is wrong if the email was inferred, copied from config, or picked up from surrounding context without a deliberate approval step.

The practical standard should be: headers are not comments. They leave the machine. Review them like request bodies, tokens, branch names, and git remotes.

Notice what agent-run curl changes

When a human writes curl by hand, there is usually a pause. You see the whole command, notice the token, edit the header, then hit enter.

When a coding agent writes and runs curl, the pause can disappear. The model can produce a shell command and execute it as part of a broader task: “check this endpoint,” “debug the webhook,” “reproduce the failing test,” or “inspect the package metadata.” That is exactly why Claude Code is useful. It is also why network commands need a sharper boundary than local grep.

The Claude Code GitHub report also shows a social problem with agent bugs. The community reaction focused as much on the poor reproduction as on the privacy risk. Both concerns are fair. Maintainers need enough detail to fix behavior, and users need a way to stay safe before a fix exists.

A good bug report for this case would include the proposed command, redacted headers, Claude Code version or install channel, platform, IDE integration if relevant, and whether the email appeared in repo files, git config, prompt text, environment variables, or an API example.

Check network commands before they run

Do a small claude code security review any time the agent wants to call the network. This is not a full audit. It is a pre-flight pause for commands that can transmit headers, bodies, file names, paths, tokens, emails, hostnames, or private package names.

The clean workflow is to ask Claude Code to print the exact command first, explain every outbound header, and wait for explicit approval before execution. For a repo convention, a short note in CLAUDE.md can say: “Before running curl, wget, httpie, or any command that sends HTTP requests, show the full command and wait for approve network.” Keep it short. Durable rules should be easy to remember.

If your setup uses custom slash-command prompts, create one that forces the pause:

/network-check
Print the exact network command you plan to run.
List every outbound header and request body field.
Mark any email, token, cookie, hostname, internal URL, or repo path.
Do not run the command until I reply: approve network.

That convention fits naturally beside the related training topic. It also pairs well with the broader command-approval discussion in Claude Code Makes Auto Mode Default, where the interesting question is not “can the agent act?” but “what should require a human pause?”

Copy this before you run curl through an agent

Use this as a light “before you run this agent” checklist when Claude Code proposes curl, wget, httpie, package-manager network calls, webhook tests, or API probes.

The trap is building a checklist so heavy that nobody uses it. Keep this boundary narrow: outbound network commands only, with special attention to headers and identity.

Common questions

• Is the Claude Code User-Agent email leak confirmed?

  No, not from the public issue alone. The report says an email address was sent in a curl User-Agent, but it does not include logs, a concrete reproduction, or the target service. Treat it as a credible class of risk, not as a fully established root cause.

• What should a claude code security review check first?

  Start with commands that transmit data outside the machine. For this issue, the first artifact is the exact curl command, including headers and request body. Check for emails, tokens, cookies, internal hostnames, customer data, and repo paths before allowing Claude Code to execute the command.

• Why would curl include an email in User-Agent at all?

  Some API operators ask clients to include contact details in User-Agent so they can reach the maintainer of noisy or abusive traffic. That convention is common enough to appear in documentation examples. It still requires intent: an agent should not infer and send a real personal email without a visible approval step.

• Is the claude code github issue enough reason to stop using Claude Code?

  Not by itself. The issue is sparse and unconfirmed, so it is a weak basis for a blanket decision. It is a strong basis for adding a local safety boundary: make agent-run network commands visible, inspect headers, and require explicit approval before anything leaves the machine.

Best ways to use this research

• Best for: deciding how much friction to add around Claude Code network commands without slowing every local code edit.
• Best first artifact: a tiny /network-check prompt that makes Claude Code print curl commands, headers, and request bodies before execution.
• Best comparison angle: compare local-only commands, git commands, and outbound HTTP commands by what data can leave the machine.
• Best limitation to remember: the public report does not prove where the email came from, so do not invent a root cause in your internal notes.

Further reading

• Claude Code — getting started
• Claude Code — skills
• Claude Code is leaking real email address as a User-Agent string in curl command — source

Next step

Add one explicit network-command pause to your Claude Code workflow today. The smallest useful rule is: show the full command, explain the headers, and wait for approve network before running it.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.