[BUG] [privacy] Claude Max account email auto-injected into LLM context with no opt-out
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
Summary
Claude Code reads the OAuth account email from ~/.claude.json and injects it into every session's system context as a # userEmail block. There is no settings.json flag to suppress this. The model can — and does — pull that email into outbound HTTP requests when a task requires identifying contact information, exposing the user's real identity to third-party services with no per-call user approval step.
Why this matters
Many third-party APIs that ask for contact info in User-Agent also retain access logs, and some publish those logs as public datasets on a delay. When the model injects the user's real identity into the UA:
- The identity is permanently associated with whatever request pattern was sent — number of requests, timing, exact endpoints hit. That pattern alone often discloses what the user was working on even before identity is recovered.
- For services that publish UA in public access logs, the combination is grep-able by anyone after the publication delay.
- For services that don't publish, the data still exists in their internal logs and is recoverable.
The model's local behavior is defensible — it has a contact email in context, the API documentation says to include contact info, so it uses what it has. The defect is upstream: the harness injected PII into the session's context for a task whose purpose did not require it, and there is no built-in mechanism for the user to suppress that injection.
Why existing mitigations don't solve it
- Removing the email from
~/.claude.jsonbreaks OAuth / subscription verification on next launch. - Telling the model not to use it relies on runtime instruction following. A memory rule or CLAUDE.md entry helps the same user on the same machine going forward, but doesn't transfer across setups, and doesn't protect users who don't realize the leak is happening.
- Reading the docs: Claude Code's privacy/security documentation does not (as far as I can find) disclose that the OAuth account email is exposed to the LLM and may be transmitted in outbound HTTP requests.
Severity
Privacy / data exposure. Not exploitable in the traditional security sense (no remote attacker), but causes real, irreversible disclosure of user PII to third-party systems whenever the user runs an HTTP-heavy task that calls for identifying headers. The disclosure happens via the model's autonomous action without the user being aware it's a possibility — that, plus the absence of any opt-out, is the core concern.
Environment
- Claude Code (VSCode native extension; also reproduces in CLI)
- macOS Darwin 25.2.0
- Account type: Claude Max
- Observed in current production builds (May 2026).
What Should Happen?
Requested fix (any one)
- Opt-out flag (smallest delta):
"privacy.injectUserEmail": falseinsettings.json, defaulted totrue. When false, suppress the# userEmailblock. - Opt-in default (better posture): don't inject the email unless the user enables it. Most coding tasks don't need it.
- Scope restriction: only inject
userEmailwhen the assistant is operating on Anthropic-account-related tasks. Default off for general coding work. - At minimum, document: explicitly state in the Claude Code privacy/security docs that the OAuth email is included in LLM context and may be transmitted in outbound HTTP, so users can make informed choices.
Option 1 is the smallest change and would resolve the immediate issue. Option 2 is the right long-term default.
Error Messages/Logs
Steps to Reproduce
Reproduction
- Log into Claude Code with a Claude Max account.
- Inspect
~/.claude.json— observeoauthAccount.emailAddressis stored in plaintext. - Start any Claude Code session and observe the system reminder delivered at conversation start. The model receives: userEmail
The user's email address is [real@email.com](mailto:real@email.com).
- Ask the assistant to perform any task that requires HTTP requests to a service whose access guidelines recommend (or require) a
User-Agentcontaining identifying contact info. Many regulatory, archive, and public-data APIs request this kind of header. - The assistant constructs a User-Agent string from the auto-injected email — and frequently the user's name, inferred from the local-part — and transmits it on every request. There is no point in the flow where the user explicitly provides the email for outbound use. Injection happens silently at session bootstrap; transmission happens silently as the model tries to honor the API's identification convention.
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Code v2.1.126 (VSCode native extension, darwin-arm64)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