Session context reports a different account email than the signed-in app account

Session context reports a different account email than the signed-in app account

Summary

The session context injected into the model reported a userEmail that did not match the account actually signed into the Claude Code desktop app. The model therefore reasoned about the user's identity using a stale/incorrect address.

What happened

• The desktop app's account menu showed the signed-in account as <user>@<company-a>.com.
• The context provided to the model declared: "The user's email address is <user>@<company-b>.com."
• These are two different accounts belonging to the same person (different employers/tenants).

The user has multiple Claude accounts and had previously used this app with a different one.

Why this matters

1. Wrong-identity attribution. The injected userEmail is explicitly scoped for "authorship, attribution, or filtering their own work." A stale value can lead to commits, filters, or queries being attributed to the wrong identity — a real hazard for someone whose accounts span separate employers.

1. Misdiagnosis. The immediate task was connecting the Claude in Chrome extension, which requires the browser side panel and the app to share the same Claude account. Working from the wrong email, the model told the user their accounts were mismatched and to change the side panel's login. That was wrong. The user had to correct it twice and produce a screenshot of the account menu before it was resolved — several wasted turns on a false lead.

1. Trust. When the model asserts an account identity that contradicts what the user sees in the UI, and repeats the claim after being corrected, the user cannot tell whether the app or the model is confused.

Expected

userEmail in the session context should reflect the account currently signed into the app, and should be re-read when the signed-in account changes — not carried over from a previous session or a different account.

Environment

• Claude Code desktop app
• Model: Opus 5
• Platform: macOS (Darwin 25.5.0)
• The working directory belonged to a project associated with the other account, which may be how the stale email was resolved (i.e. the email may be keyed off the project/workspace path rather than the live session account).

Note

That last point is a guess, not a finding — I could not inspect how userEmail is populated. The reliably reproducible fact is the mismatch between the account menu and the injected context.