[FEATURE] Multi-account support in VSCode extension

the multi-account-as-quota-pool pattern shows up everywhere right now (cursor threads, windsurf, the t3code issue floating around) and it's almost always a symptom of one missing thing: a real-time read of where each account actually sits against the rolling 5h and weekly window before you switch. without that, rotation just round-robins into accounts that are already cooling down. the headers anthropic returns on every /v1/messages call (anthropic-ratelimit-unified-5h-utilization, 7d-utilization) are the same numbers claude.ai/settings/usage shows, so the switcher should key off those per CLAUDE_CONFIG_DIR, not off a 429 after the fact. otherwise you're trading one mid-refactor stall for a slightly later one.

This is an important feature for me too. If have a company claude account and personal account I might like to use one for one project and another for another project in the same IDE - multi account support is important even for compliance to company policies. The same applies for the claude-extension for vscode and for the claude agent in the cli.

Yes, the same as said above. I have a work account, and need to set up a personal account, but being able to switch between them is critical for my use.

Same as above. Being able to easily switch between two accounts would be a great addition to the extension.

I have the same concern. I have a personal account and a company provided one. I want a good machanism to switch between these two in Visual Code IDE.

FYI my work-around was to use Claude privately but get Github Copilot from work since we have a choice. That way I can cleanly keep things separate. But would prefer to also use Claude for work.

Furthermore changing the account per context would be nice. So multiple sessions can use different accounts in parallel.

That's something the current workarounds can not provide easily.

Furthermore changing the account per context would be nice. So multiple sessions can use different accounts in parallel. That's something the current workarounds can not provide easily.

it is possible with the “work around” I mentioned above by using a different provider entirely

You are a genius @lsmith77 but a lot of people (like me) have non-copilot claude only for both accounts

I can confirm a second, concrete multi-profile failure in the current VS Code extension.

Environment

• macOS
• VS Code 1.129.1 arm64
• Anthropic Claude Code extension 2.1.217

The extension bundle resolves exactly one Claude root:

process.env.CLAUDE_CONFIG_DIR ?? path.join(os.homedir(), ".claude")

It has no configuration contribution for additional roots and no discovery of sibling profile directories. On this machine, the canonical root is ~/.claude/projects, while multiple active profiles have histories under ~/.claude-accounts/*/projects. Those non-default histories are invisible to the extension even though they contain valid recent JSONL transcripts.

There are two distinct product gaps:

1. The extension needs a supported profile/root switcher or configured-root list so it can discover/select multiple CLAUDE_CONFIG_DIR homes.
2. It does not register VS Code's native chat-sessions provider API at all. Its sessions can only appear in the extension-owned Past Conversations view, never under VS Code/Copilot's generic Sessions list.

For multi-account users, a useful short-term behavior would be to honor the extension-host CLAUDE_CONFIG_DIR consistently and expose the effective root in diagnostics. Longer term, profiles should be selectable without relogging and their histories should remain distinct.

On top of the manual account-switcher proposed here, I'd like to request an automatic failover option:

When the active account hits its usage limit/quota, Claude Code (CLI and/or VSCode extension) could automatically switch to a second pre-authenticated account instead of blocking the session and requiring manual /logout + /login or a manual dropdown selection.

Use case: I maintain two separate Claude subscriptions specifically to keep working past a single account's daily quota. Today this requires me to notice the quota error and manually re-authenticate (or, per the CLI workaround mentioned above, manually swap CLAUDE_CONFIG_DIR). An automatic fallback — e.g. detect the quota-exhausted error and transparently retry the request against a second configured account/profile — would remove that manual step entirely and make multi-account usage seamless, especially for long/unattended sessions.

This could build on the same underlying multi-account/profile mechanism proposed here, with an added "auto-switch on quota exhaustion" setting.

+1, hit this today on Windows 11 setting up two accounts split by workspace folder (one Pro, one Team, different orgs/clients).

Confirmed the split works correctly via the CLI (CLAUDE_CONFIG_DIR per directory) — verified the two .credentials.json files have genuinely different accessToken/refreshToken and different subscriptionType (pro vs team), and claude auth status --text correctly reports the right account per folder.

But the VSCode extension does not follow this at all: both workspace windows kept showing the same account in /usage, and real token consumption was attributed to a single account regardless of which folder/window was active — consistent with the extension always reading its own fixed ~/.claude-code-gui/ config dir instead of respecting CLAUDE_CONFIG_DIR or any per-workspace setting.

Would be great if the extension either respected CLAUDE_CONFIG_DIR (so the existing CLI-based workaround would "just work") or exposed an account switcher in the UI as described above. In the meantime we're falling back to the integrated terminal (claude CLI) for the second account instead of the extension panel.

Faced the same issue with personal Max and corporate Team plans

How come this has not been implemented yet!? I just realized I burned all my personal usage doing work stuff because not only does this not work but it silently uses a shared storage for credentials? This is outrageous for a company the size of Anthropic nowadays.
Please provide at least a workaround that doesn't silently use the last authenticated account for all agent windows so at least one can control usage.