[BUG] Spurious "Claude can't use thinking from another organization" when Desktop Code tab and CLI share ~/.claude.json with different logins

Preflight Checklist

• [x] I have searched existing issues (no match for "thinking from another organization", "credential_org", or "oauthAccount organizationUuid")
• [x] I am on the latest version (2.1.300)
• [x] This is a bug report, not a feature request

What's Wrong?

Terminal CLI sessions repeatedly show the warning "Claude can't use thinking from another organization" even though the session's login never changed. It fires when a Claude Desktop Code tab session (which spawns its own bundled claude.exe on the same ~/.claude config dir but is signed into a different claude.ai organization) is running at the same time.

Root cause, as far as I can trace it in the 2.1.300 binary: the per-request org check (Hl(), the function that emits the credential_org attachment and the warning um) determines the "current" org via Ju()?.organizationUuid, and Ju() is ce().oauthAccount, i.e. the oauthAccount record in the shared ~/.claude.json. Both processes rewrite that record with their own identity on launch/refresh, so a long-lived CLI session sees the field flip between org A (its own Max login) and org B (the Desktop app's Team login) and warns on every flip, although the credential it actually sends (~/.claude/.credentials.json, untouched for hours) never changed.

Evidence from transcripts (one machine, one day):

• One CLI session's credential_org attachments alternated A→B→A→B eight times in two hours; each flip coincided with a Desktop Code-tab session starting.
• The session in the screenshot warned 7 seconds after it started (on its second request) and three more times, once per flip.
• Census across all transcripts: 13 warnings between 2026-10-01 and 2026-10-14, all with entrypoint: cli; zero in claude-desktop sessions. The credential_org attachment already flapped silently on 2.1.283-2.1.285 (11 of 27 sessions); the visible warning first appeared on 2.1.286.
• No thinking_drop attachments are written and the next request still hits the prompt cache (cache_read 119k-227k tokens), so in this configuration the warning is a false positive with no real loss, but its advice ("resume this session signed in to that organization") is wrong and alarming.

What Should Happen?

The org used for the thinking-binding check should come from the credential the session actually sends (the token's org), not from a config field that other processes with a different login can overwrite. Alternatively, the Desktop Code tab should not write its oauthAccount into a ~/.claude.json that a differently-logged-in CLI shares, or the record should be keyed per credential source.

Error Messages/Logs

Claude can't use thinking from another organization
Claude's earlier thinking was written while you were signed in to another organization, so Claude can't use it now. It isn't deleted: resume this session signed in to that organization to use it again. Claude's next responses may be slower and use more tokens because it has to reread this session and generate new thinking. See docs for more: https://platform.claude.com/docs/en/build-with-claude/preserved-thinking

Transcript records surrounding one occurrence (same session, same process, 7 s apart):

20:50:18  attachment credential_org  organizationUuid=<org A>
20:50:25  attachment credential_org  organizationUuid=<org B>
20:50:25  system informational        "Claude can't use thinking from another organization"

claude auth status in that config dir reports subscriptionType: max with orgId: null, while ~/.claude.json oauthAccount.organizationUuid is org B and later org A again (file mtime changed with no login action).

Steps to Reproduce

1. Windows, Claude Desktop installed and signed into claude.ai organization B (a Team org). CLI claude installed natively and logged in via /login to organization A (a Max plan) on the same account. Both use the default ~/.claude config dir (no CLAUDE_CONFIG_DIR).
2. Start a terminal claude session and keep it alive for an hour or more.
3. Open and close a few Claude Desktop Code-tab sessions in the same project.
4. Send another prompt in the terminal session (or let a tool result trigger the next request).
5. Observe the warning in the terminal session; inspect ~/.claude/projects/<slug>/<session>.jsonl and watch the credential_org attachment alternate between the two org UUIDs; watch ~/.claude.json oauthAccount.organizationUuid flip.

Claude Model

Sonnet 5.5 (warning appears with Sonnet 5.5; account-bound thinking models)

Is this a regression?

Yes. Warning first seen 2.1.286 (2026-10-01). The underlying credential_org flapping is visible since 2.1.283 but was silent.

Last Working Version

2.1.285 (no warning shown)

Claude Code Version

2.1.300 (native install, ~/.local/share/claude/versions/2.1.300); Desktop Code tab bundles 2.1.295

Platform

Claude Desktop (Code tab) + native CLI

Operating System

Windows 11 Pro 10.0.26300

Terminal/Shell

Windows Terminal / PowerShell 7 (Claude Code's Bash tool is Git Bash)

Additional Information

Workaround that avoids it: run the terminal CLI under its own CLAUDE_CONFIG_DIR. A third profile on this machine that does exactly that (separate dir, separate .claude.json) never warns.