Desktop app: session context reports a stale identity from ~/.claude.json, not the account that actually owns and bills the session

Desktop app: session context reports a stale identity from ~/.claude.json, not the account that actually owns and bills the session

Correction (same day): originally filed claiming the inverse — that sessions billed to the stale account. Testing disproved that. Corrected version below.

Environment

• Claude desktop app (macOS, Darwin 25.5.0), embedded Claude Code 2.1.209
• App UI signed in as: personal account (Pro plan)
• ~/.claude.json oauthAccount: work account (Claude Team org) — stale, from an

earlier CLI login on the same machine

Summary

The desktop app login correctly controls session ownership and billing. But the
Claude Code session context reports a different, stale identity — the
userEmail injected into the model's context comes from ~/.claude.json's
oauthAccount, a record left behind by the machine's original CLI login weeks
earlier, which the app never reconciles or updates.

Verified behavior (logout/login experiment)

1. Signed into app with personal account: session usage panel shows

"Plan usage limits · Pro" with that plan's quotas and reset times.

1. Signed out, signed into work (Team) account: panel shows

"Your usage limits · Team" with entirely different quotas/reset schedule.
The personal session is not accessible under this login.

1. Signed back into personal: session reappears.
2. Throughout all of this, ~/.claude.json oauthAccount (work identity,

profileFetchedAt timestamp byte-identical) never changed — the app never
touches it.

1. Yet every session under the personal login has userEmail: <work email> in

its system context.

So: billing ✓ correct, session scoping ✓ correct, identity in model context ✗ wrong.

Why this matters

1. The model reasons from a false identity. In our session, Claude read the

work email from context, cross-checked ~/.claude.json (same stale record —
circular confirmation), and confidently concluded personal sessions were
billing the employer's Team seat. The user had to disprove Claude with
usage-panel screenshots. Wrong-identity context poisons anything downstream:
git identity suggestions, org/policy assumptions, personalization, memory.

1. Users who inspect config are misled the same way. ~/.claude.json is the

documented home of the CLI's account state; a stale oauthAccount there looks
authoritative and implies billing goes somewhere it doesn't.

1. No reconciliation. App login and the CLI credential record can drift

forever; nothing detects or surfaces the mismatch.

Expected behavior

• Session context userEmail should come from the live app login, or be omitted.
• App login should update/reconcile (or invalidate) ~/.claude.json's

oauthAccount, or the stale record should be clearly marked non-authoritative.

Repro

1. Log into Claude Code CLI (terminal) with account A → ~/.claude.json stores A.
2. Sign into the desktop app with account B.
3. Start a Code session in the app → session is owned/billed by B (correct), but

its system context reports account A's email, and ~/.claude.json still
claims A indefinitely.