Quick Answer: A GitHub issue reports that Claude Code may be sending your email address to websites it visits or calls. The official README does not confirm this. Your email can still reach third parties through git metadata, OAuth identity, or tool calls. Check your traffic, scope your git identity, and review the data usage policy before trusting the tool with sensitive repos.
A report on Hacker News pointed at a GitHub issue claiming that Claude Code exposes users' email addresses to websites. That claim is serious enough to check, and not serious enough to panic over. Here's what the public documentation actually says, where an email address could plausibly leak from an agentic coding tool, and how to verify it yourself in about 15 minutes.
What the Official Documentation Actually Says
The Claude Code README describes the tool as an agentic CLI that runs routine tasks, explains code, and handles git workflows. It does not mention transmitting email addresses to websites. What it does say is that feedback collection includes "usage data (such as code acceptance or rejections), associated conversation data, and user feedback submitted via the /bug command."
That's a specific list, and an email address is not on it. But "associated conversation data" is broad, and an account-level identifier may be attached to sessions. The README links to a data usage policy and to Anthropic's Privacy Policy for the details. Read both before you assume the answer is no.
The README also notes that installation via npm is deprecated and recommends the curl, Homebrew, or WinGet installers. This matters because the install channel affects what you're trusting, and it's a sensible reason to verify the binary you actually run.
Where an Email Address Can Leak in an Agentic Tool
Most people picture a single HTTP request carrying an address. In practice, an agent that runs shell commands, fetches URLs, and talks to APIs has several more likely paths. Here's the list, roughly from most to least common in developer tooling:
- Git identity in commits and requests. Your
user.emaillives ingit config. If the agent creates commits or runsgit push, that address travels with every commit object and is visible to the remote host. This is by design, not a hidden leak, but it's the most common place an email shows up on a third-party server. - Account identity in API calls. Authenticated sessions carry an account identifier. The provider can associate that with the email on your Anthropic account. This is expected, and it goes to Anthropic, not to arbitrary websites.
- Tool-driven web requests. When the agent fetches a page, a poorly scoped request could include headers or query strings derived from local config. Anything the agent can read, a tool call can forward.
- MCP servers and plugins. Third-party MCP servers run with whatever context you give them. A server you installed may log the same identity fields the core tool sees.
The counter-intuitive point: the riskiest path is often not the core binary at all. It's the combination of a readable git config, a plugin with network access, and a prompt that asks the agent to "look up this project." The core tool can be clean and your setup can still leak.
How to Check Whether Your Email Is Leaving Your Machine
Don't rely on a vendor's statement or on a forum thread, including this one. Test it. Here's a practical method that works on macOS and Linux:
- Create a throwaway test repo and set a unique address, such as
canary-test-7731@example.invalid, withgit config user.email. - Run a Claude Code session in that repo that performs a web fetch and a commit, using a known public URL you control.
- Capture traffic with a proxy such as mitmproxy or with
tcpdumpon port 443, then grep the captured payloads for your canary string. - Repeat with the git identity unset to separate git metadata from other sources.
A canary value is the key idea. Because it's unique, any match is unambiguous. If you find it in a request to a site unrelated to git, you have a real finding worth reporting through the /bug command or the GitHub issue. Note that TLS encryption means you need a proxy with a trusted local certificate to see payload contents. Without it, you'll only see destination hosts, which is still useful.
When to Use Which Mitigation
There's a real trade-off between convenience and exposure. Here's how the common options compare:
| Mitigation | What it stops | What it doesn't stop | Cost |
|---|---|---|---|
| Scoped git identity per repo | Personal email in commits to shared remotes | Account-level identifiers sent to the API | Low: one git config --local per repo |
| Egress filtering with a proxy (for example, mitmproxy or Squid) | Unexpected destinations from tool calls | Leaks to hosts you already allow | Medium: needs allowlist maintenance |
| Running in a container or VM with no credentials mounted | Local config and SSH keys leaking | Data you deliberately paste into the session | Medium to high: workflow friction |
| Disabling web tools for sensitive repos | Outbound fetches from the agent | Git pushes and API traffic | Low, but reduces usefulness |
For most individual developers, a scoped git identity plus periodic traffic checks is a reasonable baseline. For regulated code or client work, add egress filtering and a container boundary.
The Part Most Guides Skip: Your Own Config Is the Biggest Variable
Most advice about "AI tool privacy" focuses on the vendor. In my experience reviewing developer setups, the bigger variable is local. A global .gitconfig with a personal address, an SSH agent with broad keys, and a .env file in the working tree can all be read by any process the agent runs. That's true for any shell tool, not just this one.
That said, you should still hold the vendor to account. Ask Anthropic directly what identity fields accompany requests, and check the data usage policy for retention terms. A vendor's answer in writing is more useful than a claim in a comment thread.
Here's where it gets practical: the fix that matters most is also the cheapest. Set a repo-local git identity and keep your personal address out of global config.
Frequently Asked Questions
does claude code send my email address to websites?
There's an open GitHub issue reporting this behavior, but the official README does not confirm it. Email addresses can reach third parties through git commit metadata or tool-driven requests. Verify with a unique canary email and a traffic proxy, then report any unexpected match through the /bug command or the GitHub issue tracker.
how do I stop Claude Code from using my personal email?
Set a repo-local identity with git config --local user.email to a work or alias address. This keeps your global email out of commits the agent creates. It does not affect account-level identifiers, which are tied to your Anthropic login rather than git.
why would an AI coding agent expose my git email?
Agents run real commands, and git embeds user.email in every commit object. Pushing those commits sends the address to the remote host by design. The exposure is often a configuration issue, not a hidden leak from the tool itself.
can I audit Claude Code network traffic myself?
Yes. Use mitmproxy or tcpdump with a unique canary string in your git config, then search captured traffic for it. Destination hosts are visible even without decrypting TLS, which is enough to spot unexpected endpoints.
is the npm install of Claude Code safer than the curl installer?
The README marks npm installation as deprecated and recommends the official curl, Homebrew, or WinGet methods. Prefer those, verify checksums where offered, and avoid running unverified scripts from forums.
Keep Your Identity Out of the Agent's Reach
The most useful takeaway: assume anything your agent can read can end up in a request, and shrink what's readable. Start this week by setting a repo-local git identity on one project, then run a canary test and note what you find. If you manage a team's setup, pass this to whoever owns the developer laptop image and ask them to check the global .gitconfig before the next rollout. Claude Code privacy depends on your configuration as much as on the vendor's promises.