Feature Request: Named account profiles for quick switching between multiple claude.ai accounts

Built exactly this — named profiles with instant switching:

npm install -g @synth1s/cloak

cloak create work
cloak create home
cloak switch work    # instant, no logout needed

Shell integration adds a one-step shortcut:

claude -a work       # switch and launch

Sessions, tokens, MCP servers, settings — all preserved per profile. 700+ downloads in the first day.

https://github.com/synth1s/cloak

As others have mentioned here and in other threads, it can be accomplished with CLAUDE_CONFIG_DIR environment variable. I wrote a 1 minute article about my minimal setup, which requires no dependency, hopefully it could be of help: article

Hi,

I ran into the same problem and there are a lot of tools out there for macOS or Linux that already tackle this problem.

Sadly there was no good tooling to manage Anthropic accounts on Windows... so I built this:

https://github.com/countzero/windows_switch_claude_account

<img width="1018" height="547" alt="Image" src="https://github.com/user-attachments/assets/c8d044fd-0a07-43f3-8400-38646969f2aa" />

Maybe this helps someone :wink:

No browser /login needed. I built aistat to keep each account in its own keychain item and rewrite the live Claude Code-credentials item in place, so the next claude invocation just picks up the switch:

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

Usage reporting is the other half — it lists every stored account so you can see who has room:

$ 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)

cloak and windows_switch_claude_account are more featureful for Claude alone; aistat's angle is one binary that also reports and switches Codex, with JSON output for statuslines by default.

https://github.com/drogers0/aistat

+1 — concrete use case: I'm a product designer who ships in code for two different clients, and I brought the Claude Code workflow to both on the design part. Each client has its own Claude account (different emails). Today switching means a full logout and browser login every time I change project — and sometimes I'd simply like to run two sessions in parallel, one per client, which a single logged-in account can't do. Both accounts are already paid — this is purely a workflow gap. A profile switcher (like gh auth switch or Google's account menu) would remove the friction. The CLAUDE_CONFIG_DIR workaround helps in the terminal, but the desktop app doesn't support it (#25762).

Adding the desktop-app dimension to this, since the most recent comment touches on it.

I have two accounts on the same email — a business (Team) seat and a personal plan — and I use the Claude desktop app for chat, not only the CLI. Toggling profiles from the account menu breaks an in-flight conversation.

Worth being precise about the failure mode, because it differs from how #68441 described it. The conversation is not lost. It survives on the original profile, and switching back shows it fully intact. What's broken is the generation: the interrupted response never resumes. The conversation just sits there stopped, and I have to manually ask it to continue. So it's an orphaned turn with no resume, not data loss — and there's still no way to carry a conversation across profiles, or to keep both accounts live at once.

Why I'm posting here rather than opening a dedicated issue: #68441 asked for precisely this (conversation continuity across Team → Personal in the desktop app) and was closed as invalid / not-planned — "doesn't seem to be related to Claude Code." That may be right for this repo's scope, but the practical effect is that desktop-app profile switching has no venue at all, so the profile-management request here is the nearest live thread.

Three things that would resolve it, in priority order:

1. Independent windows per profile — one window per account, both live, no token swap. This removes the need to toggle at all. It's what separate browser profiles on the web achieve today, which is the workaround I've fallen back on.
2. Resume the orphaned turn on switch-back — since the conversation is already intact, the narrow fix is just for the interrupted response to pick up where it stopped instead of needing a manual nudge.
3. CLAUDE_CONFIG_DIR honoured by the desktop app (#25762) — the terminal workaround described in this thread doesn't reach the desktop app.

Both accounts are paid; this is purely a workflow gap.

Adding the piece that isn't in this thread yet, because it explains why none of the tools posted above can do what @RajeshGoradia and @alexandraapituru are asking for.

Everything linked here — cloak, aistat, windows_switch_claude_account, the plain CLAUDE_CONFIG_DIR recipe — is a switcher. They rewrite one shared thing (the Claude Code-credentials Keychain item, or which config dir is active) so the next claude invocation comes up as a different identity. That's the right design for the CLI and they do it well. But it means one account is live at a time by construction, and none of it reaches the desktop app, which is a separate Electron app with its own profile directory and doesn't read CLAUDE_CONFIG_DIR (#25762).

For "both live at once" you need isolation rather than switching — a second copy of the official app with its own --user-data-dir, which Electron treats as a fully separate profile:

# macOS
open -n -a "/Applications/Claude.app" --args --user-data-dir="$HOME/.claude-profiles/work"

# Windows (Claude.exe lives under %LOCALAPPDATA%, usually \AnthropicClaude\ or \Programs\Claude\)
Start-Process "$env:LOCALAPPDATA\AnthropicClaude\Claude.exe" -ArgumentList '--user-data-dir=C:\claude-profiles\work'

That gives you a second window with its own history, settings and connectors. Then sign-in splits by platform, and this is the part that surprised me:

• macOS — the app runs browser sign-in (Google, magic link, enterprise SSO) through a native in-process auth session, so the callback returns to the window that started it. Isolated instances just work.
• Windows — there is no native auth session. Sign-in leaves for the system browser and comes back as a claude://…sso-callback deep link, and the protocol handler starts a fresh Claude.exe with no --user-data-dir. Claude also holds no single-instance lock. So the callback lands in the default profile instead of the window you started the login from. That break happens outside the profile, which is why a per-profile data dir alone can't fix it.

Practical upshot on Windows: the free recipe above gets you isolated windows, but the second one may never finish signing in — specifically for SSO and Google. Email + password is fine.

@RajeshGoradia — your option 1 is exactly what isolation gives you, and it does dissolve the orphaned-turn problem, because you never switch. Worth flagging that your option 3 wouldn't get you there though: CLAUDE_CONFIG_DIR is the CLI's config, so honouring it wouldn't give the desktop app profiles.

Disclosure: I package this — https://deckspace.dev/claude-accounts/?src=gh-27359 ($14 one-time, Mac + Windows, unofficial, not affiliated with Anthropic, full source in the download, 7-day refund). The part that took real work was routing those Windows callbacks back to the profile that asked for them. Rather than take my word for it: @weineran posted his own results over in #18435 after using it with a personal Google account and his work SSO — https://github.com/anthropics/claude-code/issues/18435#issuecomment-5028823644

To be clear about scope: if you're on macOS, or you sign in with email + password, the recipe above is free and it works — use that, or one of the tools already linked in this thread. The Windows SSO callback is the only thing I'd claim is genuinely different.

All of it is duct tape over a missing feature, though. Native profiles in the app is what this thread actually wants — #18435 is the biggest live thread on that if anyone wants to add weight to it.