[BUG] Switching between personal and work Claude Code accounts is abysmal

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22841
2. https://github.com/anthropics/claude-code/issues/22333
3. https://github.com/anthropics/claude-code/issues/20553

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I don't know if it used to work, but I'm running into a similar issue while trying to switch the Claude account in VS Code.

I receive a new magic link, click on it, and when I'm back in VS Code, it's still the old account. I don't know if the fact that my settings are synced is causing an issue, but it shouldn't matter.

Supporting this. To switch accounts currently you must:

rm ~/.claude.json
Manually remove the "claude" entry from macOS Keychain Access
Re-run claude to re-authenticate
Running claude logout just opens an interactive session — it doesn't work as a command.

Requesting a proper claude logout command that clears OAuth credentials (including Keychain on macOS) cleanly.

Environment: macOS, Claude Code v2.1.45

There is a simple way to manage multiple accounts for the cli: 'CLAUDE_CONFIG_DIR=~/.claude-work claude'

There is a simple way to manage multiple accounts for the cli: 'CLAUDE_CONFIG_DIR=~/.claude-work claude'

That doesn't work. There's a number of bugs around that env_var not offering complete isolation, e.g. https://github.com/anthropics/claude-code/issues/20553

> There is a simple way to manage multiple accounts for the cli: 'CLAUDE_CONFIG_DIR=~/.claude-work claude' That doesn't work. There's a number of bugs around that env_var not offering complete isolation, e.g. #20553

@Skowt thanks for the info! I'll watch out for issues around that. That specific one seems to be at least partially resolved now as per latest comments.
One of my Claude auth keychain entries is hashed, presumably the work account that I added recently. Perhaps try a wipe and login and see if your new credentials gets the hash.

> > There is a simple way to manage multiple accounts for the cli: 'CLAUDE_CONFIG_DIR=~/.claude-work claude' > > > That doesn't work. There's a number of bugs around that env_var not offering complete isolation, e.g. #20553 @Skowt thanks for the info! I'll watch out for issues around that. That specific one seems to be at least partially resolved now as per latest comments. One of my Claude auth keychain entries is hashed, presumably the work account that I added recently. Perhaps try a wipe and login and see if your new credentials gets the hash.

Yeah it's presumably improved the situation but there's still some limitations unfortunately, like memories seem to always be stored in ~/.claude/ regardless of the config setting. Keen to see it fully supported in the future.

I hit the exact same pain point and built CCM to work around it.

The specific problems mentioned in this issue — credential confusion, manual logout/login cycles, lost session state — are addressed by:

• Atomic credential swap — backs up current account to Keychain, restores target, validates before activating. No partial states.
• Project bindings + shell hook — cd into a project directory and the right account activates automatically. No manual switching needed for day-to-day work.
• Account health tracking — ccm doctor checks credential integrity, so you know if something went wrong.

\curl -fsSL https://raw.githubusercontent.com/dr5hn/ccm/main/install.sh | bash\

v4.0 of CCM just dropped with the concurrent sessions feature a lot of people were asking about.

ccm switch --isolated work gives you a fully isolated CLAUDE_CONFIG_DIR profile - different terminals can run different accounts at the same time. Plus there's now a ccm setup wizard that walks you through first-time setup in about 30 seconds.

https://github.com/dr5hn/ccm/releases/tag/v4.0.0

Adding my account details to this thread.
Account config: Team plan (Dovetail Team Standard) + Free plan on the same email — dmackay@dovetailsoftware.com
Symptom: Extension always authenticates to the Free plan. Web UI org switcher works correctly. Extension-only issue.
Attempted:

