A session's CLAUDE_CONFIG_DIR names a different account than the one it authenticates and bills under, and nothing in the session can tell

*Identities are labelled (account A/D, org A/D) rather than quoted. They are real logins on one
machine; I can supply actual values privately if that helps diagnosis.*

Summary

A desktop-app-launched session runs with CLAUDE_CONFIG_DIR set to a config root that is not the
root it authenticates under. On this machine the environment names a root belonging to account A
(a corporate login, org A), while every account record the desktop app writes for its own sessions
names account D (a webmail login, a different org). The account owner confirms billing is
account D.

Everything downstream trusts the environment and is therefore confidently wrong:

• the model's session context reports account A's email
• claude auth status, spawned from the session's own shell, reports account A
• a machine-local usage governor reading the same signal reports account A

Three independent surfaces, one wrong answer, no disagreement between them to signal a problem. The
session cannot determine which account it is operating under, and neither can any tool it runs.

I am not asking for the credential store to be exposed. I am asking that the session's effective
account be a stated fact, and that CLAUDE_CONFIG_DIR either govern authentication or stop being
presented as the session's config root.

Environment

• Windows 11 Pro 26200, Claude Code 2.1.233
• Desktop app + VS Code extension + CLI, several concurrent sessions against one repo
• 5 CLI config roots in $HOME: ~/.claude, ~/.claude-account-1 .. ~/.claude-account-4,

resolving to three distinct accounts across three organizations

• Desktop-managed per-session roots under

%APPDATA%\Roaming\Claude\{claude-code-sessions,local-agent-mode-sessions}\...\.claude\

Repro A -- the environment names one account, the session authenticates as another

In a desktop-launched session:

$ echo "$CLAUDE_CONFIG_DIR"
C:\Users\<user>\.claude-account-1

$ claude auth status
{"loggedIn":true,"authMethod":"claude.ai","apiProvider":"firstParty",
 "email":"<account A>","orgId":"<org A>","orgName":"...","subscriptionType":"max"}

The model's own context likewise carries account A's email, and nothing else about identity.

Now count the account records the desktop app writes for its sessions:

$ grep -rhoE '"emailAddress"[[:space:]]*:[[:space:]]*"[^"]+"' \
    "$APPDATA/Claude/claude-code-sessions" "$APPDATA/Claude/local-agent-mode-sessions" \
  | sed 's/.*: *"//;s/"//' | sort | uniq -c

    143 <account D>

143 of 143 name account D. Zero name account A, which is the account the environment, the CLI,
and the model's context all report. The owner independently confirms account D is the billing
account.

So CLAUDE_CONFIG_DIR is being set to a root that does not govern the session's authentication,
while every consumer -- including Claude Code's own auth status -- treats it as authoritative.

Expected: a session can name the account it authenticates and bills under, and the environment
does not advertise a different one.
Actual: the environment advertises account A, the session bills account D, and no surface
available to the session reports the discrepancy.

Repro B -- the default config root reports logged in with no identity

Independently reproducible, and it removes the obvious fallback for tooling that suspects the
environment. Three ways of naming the same directory:

$ CLAUDE_CONFIG_DIR='C:/Users/<user>/.claude' claude auth status
{"loggedIn":true,"authMethod":"claude.ai","apiProvider":"firstParty","email":null,"orgId":null,"orgName":null,"subscriptionType":"max"}

$ CLAUDE_CONFIG_DIR='C:\Users\<user>\.claude' claude auth status
{"loggedIn":true,...,"email":null,"orgId":null,"orgName":null,"subscriptionType":"max"}

$ CLAUDE_CONFIG_DIR="$HOME/.claude" claude auth status
{"loggedIn":true,...,"email":null,"orgId":null,"orgName":null,"subscriptionType":"max"}

~/.claude/.credentials.json is present and subscriptionType is populated (max) in the same
response whose identity fields are null, so this is not a plain "not signed in" state. That root's
.claude.json contains no emailAddress key at all, while the other roots' do.

Expected: an identity, or loggedIn: false.
Actual: loggedIn: true with a null identity -- an answer no caller can act on.

Repro C -- unset and explicit-default disagree about the same directory

$ env -u CLAUDE_CONFIG_DIR claude auth status
{"loggedIn":true,...,"email":"<account B>","orgId":"<org B>",...}

$ CLAUDE_CONFIG_DIR="$HOME/.claude" claude auth status
{"loggedIn":true,...,"email":null,"orgId":null,"orgName":null,...}

Unset should mean the default root, documented as ~/.claude. Naming it explicitly yields a null
identity; leaving it unset yields account B, the identity of a different root. I did not diagnose
which resolution path produces that; I am reporting that the two disagree.

Why this is load-bearing, not cosmetic

I run a machine-local usage governor that reads account consumption and, at thresholds, tells
sessions to protect work in progress. It has to know which account a session bills to, so it read
the only signal available -- CLAUDE_CONFIG_DIR -- and has therefore been grading account A's
consumption while the sessions it governs spend account D's. It has been reporting a percentage for
the wrong account, at a threshold that triggers protective action, for as long as it has been
running.

Nothing in the product could have told it otherwise. That is the shape of the defect: not a wrong
number, but an unanswerable question with a confident-looking answer sitting where the answer should
be.

Concurrent sessions on this machine also report different accounts from each other, depending on
which root each was launched with, so comparing usage between sessions silently compares different
accounts.

What would fix it

1. Put the session's effective account in the session's context -- email, organization id and

name, subscription type, and the config root actually governing authentication. A session should
be able to state which account it is on, and to decline to guess when it cannot.

1. Add the same fields to the hook stdin payload, so machine-local governors, auditors and

schedulers stop reverse-engineering identity from undocumented state.

1. Do not set CLAUDE_CONFIG_DIR to a root that does not govern the session's authentication.

If the desktop app manages a per-session root, the environment should name that root, or make
clear that the variable is not the auth source.

1. Never return loggedIn: true with a null identity. Report the identity, or report not logged

in.

1. Document how the default config root resolves when CLAUDE_CONFIG_DIR is unset.

Item 3 is the actual bug. Items 1 and 2 would have made it visible in minutes instead of weeks.

Related

• #83951 -- no supported way to enumerate config roots (same multi-root setup, from the outside)
• #83952 / #82323 -- hooks across multiple config roots: no receipt for which file governs
• #84868 -- session listing conflates idle / not observable / gone
• #87155 -- desktop tray icons indistinguishable when one instance per account is running

CLAUDE_CODE_ENTRYPOINT   claude-desktop    -> takes the desktop branch, correctly
session id               resolved          -> correct
desktop-record lookup    EMPTY             -> no desktop record for this session
CLI config-root lookup   org A             -> what our tooling reports
app-current-org fallback org B             -> a third answer
ACTUALLY BEING SPENT     org D             -> NO BRANCH RETURNS IT

oauthAccount.accountUuid              -> account A   (alongside account A's org uuid and email)
cachedUsageUtilization.accountUuid    -> account D