[BUG] Personal/Work account switch breaks Claude Code VS Code extension — reload doesn't reliably fix it

Update: this is worse than a UI toggle glitch — it's orphaning chat session history, and it's 100% reproducible (4/4 old chats checked, all broken).

After recovering via full re-auth (see original report), I checked four unrelated old conversations from before the account switch, spanning different dates and topics. All four fail to load with the same error shape:

Error: Claude Code returned an error result: No conversation found with session ID: dc844b40-df12-4c8f-ba8d-ede7679a9660
Error: Claude Code returned an error result: No conversation found with session ID: 0d7243eb-9508-4d41-966c-72fcc1293d43
Error: Claude Code returned an error result: No conversation found with session ID: 43a3ec40-f0f9-48ea-93e0-247055a2774b
Error: Claude Code returned an error result: No conversation found with session ID: 2f8eff08-94ab-46e7-ab54-61abb4910694

Several of these were /compact-continued sessions with substantial prior context (one had a multi-step summary covering feature work across several days) — that history is now unreachable through the panel.

This isn't the toggle silently dropping one in-flight message (original report). The account-switch failure (~/.claude-work ↔ ~/.claude-personal via the claude-code-profile-switcher extension) appears to corrupt or repoint whatever local index maps session IDs to stored transcripts — losing/orphaning it for every prior chat, not just the one open at switch time.

Severity: prior work/chat history becomes unrecoverable via the UI, apparently unconditionally once this triggers, not just for the actively-open chat. Flagging in case transcripts are still recoverable on disk even though the panel can't find them — happy to provide local paths/session IDs if useful for debugging.

This is the smoking gun: the profile switcher swaps which .claude.json/config dir is active, but session history is scoped per-profile. When you're on Personal, Work's session IDs simply aren't in Personal's index — even though the actual .jsonl transcript files sit untouched on disk under Work's directory. It's not corruption, it's cross-profile lookup: the UI is asking the wrong profile's registry about the other profile's sessions.

Key detail: I found .claude.json in ~/.claude-personal (34 KB, updated 00:32) but there's no .claude.json in ~/.claude-work — only in personal. That top-level .claude.json is very likely the session registry/index the panel reads to know which session IDs exist and map them to transcripts. If the profile switcher extension swaps CLAUDE_CONFIG_DIR (or equivalent) between ~/.claude-work and ~/.claude-personal but the panel's lookup logic ends up reading (or caching) the other profile's .claude.json index — or work's index is missing/stale — the transcript files exist on disk but the panel can't resolve session-ID → file because it's consulting the wrong or absent index.

That's the real bug: an index/registry desync between profiles, not data loss.

This is worth adding to the GitHub comment — it makes the report much more actionable for maintainers (points them straight at .claude.json session registry handling during profile switch), and it also means your history is very likely recoverable, not gone.

I think I hit the same root cause from a different angle — not the
idle-timeout UI desync described above, but a silent account swap
between two separate profiles.

Setup: two separate editors on the same macOS user account — VS Code
using the default config (no override, work account), and Cursor
(VS Code fork) with claudeCode.environmentVariables setting
CLAUDE_CONFIG_DIR to a custom directory for a personal account.

At some point, with no manual re-authentication in either app
(confirmed via shell history — no claude CLI invocation in the
relevant window), the work account's VS Code session got silently
replaced by the personal account. Confirmed by checking
oauthAccount.emailAddress in ~/.claude.json (personal email) and
by VS Code's own account UI (also showing the personal account).

My working theory: CLAUDE_CONFIG_DIR separates the session/project
storage, but does NOT separate the secure-storage/keychain-backed
credential — that appears to need CLAUDE_SECURESTORAGE_CONFIG_DIR
set explicitly and separately. Since only CLAUDE_CONFIG_DIR was set
for the personal profile, logging in there ended up overwriting the
shared keychain credential that the default (work) profile was
relying on.

Workaround: explicitly setting CLAUDE_SECURESTORAGE_CONFIG_DIR
alongside CLAUDE_CONFIG_DIR for the non-default profile. Would be
good if this were documented — or better, if CLAUDE_CONFIG_DIR
implied an isolated secure-storage scope by default unless
overridden, so this isn't a silent trap for anyone running multiple
accounts across editors on one machine.