Fresh Chrome profile (new user data directory)
Full cookie/cache clear + extension reinstall
Logged into Team plan in web UI before installing extension
Email/password login instead of Google SSO
Attempted to delete Free plan to eliminate the conflict — support page requires contacting support. Oldest ticket: [TICKET#], filed [DATE]. No response after a week.

Outcome: Extension non-functional for my account config. No workaround found.
Happy to run browser console logs or network traces if that helps the investigation.

In regards to the bug on Claude Code, a workaround I've found for this bug is to change models after changing the account . Not sure why, but it works for me regardless of this happening via VScode extension or the CLI.

Hopefully they will address the core issue soon.

Cross-referencing a narrower, complementary issue I just filed: #62790.

The bug there is one specific failure mode that makes this broader switching pain visible even after the user technically succeeds in switching: any older Claude Code window that was open during the switch keeps charging API calls against an in-memory token, while /account in that same window reports "Not authenticated" — even though the Usage progress bars in the very same dialog continue to fill with real values.

The result is that "successful" account switching still leaves the user unable to tell which account a given window is being billed against, which I think is part of why this experience feels so abysmal in practice.

Filed with full repro steps and a bilingual (EN / KR) body in #62790.

The three-step rm ~/.claude.json + Keychain-delete + re-run dance described above collapses into one command with aistat (which I built), and it keeps both credentials so you can flip back later without re-authing:

$ aistat switch --to work
switched to work@example.com (uuid 5e9c1a47-3b8f-42d1-a6e0-7c2f9b4d8e13); was personal@example.com

It also reports per-account usage, so you can check headroom before flipping:

$ aistat -h
Claude usage
- personal@example.com (active) [Max 5x]
  - 5-hour: 92.0% (resets in 4h 53m)
  - 7-day: 71.0% (resets in 2d 5h)
- work@example.com [Max 20x]
  - 5-hour: 4.0% (resets in 4h 12m)
  - 7-day: 12.0% (resets in 5d 9h)

Codex usage
- personal@example.com (active) [Pro]
  - 5-hour: 25.0% (resets in 5h 16m)
  - 7-day: 18.0% (resets in 4d 18h)

It writes the stored OAuth credential back into Claude Code-credentials unchanged, so new claude sessions and the VS Code extension pick it up on next launch. ccm is more feature-rich for Claude; aistat's angle is adding Codex switching and multi-provider reporting in one binary.

https://github.com/drogers0/aistat

+1 on macOS — adding two specifics I don't see captured yet, since most of the thread focuses on the logout/login dance itself rather than what a real fix looks like.

The CLAUDE_CONFIG_DIR workaround relieves the symptom but reveals the actual gap. Giving each account its own config dir (alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude') does keep both accounts authenticated at once and avoids the /logout → /login → browser round-trip. But it isolates everything — settings.json, session history, memory, and MCP config — so there's no way to share global config (a global CLAUDE.md, tooling, MCP servers) while keeping only credentials separate. What people actually want is "shared config, separate credentials," not two fully separate worlds. (Related config-bleed bugs: #55456, #64417.)

The ANTHROPIC_API_KEY precedence trap compounds the confusion. A globally-exported ANTHROPIC_API_KEY silently overrides subscription login regardless of which profile is active, with nothing in /status indicating it. People burn time on opaque auth failures without realizing the subscription was bypassed entirely (see #8327). Surfacing the active auth source in /status — and warning when an env key is overriding a subscription login — would prevent a whole class of this.

Concrete ask, consolidating the feature requests in #24963 / #27359 / #30031:

1. First-class named account profiles storing multiple credentials at once (à la gh auth switch), with no re-auth per swap.
2. A per-profile choice of shared-vs-isolated config (share settings/memory/MCP; separate only credentials).
3. /status showing the active account and its auth source, with a warning when ANTHROPIC_API_KEY is overriding a subscription login.

+1 we really need proper account-profile mapping and multiple account support. Claude Code account auth should associate with vscode profiles, direnv profiles, venv's, or whatever dev enviro they are configured in. Not global.

+1

had individual work account. company changed domains thus, new email. new email was invited to an org. accepted invite, ran /logout and /login. /login takes me to the sign in page, sign in with new email. taken to https://platform.claude.com/create?returnTo=... instead of dashboard (where I'm already signed in). even the claude code docs assistant says this is incorrect.

On Tahoe 26.5.1 and Claude Code 2.1.178