[FEATURE] Add the ability to manage multiple Claude accounts within the Claude Desktop app with easy switching between profiles.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/261
2. https://github.com/anthropics/claude-code/issues/12810
3. https://github.com/anthropics/claude-code/issues/3835

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

This is not a duplicate of the referenced issues. Those issues (#261, #12810, #3835) are specifically about Claude Code (CLI), whereas this feature request is for Claude Desktop (the GUI application).

Key differences:

Different products:

Issues #261 and #12810 address the command-line tool and already have workarounds using CLAUDE_CONFIG_DIR environment variable
Issue #3835 is about switching between payment methods (Max vs API), not different accounts
This issue is specifically for the Claude Desktop GUI app, which is a separate product
Different user experience:

CLI users can use environment variables and shell functions to manage profiles
Desktop app users have no equivalent workaround and must manually sign out/in through the GUI
Different use case:

This request is for graphical multi-account management in the Desktop application, not CLI profile switching
The Claude Desktop app needs its own implementation of account switching that's appropriate for a GUI application (similar to how Slack, Discord, or Chrome handle multiple accounts/profiles in their desktop apps).

Please keep this issue open as it addresses a genuine gap in the Claude Desktop application's functionality.

+1

my main use case is running parallel projects across two different GitHub accounts from the desktop GUI. I've looked through existing issues and tried various workarounds (separate CLAUDE_CONFIG_DIR profiles, GH_TOKEN in cloud environments) but nothing provides a clean solution.

the Connectors feature only supports one GitHub account at a time, which forces constant disconnecting and reconnecting when switching contexts.

Please add this!

+1 — This is a significant adoption blocker.

What I've already solved in the terminal:

I run a multi-workspace Claude Code setup with 5 separate API workspaces (work org + personal + consulting), hierarchical 4-tier configs, and automatic API key selection per directory via apiKeyHelper. Full context isolation, separate cost tracking, bidirectional config sync — it all works beautifully in the terminal.

The terminal proves this workflow is technically feasible and highly productive. But it runs on API billing, which adds up fast.

Where it breaks down:

The Desktop app (with Pro/Team/Max subscriptions) is the cost-effective path — and it's required for Cowork and Desktop-based Code. But it only supports one logged-in account at a time. No browser workaround covers Code or Cowork since they need local file system access through the Desktop app.

My current situation: I have a Team account for work and want a personal Pro account — same machine. Right now, that's impossible without constant logout/login.

The competitive angle:

I'm currently considering consolidating from multiple AI tool subscriptions (ChatGPT for personal, Claude Team for work) into Claude for everything. Multi-account Desktop support would remove the last friction point. I suspect there are many others in the same position — people ready to go all-in on Claude if this basic workflow is supported.

Suggested approach (from terminal experience):

• Profile-based sessions (like Slack workspaces), not just account switching
• Each profile maintains its own conversation history, projects, memory, and MCP configs
• Visual indicator for active profile (color-coded sidebar or avatar)
• Keyboard shortcut for quick switching (Cmd+Shift+] as OP suggested)
• Bonus: directory-aware profile auto-switching (like how apiKeyHelper works in the terminal)

Related issues: #12810 #20549 #261

+1 — this is a daily pain point for me.
I work in IT for an organization and also run my own consulting business on the side. I use Claude heavily for both — enterprise security research, documentation, and project work during the day, then personal projects and business development in the evenings and weekends. All on the same Mac.

Right now I’m doing exactly what the OP describes:
Claude Desktop for one account, browser for the other. It works, but it defeats the purpose of having the desktop app and Cowork/MCP integrations if I can only use them for one identity at a time.

The Slack-style workspace switcher model is the right call. Separate conversation history, separate MCP configs, separate memories — just a quick Cmd+Shift+] to flip between them. The browser profile workaround shouldn’t be the long-term answer when every other productivity tool has solved this already.

This would also be huge for consultants and MSP techs who manage multiple client environments.
The use case goes well beyond just “work and personal.“​​​​​​​​​​​​​​​​

+1 on this feature — enterprise/corporate use case

I'm an IT administrator and network engineer working in a managed enterprise environment. I maintain two Claude accounts: a corporate account provisioned and managed by my organization, and a personal Max plan I pay for out of pocket.
Because these accounts are on different email addresses, there's no way to switch between them without fully signing out and back in. In practice, this means I keep the desktop app logged into one account and a browser window open for the other — a clunky workaround that defeats the purpose of having a native app.

The friction is real and daily. My corporate account is appropriate for work tasks within my organization's acceptable use policies, while my personal Max account is what I reach for outside that scope. Having to juggle two separate surfaces constantly breaks flow.

A profile switcher — even just a simple drop-down from the avatar menu like Slack uses for work spaces — would be a meaningful quality-of-life improvement for anyone operating in environments where work and personal accounts need to stay separated. This is an especially common scenario in enterprise settings where organizational accounts are managed externally and can't simply be merged with a personal subscription.

Add me to the list requesting this. I am a web developer on a Team account for work and want to be able to cleanly switch between work and side gig accounts, including to use Code. Being able to run both at the same time would be great, but I would settle for a clean switch where my Claude Desktop doesn't show the wrong Code sessions. Simply put: Desktop Code view should respect per-account session storage, not a single shared Windows config directory.

adding myself to the request list here too. desktop switching between my work and personal accounts would be incredibly valuable.

I want to pass along to those of you who are looking to do this that if you already run Windows and WSL, a workaround that allows you to run both is to install the Ubuntu version of Claude Desktop and the windows version of Claude Desktop, one for work and one for personal. You have to write a launch script to pick up the correct config on the Ubuntu side, or it will pick up the config from the Windows version, but it works - two fully functional versions of Claude, one computer. They'll even run at the same time if your machine will handle it.

If you need this feature, your upvote is the only thing that matters. Don't just read and leave. React.

Every single thumbs-up on this issue is a signal to the team that this is not a nice-to-have. It is a workflow blocker. A productivity killer. A daily source of frustration for people who are paying customers and loyal advocates of this product. Right now, this issue has a fraction of the votes it deserves given how many people are silently suffering through the same pain.

The problem is universal. If you use Claude for work, you almost certainly maintain more than one account. A personal Max plan and a corporate Team seat. A consulting gig and a side project. Multiple client environments you have to juggle. This is not some niche edge case. This is the default reality for any serious professional user. Look at the comments here. Developers, consultants, enterprise users, IT professionals. We are all hitting the same wall.

The workarounds are embarrassing for a product this good. Think about that for a second. Claude is one of the most capable AI tools on the planet, and to switch between two accounts you have to sign out, sign back in, and lose your entire flow state. Or run a janky setup with Desktop for one account and a browser tab for the other. Or create separate macOS user profiles like it's 2005. Slack, Chrome, Notion, Discord, VS Code, and virtually every modern multi-user application solved this years ago. This is table stakes. We should not still be asking for it.

But here is the hard truth: silent agreement does not ship features.

I know exactly what happens. You found this issue, you read through it, you thought "yes, I need this too," and you kept scrolling. I get it. Someone already said what you were going to say. The issue exists. Surely the team knows. But that is not how prioritization works. Product teams allocate resources based on measurable demand. And the single most important metric on a GitHub issue is the thumbs-up reaction count on the original post. Not a "+1" comment. Not a bookmark. The reaction. It is the difference between "a few people mentioned this" and "our users are overwhelmingly asking for this."

37 upvotes is not enough. Not for a feature this fundamental. Not when thousands of people use Claude Desktop across multiple accounts every single day. That number should be in the few thousands. The only reason it is not is because people assume someone else will do it. That their one vote will not matter. But it does. Every single one adds up. Every single one makes this harder to deprioritize.

What to do right now (it takes 5 seconds):

1. Scroll to the very top of this issue
2. Click the smiley face reaction button on the original post (not this comment)
3. Hit the thumbs-up

That is it. You do not need to write anything. You do not need to subscribe. Just one click.

If switching accounts wastes even five minutes of your day, that is over 20 hours a year of lost productivity you are quietly accepting. Twenty hours of broken focus, interrupted workflows, and unnecessary friction. All because you did not click a button.

Be the vote you wish someone else would cast. Let's get this on the roadmap.

+1

I am also looking to have a personal usage account and then a work account. Needing a virtual machine or even a completely separate local machine for this feature would be exceptionally tedious...

Same here in the need of running multiple accounts in claude code session or desktop app.

This is my only barrier remaining to make a personal subscription of Claude. I’m currently using ChatGPT for my personal use.

Big +1 as well. I'm trying to switch from other providers for my personal LLM use cases to Claude for everything, and I have work accounts already. I need the ability to switch between work and personal contexts and keep a hard wall between them both for billing and privacy/legal reasons. This is pretty important if I ever want to use Claude for my personal use and pay for a subscription in addition to my work usage - which I would love to do!

In particular this matters for both desktop and mobile.

I REALLY want to switch. But I do need to keep my work & personal separate. Please consider adding this ability so that those of us wanting to make the change to Claude can do so. Adding friction means fewer people may capitalise on the current environment!

+1, I was already paying for a personal Claude subscription for personal projects, then work bought a Claude subscription today and I need to run both in Mac Desktop app for Cowork. This definitely makes it harder for people paying for personal subscriptions to get the full benefit and I can see some people discontinuing their personal subscription if they can't switch easily.

The ability to give separate, mutually exclusive folder access permissions to each Claude account is also extremely important to keep sensitive personal data + confidential work data isolated.

Passo da hora, 3 contas e não posso alternar no Claude Desktop.

+1

Please do this!

We should already have this. I have a business account managed by the company and my personal account. I would like to be able to use both without having to log out of my account all the time.

+1 This is very annoying to not be able to switch. There are many use cases to having multiple accounts, and needing to keep data and usage separate.

+1, i need to seperate my business consumption with my personal one and currently it´s blocking me to do this without additional effort

🙏🏻... on iOS too.

+1, I have a personal account and a different one for a business I work for.

I built an open-source CLI that solves this for Claude Code (terminal):

npm install -g @synth1s/cloak

cloak create work        # save current session
cloak create home        # save another
cloak switch work        # instant switch, no logout needed

Each account gets its own isolated directory. Sessions, tokens, MCP servers, and settings are fully preserved across switches. Supports concurrent sessions in different terminals.

Shell integration adds claude -a work as a one-step shortcut.

https://github.com/synth1s/cloak

Note: This works with Claude Code CLI only, not the Desktop app. For Desktop app multi-account support, we still need Anthropic to implement it natively.

I built an open-source CLI that solves this using CLAUDE_CONFIG_DIR: npm install -g @synth1s/cloak cloak create work # save current session cloak create home # save another cloak switch work # instant switch, no logout needed Each account gets its own isolated directory. Sessions, tokens, MCP servers, and settings are fully preserved across switches. Supports concurrent sessions in different terminals. Shell integration adds claude -a work as a one-step shortcut. https://github.com/synth1s/cloak

Ok, nice, but this thread is about the desktop app, not the CLI.

I built an open-source CLI that solves this for Claude Code (terminal): npm install -g @synth1s/cloak cloak create work # save current session cloak create home # save another cloak switch work # instant switch, no logout needed Each account gets its own isolated directory. Sessions, tokens, MCP servers, and settings are fully preserved across switches. Supports concurrent sessions in different terminals. Shell integration adds claude -a work as a one-step shortcut. https://github.com/synth1s/cloak > Note: This works with Claude Code CLI only, not the Desktop app. For Desktop app multi-account support, we still need Anthropic to implement it natively.

This is a well documented and understood workaround for the CLI and has no part in the solution for the client issue this feature request is trying to resolve.

Why we already don't have this feature?
commmmmon this switching is killing me.

Workaround: Profile switching via credential files + directory auto-detection

I needed to switch between a personal (Claude Pro) and a work (Claude Team) account depending on the project I'm working on. Since native multi-account support isn't available yet, I implemented a workaround using credential
file swapping + a shell wrapper that auto-selects the profile based on the current directory.

How it works:

• Credentials are saved per profile under ~/.claude/profiles/<name>/.credentials.json
• claude-switch <profile> copies the right credentials file to ~/.claude/.credentials.json
• A claude() wrapper checks the current directory and auto-activates the correct profile before launching
• A manual override ($env:CLAUDE_MANUAL_PROFILE) prevents the auto-switch from overriding an explicit user selection
• Works on both Git Bash (.bashrc) and PowerShell ($PROFILE)

Core functions (PowerShell version):

function claude-switch {
param([string]$profile)
$creds = "$HOME\.claude\profiles\$profile\.credentials.json"
Copy-Item $creds "$HOME\.claude\.credentials.json" -Force
$env:CLAUDE_MANUAL_PROFILE = $profile
Write-Host "Profile '$profile' activated."
}

function claude {
if (-not $env:CLAUDE_MANUAL_PROFILE) {
# auto-switch based on directory
if ((Get-Location).Path -like "C:\Projects\work*") {
claude-switch work | Out-Null
}
}
& "$env:APPDATA\npm\claude.ps1" @args
}

It works reliably, but it's clearly a hack. Native support with something like claude --profile work or a CLAUDE_PROFILE env var would be a much cleaner solution. +1 on this request.

Similar Feature request on Mobile
https://github.com/anthropics/claude-code/issues/36151

Please add this!! I'm collaborating with more and more teams, and switching is more friction than expected.

+1 please add this

+1 please add this.

Really need this!

pls- super important now that Microsoft 365 connector is only available on Claude Teams/Enterprise! need to be able to get one personal daily digest using context from work and personal, and keeping sensitive data where it belongs!

+1 Add this feature

+1

Seems like they could just use Claude to implement this constantly requested feature in about 37 seconds.

+1 It seems currently there is already support for multiple plans on one account (Personal and Team) but only if they are on the same email. Please add the ability to login to a personal (different email) and team (work email) with the sidebar switcher!

+1

+1 (work + personal accounts different emails)

+1, needed for work and personal use

+1

+1 def need this for work

+1

+1

+1 this should absolutely be a priority.

+1

This would be great - and really prevents potential revenue for pro accounts. Since desktop already allows a "Personal" plan when you have a corporate team plan, maybe by adding the ability to specify an account email for the "Personal" plan, it can separate the necessary memory and connectors.

Please.

+1 on this request. I’d like to extend the scope to also cover a few missing areas:

Claude Code (CLI)
Beyond the Desktop app, the CLI has the same problem. A dedicated /accounts slash command for interactive account switching mid-session would be ideal, along with a --account <name> flag for scripting and automation workflows. The groundwork already exists in ~/.claude/.credentials.json — named profile support could be layered on top without a major architectural change.

Claude.ai — Web & Mobile
The same account switcher concept should extend to the web app and mobile apps (iOS/Android), not just Desktop. Users shouldn’t need to fully sign out on any platform.

Freelancer / contractor use case
Beyond the personal vs. work split, many developers maintain completely separate accounts per client for confidentiality and billing reasons. Quick switching between 3+ accounts would make this workflow viable without juggling multiple browsers, terminals, or devices.

I can understand why there is apprehension on Anthropic's side to add this feature due to the current landscape around unofficial wrappers, third party harnesses, etc. However... the enterprise need for this is strong.

+1 -- specifically need this for Cowork

I have a personal (Pro/Max) and a work (Team) Claude account. I need Cowork on both: personal for my side projects, work for company tasks.

Since Cowork is desktop-only with no web fallback, there is currently no clean way to use both accounts. The only workaround is launching a second instance with --user-data-dir, which works but feels like a hack.

A simple account switcher (like Slack workspaces) would solve this completely.

+1 on this request. I have multiple subscriptions through various client projects. Need an account or profile switcher inside of Claude Desktop to use Cowork with local files and connectors.

+1. preventing me from recommending my workplace acquire an additional account for me - too hard to manage in addition to my personal account

+1

+1 - really want this!!

+1

Worth noting OpenAI and Gemini both have this feature.

+1 - This is a significant friction point between adoption between home and work.

+1 I have workplace-managed claude subscription that I use for work projects and personal subscription that powers my claude-based personal assistant and I'd like to be able to switch between them

+1

+1 — being able to switch between personal and enterprise accounts seamlessly would be fantastic. Signing out and back in every time I move between contexts is real friction.

+1, x20 is not enough for full week of work, I would like to be able to easily switch between multiple subs without losing the history and in progress items just like I can do in CLI

+1

+1

+1

I have a personal and a work claude account, this would be a massive win for my workflows.

I've tried experiments like isolating a 2nd installation of the claude app but that messes with the bundle too much and things break (like the VMs in cowork). I wish some hacks were possible but they're too brittle.

+1

+1

+1

+1

+1

+1

+1

I have a personal Max plan and I have pushed to get a work Max plan for security reasons. Running into issues effectively using them both. This seems like the type of use you would want to encourage!

I have a personal Max and our org has a Team plan. Having to keep one open in the browser and one on the app is just a poor experience. Make it happen! +1

Guys, please stop spamming this thread. If your comment is just another "+1", a thumbs-up reaction on the first message is more than enough. I can relate to your pain, but comments like these don't add any value to the conversation.

Guys, please stop spamming this thread. If your comment is just another "+1", a thumbs-up reaction on the first message is more than enough. I can relate to your pain, but comments like these don't add any value to the conversation.

I rather disagree, this is very annoying to work around and the louder people are about it, the more attention it will get

> Guys, please stop spamming this thread. If your comment is just another "+1", a thumbs-up reaction on the first message is more than enough. I can relate to your pain, but comments like these don't add any value to the conversation. I rather disagree, this is very annoying to work around and the louder people are about it, the more attention it will get

What about those of us that want a real update when/if it ever happens, without getting 87 spam messages every single day?

This would need to be extended to Claude code cli and the mobile apps too.

+1 from another paying-on-both-sides user.
Two paid plans — Team Premium through my employer for daily Claude Code work across multiple repos and customers, personal Max 5x for independent consulting and personal projects. Different emails, deliberately separated for IP and Commercial Terms vs Consumer Terms reasons. Sign-out / sign-in every switch is real friction.
One thing worth adding to the OP’s request: this should cover the VS Code Claude Code extension too, not just Claude Desktop. The extension has the same pain — one logged-in account at a time, each VS Code window inherits the global login. Being able to set the account per-window (or per-workspace via .claude/settings.json) would let a single VS Code instance host work and personal repos cleanly without launching separate browser-based workarounds.
The community has already shipped working approaches via CLAUDE_CONFIG_DIR (see jean-claude, claude-swap) — would be great to have first-party support so it’s not an env-var hack.

+1

+1 but I would that there should be configurable profiles within a single Claude account. They share plan usage and billing but everything else acts as if they were two separate accounts. This would allow a user to have a work profile and personal profile without having to purchase two claude plans.

+1

+1

+1

+1 to this issue as well. I have an Claude Team plan on my work email address; mainly used for work matters, and I also do have Claude Pro plan on my personal account; used for side-projects. Currently for Claude Code CLI I follow this a reply from #261 for my claude accounts and setting aliases to switch between them: https://github.com/anthropics/claude-code/issues/261#issuecomment-2701757283

However, there are some tasks I would use Claude Desktop and it doesn't natively support the switching of accounts. I have to log out and log in to another account just to research on something or ask an enquiry.

+1

It causes major friction to have to log in and log out of work and personal accounts when I need desktop access for both. Please add this feature Anthropic!

+1

+1

+1

+1

+1
Really needed, I have a personal Max account and an Enterprise account at work and it's really frustrating to log in and out several times a day

+1
Competitors like ChatGPT already have this basic feature.
The obvious use-case is work/personal account switch

Partial workaround for a subset of users — useful if your two accounts can live in different interfaces rather than two profiles inside Desktop itself.

If you have Claude Desktop (Team) + Claude Code CLI (Max) and want them on the same Windows machine running in parallel, you can use NTFS junctions + CLAUDE_CONFIG_DIR to give each its own config dir, MCP roster, memory graph, and session history. The two run simultaneously, no sign-out/sign-in churn.

Doesn't address the in-Desktop profile switcher this issue is asking for — that still needs Anthropic to ship it. But unblocks the Team-at-work + Max-for-personal scenario today.

Full writeup with reproducible scripts: https://github.com/MankhongGarden/claude-code-multi-context-windows

+1

For anyone who needs Claude CLI multi-account on Windows in the meantime (this issue asks for Desktop, but CLI is where most of the heavy quota gets burned anyway), the workaround that holds up well:

1. Per-account config directory — set CLAUDE_CONFIG_DIR to a different folder for each account, e.g. D:\ClaudeData\.claude-work and D:\ClaudeData\.claude-personal.
2. Each folder gets its own .credentials.json, settings.json, MCP config, skills set, memory directory.
3. Wrapper scripts (one .cmd per account) that set CLAUDE_CONFIG_DIR then invoke claude. Put both on PATH so you launch with claude-work vs claude-personal.

This doesn't address the Desktop ask in the OP (UI account switcher, separate conversation history within a single Desktop instance), but it solves the CLI side completely — two independent Claude sessions with no auth cross-talk, no /logout/login required, each context with isolated MCP / skills / memory.

The mobile (#36151) and VSCode (#55621) sister issues look like they need the same primitive (per-account config dir) plumbed through their host apps.

+1 on this, personal and work account switching would be a boost. I use them for different tasks, don't want to conflate the two nor create any conflict of interest in the content or actions

+1
Use-case: Enterprise/Personal account switch

Also, switching between accounts (logout/login) makes the grouping of conversations get lost — the sessions themselves are still on disk, but the custom groups in the sidebar are reset.

Adding my support for this.

The sign-out and sign-in cycle is genuinely disruptive. Every switch means losing conversation context and going through re-authentication, which adds up fast when bouncing between personal and work throughout the day.

The bigger pain for me has been accidentally using my personal account for work tasks, and the other way around, because I forgot which account was signed in. By the time I notice, the usage is already counted against the wrong account. A built-in profile switcher would prevent these mix-ups entirely.

Would love to see this land.

+1

On the same page here with everyone

+1
Use-case: Enterprise/Personal account switch

In the end the only viable solution that I have found was switching to codex for personal projects 🤣

I guess I'm not the only one who came to the same conclusion. Anthropic really shoots itself in the leg by ignoring this issue. People using multiple accounts for economy are doing it anyway using routers. Mostly legitimate users suffer.

Operator-side workaround for those who can't wait on the desktop fix: the same multi-account pain shows up identically in the Claude Code CLI, and the cluster of three related filings (this one, #27302, #36151) now has ~1,178 cumulative reactions across the three platforms.
For the CLI specifically, two new hooks shipped this week in cc-safe-setup (MIT, no telemetry) that address the audit and refusal sides of multi-account CLI workflows:

• account-routing-preflight.sh — SessionStart hook that refuses the session with exit 2 when ANTHROPIC_ACCOUNT_LABEL doesn't match the per-project declaration in .claude/expected-account. Catches the "I forgot to switch accounts before launching" failure mode at session start rather than at the billing dashboard at month-end.
• account-billing-log.sh — Stop hook that appends one pipe-separated line per session to ~/billing-logs/sessions.log capturing timestamp, account label, cwd, session ID, and turn count. For consultants invoicing clients off the same machine.

Important constraint documented in both hooks: a SessionStart hook cannot set the parent claude process's env vars (hooks run as subprocesses). Account switching itself still happens via shell alias or direnv before launch. The hooks are the safety net.
Companion long-form for the five-pattern field guide (shell alias / direnv / ~/.claude symlink / SessionStart preflight / billing log): https://gist.github.com/yurukusa/d880ecc984af5d664f003daf85f956e3 — covers the three personas (work+personal / consultant / enterprise multi-org).
None of this replaces the desktop UX fix this issue is asking for. The hooks are CLI-only and only help the cohort that's already in the terminal. For the desktop, web, and mobile surfaces, the cluster's combined 1,178-reaction signal seems like the relevant case for prioritization.
— independent operator; not affiliated with Anthropic

Until/unless this lands, here are five operator-side paths I documented after running into the same pain across personal + consulting contexts. The right one depends on how you switch (and how often).
1. shell alias / wrapper — alias claude-work='ANTHROPIC_API_KEY=$WORK_KEY claude'. Fastest setup. Right for daily switchers who already have terminal muscle memory.
2. direnv — .envrc per project sets the credential. Switching is automatic by cd. Right for users with one folder per account context (e.g. work-projects/ vs personal-projects/).
3. .claude/ symlink — ~/.claude is a symlink to either ~/.claude.work or ~/.claude.personal. Switching script swaps the link. Right for users where the session state (not just the API key) needs to switch — separate caches, separate logs, separate hooks.
4. SessionStart hook — At session boot, read a marker file (e.g. .cc-account in the project root) and reject the session if the wrong credential is loaded. Right for production-ish setups where the wrong-account risk is a financial / data-leak concern, not a convenience concern.
5. Per-shell PROMPT marker — Display the active account in the prompt so you always know which one is loaded. Combines well with any of the above; reduces "I thought I was on personal" mistakes.
A free 7-question interactive self-audit classifies your persona (work+personal / consultant / enterprise multi-org) and recommends a pattern combination in five minutes. No signup.
The five patterns with worked examples + cross-cluster references (this issue connects to ~1,178 cumulative reactions across #18435 here + #27302 connectors + #36151 mobile) are in the multi-account operator field guide (日本語版).
Two cc-safe-setup hooks shipped specifically for the wrong-account risk:

• account-routing-preflight.sh — SessionStart preflight refusal on mismatch
• account-billing-log.sh — Stop hook per-session billing log for consultants invoicing clients

These are advisory-level operator-side defenses; they don't replace the native multi-account feature this issue is asking for, but they keep the wrong-account category from becoming an incident while we wait.

+1
This is a very basic feature that most compatible tools already provide. It’s a mess that I manage daily, and it wastes a lot of time.

+1
I would also like this feature, but here is a working around that i'm using at the moment with Google Chrome feature of creating web apps:

1. Create a google chrome profile for your personal use
2. Access claude.ai and login with your personal account
3. In Google Chrome settings, you can create a web app for the current page (in this case, claude.ai): settings > Cast, save and share > Install Claude...
4. Optionally you can go to the folder where these chrome apps are installed and edit the file to change its name (this will change how the app name is displayed in your application launcher). For instance, in Linux chrome apps are stored in ~/.local/share/applications. In macOS i believe they're located in ~/Applications/Chrome Apps. In windows i believe it is in %appdata%\Microsoft\Windows\Start Menu\Programs\Chrome Apps (but i didn't check since there is quite some time i dont use windows)
5. Repeat for other profiles (e.g: your work profile)

In the end of the road its just a web page being rendered as it was a standalone app; but tbh it is already good enough for me (i do the same thing for notion in linux since they do not offer a desktop app for the OS, and it was never a problem for me).

Here is an example on how i can launch it in my OS:

<img width="582" height="331" alt="Image" src="https://github.com/user-attachments/assets/46ff07bd-dcee-406f-98d6-7921ee406d07" />

<img width="405" height="241" alt="Image" src="https://github.com/user-attachments/assets/45f306fa-5d86-4759-9443-122ce2ea6a98" />

And here is how they'll look like after this process

<img width="1435" height="828" alt="Image" src="https://github.com/user-attachments/assets/e4198f9e-5f2b-4512-ad76-f625b85dafd2" />

Adding another +1, with one important workflow requirement: switching accounts must not kill or suspend work running under the other account.

My concrete use case is having both a corporate Anthropic account and a personal Anthropic account. I may want to start Claude Code work under the corporate account, quickly switch Claude Desktop to my personal account, start or monitor personal work there, and then switch back to the corporate account to check progress.

Expected behavior:

• Claude Desktop can keep multiple Anthropic accounts signed in at the same time.
• Each account keeps its own Claude Code sessions, auth state, settings, and history.
• Switching the visible account is fast and does not terminate active work from the previous account.
• There is a clear account/profile indicator so I know whether I am operating in personal or corporate context.

This is especially important as Claude Desktop becomes a control plane for Claude Code/Remote Control/Cowork-style workflows. A single-account Desktop app is too limiting for people who split work and personal usage or operate across multiple orgs.

This is a must add with running a business and working for an agency and having a personal account - I need a way to switch between them or have a few instances of the app running alongside each other. Please add this feature I know others having similar issues.

I made a free VS Code extension to switch between multiple Claude Code accounts without logging out

If you use Claude Code with separate work and personal accounts, you know the pain: logging out, logging back in, losing your place every time you switch.

So I built Account Switcher for Claude Code (unofficial, open source). It snapshots each account's local state into named profiles and swaps them with one click from the status bar:

🔄 Switch accounts in seconds — both stay logged in
🔒 Sessions and chats stay fully isolated per account
💾 Automatic timestamped backup before every switch
↩️ Failed switch? It rolls back automatically — plus a "Restore Last Backup" command
🧪 Open source with a full test suite, so you can verify it never touches or logs your tokens
Works in VS Code, code-server, and VSCodium.

VS Code Marketplace: https://marketplace.visualstudio.com/items?itemName=faisalsannan.account-switcher-for-claude-code
Open VSX (code-server/VSCodium): https://open-vsx.org/extension/faisalsannan/account-switcher-for-claude-code
Source + docs: https://github.com/FaisalSannan/account-switcher-for-claude-code

It's completely free — if it saves you time, a ⭐ on GitHub helps others find it. Feedback and issues welcome!
And if it really saves your day, you can buy me a coffee ☕

Hi guys, I had the same issue I decided to create this cli tool https://github.com/yarikleto/claude-profile

It can help you too

For anyone on Windows who needs this today, there’s an open-source workaround worth trying: ai-multi-instance 🛠️

It allows you to launch multiple Claude Desktop instances with a separate --user-data-dir per profile, so you can run multiple accounts side by side with isolated auth, history, and settings. It also solves the OAuth callback problem: normally the claude:// redirect after sign-in lands in whichever install owns the protocol, not the profile you’re trying to log into. The tool optionally registers itself as the claude:// handler (an HKCU registry entry with a valid UserChoice hash, reversible from the menu) and routes the callback to the last profile you launched. MIT licensed, Python standard library only.

This is a real pain point for anyone that uses Claude at work and on their own time. Employers regularly expected employees to use their personal phones for work, which means if you want to remote control your professional work and your personal work, you can't do it.
This doesn't seem like a particularly complicated ability to provide

+1 to this. Native profile switching would still be the best solution, especially for work/personal or client-separated setups.

For anyone on macOS who needs something today, the lightweight workaround is to create a second Claude Desktop app and run it with its own data directory.

Simple version:

cp -R "/Applications/Claude.app" "/Applications/Claude Work.app"
open -n "/Applications/Claude Work.app" --args --user-data-dir="$HOME/Library/Application Support/Claude-Work"

That gives the second app its own local profile data instead of sharing the default Claude Desktop state.

For daily use, there is also a small helper script and Mac-specific write-up that makes the copied app open normally from Finder, Dock, or Spotlight with the separate data dir already wired in.

Still agree this should be native. A built-in profile switcher would be much cleaner than asking users to manage separate app copies.

+1 looking forward

For GUI version I use Claude Desktop Manager (claudeprofiles.com). Does the job for me. Same approach as ai-multi-instance I guess but as a native Windows desktop app instead of a CLI menu.
+1 for the native feature anyway

+1 please do this!!

+1 please do this!!!

Update (Sep 2026) — correcting my own comment: this app is not free any more. It was when I posted this in June; it is now $9.49 on the Microsoft Store, one-time purchase, no subscription. I would rather correct it here than delete the comment, but the word "free" above is wrong and I do not want anyone clicking through on a false promise.

For anyone landing here from search, what it actually does: Multi Instance for Claude Desktop runs several isolated Claude Desktop instances side by side on Windows. Each one gets its own profile, session, account and MCP servers via a separate --user-data-dir, with a dashboard to create, launch and delete them.

https://apps.microsoft.com/detail/9NG247TJ47P0?cid=gh-18435

The underlying limitation has not changed: claude:// deep links are global, so each instance still needs a one-time manual sign-in.

I built a free app that does exactly this — Multi Instance for Claude Desktop. It lets you run multiple isolated Claude Desktop instances side by side. Each instance gets its own profile, session, account, and color. One click to create, one click to launch. No command line, no --user-data-dir flags, no manual setup. Available now, free, on the Microsoft Store: 👉 https://apps.microsoft.com/store/detail/9NG247TJ47P0

My work account for Claude only supports SSO sign-in. I tried your desktop app, but it seemed like it wouldn't open a separate instance when signing in with SSO? Correct me if I'm wrong.

It might be possible that they don't want to implement this lest users abuse this feature by using multiple subscriptions plans.

https://apps.microsoft.com/store/detail/9NG247TJ47P0

@radelqui is it possible to have this on mac as well?

I just created a launcher app that lets you run multiple instances simultaneously with different accounts. You can use it until Anthropics releases an official update.
Claude Desktop Profiles

+1 — strong enterprise need on Windows. Related to the now-closed #36821, which captured the same desktop multi-account pain.

I run a work and a personal Claude account and need both with full Desktop features (Cowork, local MCP, local-folder access). Every current workaround falls short:

• The web app has no local-filesystem access.
• The CLI works (via CLAUDE_CONFIG_DIR) but isn't the Desktop GUI.
• --user-data-dir is silently ignored by the MSIX build, so the second-instance trick no longer works.
• On a managed device (Entra/Intune, ISO 27001), the second-Windows-user / Fast-User-Switching workaround is a compliance problem, not a real solution.

This is partly a regression: the earlier standalone (non-MSIX) Electron/Squirrel Windows build honored --user-data-dir, which allowed running fully isolated instances/profiles side by side. Moving the Windows app to MSIX packaging (single-instance lock + per-user provisioning + sandbox) removed that capability — so behavior that previously enabled multi-profile use is now blocked.

Ask: native in-app ability to run two profiles concurrently in one Windows session. I understand MSIX makes true concurrency non-trivial — but even restoring isolated-instance support (or non-concurrent native account switching without a full sign-out/in) would be a major improvement.

Context: Windows 11, enterprise-managed (Entra/Intune) device.

Personally I think there should be 2 separate apps too. i would like both running so scheduled tasks can always run for each instance. Switching profiles stops anything from continuing on the previous profile. There must be something in works for this, so many people use 1 machine for work and personal.

+1 on this. I regularly switch between a personal Claude account and a client organization's account, and having to sign out/back in each time is a real friction point. A first-class profile switcher (like Chrome or Slack) that keeps both sessions live would be a _massive_ improvement, especially for anyone doing consulting/contractor work across multiple orgs.

Would be just great if switching accounts didn't b0rk / interrupt running sessions in the account being switched away from.

For anyone on Windows landing here while this stays open. A workaround that's held up well for me:

You can launch a second isolated instance with Electron's --user-data-dir flag (separate login, history, MCP config). The one thing that flag doesn't fix on Windows is the taskbar. Both instances share the same icon and Alt-Tab entry, so you can't tell work from personal at a glance.

I put together a small free/open-source launcher that does the --user-data-dir isolation and stamps each instance with its own Windows taskbar identity (separate icon, separate Alt-Tab entry, independently pinnable) via per-window AppUserModelID. MIT licensed: https://github.com/GiovanniTrevisan/claude-multi-account

Not a replacement for native account switching (still hoping for that!), but it makes running two accounts side by side genuinely usable day to day.

I hit this daily, so I built a workaround and open-sourced it: [Lanes](https://lanes.synthetixis.com), a macOS menu-bar launcher that opens Claude Desktop with a separate profile per account. Work and personal run side by side, no signing out.

This removes the compromise you described. Both accounts are the real desktop app now, not one in a browser.

What it isn't: the in-app switcher this issue asks for. No Cmd+Shift+], no single window with a dropdown, it launches separate instances. Parallel windows work better for me, but this doesn't replace the feature request.

How it works: each profile gets its own --user-data-dir. Electron's single-instance lock lives inside that directory, so separate dirs give you genuinely independent parallel sessions — separate login, history, and settings each.

It never touches your auth tokens. No credential copying, no session-file swapping. It only decides which directory each instance writes to. No network calls, no telemetry, no auto-updater.

• https://lanes.synthetixis.com
• https://github.com/synthetixis/lanes (MIT)
• macOS 13+, Apple silicon. Not notarized, so first launch needs "Open Anyway", documented on the page.

Unofficial, not affiliated with Anthropic. Happy to answer questions on the approach. Still want to see this land natively.

Waiting for it since last year 😢

I've tried a couple of the workarounds on this thread, but I need something that supports SSO for my work account for Claude. Has anyone found a multi-instance workaround that supports SSO login for one of the instances?

It this request already on the roadmap? Antropics? Any estimated release date?

My organization is running into the same problem now that we've adopted Claude Team. Its causing corporate work and personal work to accidentally occur in the wrong account because users have to remember to switch accounts each time. A native solution is really important here whether that be the ability to switch profiles or even to be able to have two installations of claude where one is dedicated to each account (similar to Chrome profiles).

My organization is running into the same problem now that we've adopted Claude Team. Its causing corporate work and personal work to accidentally occur in the wrong account because users have to remember to switch accounts each time. A native solution is really important here whether that be the ability to switch profiles or even to be able to have two installations of claude where one is dedicated to each account (similar to Chrome profiles).

You are right. Native solution is really important. But meanwhile if your are on macOS, you should try this: https://lanes.synthetixis.com/

Same need here: easy toggle between personal account Pro and separate (company) Max.
Most pressing needs:

• keep work separated
• able to do remote control on Claude code cli on both

Use case: hard account separation for client confidentiality.

I'm CTO of a startup (company-owned Team seat) and starting independent consulting on a separate personal account. Claude Desktop is my primary working interface, and the two contexts can't be allowed to bleed — connectors, memory, and org data ownership all live at the account level, so folder/project separation isn't enough.

Today that means sign-out/sign-in every time I switch contexts, sometimes multiple times a day. Native profile switching — the way browsers handle separate profiles — would make Desktop viable as a professional multi-client tool rather than a single-org one.

You guys can try this; it just solves this problem, different accounts, and multiple terminals. You can work on any project you might have: https://soromi.dev/ The terminal stays the same, but you can work and switch projects like slack.

@juandl Can you detail how soromi addresses Claude Desktop? This issue is specific to Claude Desktop (ability to easily switch or ideally run multiple instances of Claude Desktop - each instance with it's own separate authenticated subscriptions) for 1 or more personal and work related subscriptions.

Basically different accounts, multiple ~terminal~ Claude Desktop app instances.

How could the desktop app not have this feature when releases is beyond me :D Please add it!

Most of the workarounds in this thread are macOS-only, so here's the Windows version — @cmg-gcaudle, @kintz09, this should cover you.

Copy your Claude shortcut once per account and edit the Target:

"C:\Users\You\AppData\Local\AnthropicClaude\claude.exe" --user-data-dir="C:\Users\You\AppData\Local\ClaudeAccounts\work"

macOS, for completeness:

open -n -a "Claude" --args --user-data-dir="$HOME/Library/Application Support/ClaudeAccounts/work"

If you use Claude Code as well, point its config into the same isolated folder, or auth and sessions bleed across accounts:

export CLAUDE_CONFIG_DIR="$HOME/Library/Application Support/ClaudeAccounts/work/.claude"

@cmg-gcaudle — that last line is exactly your "Desktop Code view shows the wrong Code sessions" problem. The single shared config directory is the cause.

Why this fixes more than it looks like. Electron's single-instance lock lives inside --user-data-dir, so separate dirs give you genuinely independent parallel instances. Nothing is ever "switched", so nothing is ever lost — @simopala82's sidebar groups resetting and @darqueos's context loss both go away, because from the app's point of view you never logged out.

Two traps worth knowing:

• Relaunching the same data-dir can spawn a duplicate instance and risk corrupting that profile. Safer to detect an already-running instance (match on --user-data-dir) and focus that window instead of opening a second copy.
• Use a fresh folder for each account. Don't point it at your existing Claude profile.

If you're on Windows, or you'd rather skip the unsigned-app "Open Anyway" step, I sell a launcher that does all of the above in one click on both platforms — https://deckspace.dev/claude-accounts/ ($14, full source included in the download). On Apple silicon, @mafaqriaz's Lanes is free and MIT and handles the Mac side well. And if the shortcut recipe above is enough for you, just use that — it's the same mechanism underneath.

Unofficial, not affiliated with Anthropic. This is for multiple accounts you own, not account sharing.

My Claude matched email addresses of my clients to folder and created Deny access lists to make sure no files are visible to different account

I am looking for Anthropic to do this in the desktop app first party only, no 3rd party sales / pitches needed here.

On Jul 20, 2026, at 11:40 AM, Juan David @.***> wrote: juandl left a comment (anthropics/claude-code#18435) <https://github.com/anthropics/claude-code/issues/18435#issuecomment-5025856412> Guys!! Guess what? I just released an app under "Soromi" that helps you with this; you can open multiple "Claude Desktop" and log in with different accounts. Free and open source: bento.soromi.dev <https://bento.soromi.dev/> cc: @gmarcus <https://github.com/gmarcus> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/18435?email_source=notifications&email_token=AAANOYBGWBYPQAQXRXZ7BXT5FZRQDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBSGU4DKNRUGEZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5025856412>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANOYHAS3LZS6XSS6YG76D5FZRQDAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOBRHE2DONZWGU4KC5QC>. You are receiving this because you commented.

I am happy to use a workaround, would probably even pay for one, but for me it must 1) support SSO sign-in for my work Claude account, and 2) work on Windows.

Do any of the workarounds above support both of those requirements?

I've tried a few of the workarounds so far, but seemed like SSO didn't work for any of them...?

https://deckspace.dev/claude-accounts/. try this

I've made my own my app to manage my Claude Desktop profiles, feel free to try it out and send me some feedback: https://github.com/odahcam/claude-desktop-profiles

<img height="175" alt="Image" src="https://github.com/user-attachments/assets/e275fc4c-54fd-4762-86b4-dfc66faab6db" />

<img height="175" alt="Image" src="https://github.com/user-attachments/assets/c2075111-7326-4857-ba86-ac24e0d81c58" />

https://deckspace.dev/claude-accounts/. try this

Confirming, I got this working for me on Windows with my personal (sign in with Google) and my work (sign in with SSO)

@weineran Thank you for confirming here — and for the detailed field report you sent by email. That report turned into today's update: v2.6 now routes SSO / Google / magic-link sign-ins straight to the account window that asked for them on Windows, so the finagling you described isn't needed anymore. (macOS was already fine — it authenticates in-process.) One sign-in at a time, via the graphical launcher, and it comes back to the right window automatically.

For anyone else who needs multiple Claude desktop accounts side by side — including SSO-only work accounts, which as this thread shows no other workaround handles: https://deckspace.dev/claude-accounts/ ($14 one-time, Mac + Windows). Existing buyers: it's a free update — re-download from your receipt link.

I hit this daily, so I built a workaround and open-sourced it: [Lanes](https://lanes.synthetixis.com), a macOS menu-bar launcher that opens Claude Desktop with a separate profile per account. Work and personal run side by side, no signing out. This removes the compromise you described. Both accounts are the real desktop app now, not one in a browser. What it isn't: the in-app switcher this issue asks for. No Cmd+Shift+], no single window with a dropdown, it launches separate instances. Parallel windows work better for me, but this doesn't replace the feature request. How it works: each profile gets its own --user-data-dir. Electron's single-instance lock lives inside that directory, so separate dirs give you genuinely independent parallel sessions — separate login, history, and settings each. It never touches your auth tokens. No credential copying, no session-file swapping. It only decides which directory each instance writes to. No network calls, no telemetry, no auto-updater. https://lanes.synthetixis.com https://github.com/synthetixis/lanes (MIT) * macOS 13+, Apple silicon. Not notarized, so first launch needs "Open Anyway", documented on the page. Unofficial, not affiliated with Anthropic. Happy to answer questions on the approach. Still want to see this land natively.

Working well for me. I had Claude Fable run a security review first and it came back clean.

Would still rather have an official solution, but it is what it is.

One thing worth knowing before you try any of the workarounds here, because it caught several people in this thread: --user-data-dir alone does not survive an SSO sign-in on Windows.

The reason is platform-specific:

• macOS — Claude signs in through a native, in-process auth session. The callback comes back inside the same instance, so an isolated profile authenticates fine. Every Mac launcher here works for this reason.
• Windows — there is no native session. Sign-in leaves for your system browser and returns as a claude:// deep link, which starts a fresh default-profile window. Claude also holds no single-instance lock, so nothing redirects it. Your work account lands in the wrong instance, every time. A per-profile data dir can't fix this, because the break happens outside the profile.

That's why "works on my machine" reports pass on Mac and fail on Windows with a work account — it isn't a bug in anyone's launcher, it's where the callback lands.

We route that callback back to the window that actually asked for it. It isn't theoretical: @weineran tested it against a real corporate IdP on Windows and confirmed it here, and his field report is what shipped as v2.6 yesterday. It's in daily use on both Mac and Windows, and it goes through a Windows test suite on every change rather than a one-off manual check.

If SSO + Windows is your blocker, try it: https://deckspace.dev/claude-accounts/ — $14 one-time, 7-day refund, so you can verify it against your own IdP rather than take my word for it. If you're on Mac only, or your accounts are all email/Google logins, the free options in this thread will genuinely serve you and I'd start there.

Still want the native in-app switcher. Until it lands, this is the gap that nothing else covers.

This conversation is moving away from the original intent of the feature
request. To clarify, the request is specifically for a first-party account
switching mechanism from Anthropic within the Claude Desktop app (not the
CLI).

The goal is to allow users with multiple subscriptions to switch between
accounts seamlessly, ensuring total data isolation and zero leakage between
profiles.

I would appreciate it if we could keep this thread focused on the native
feature request rather than pitching or troubleshooting third-party
workarounds.

On Tue, 21 Jul 2026 at 10:23, Samic333 @.***> wrote:

Samic333 left a comment (anthropics/claude-code#18435) <https://github.com/anthropics/claude-code/issues/18435#issuecomment-5036997125> One thing worth knowing before you try any of the workarounds here, because it caught several people in this thread: --user-data-dir alone does not survive an SSO sign-in on Windows. The reason is platform-specific: - macOS — Claude signs in through a native, in-process auth session. The callback comes back inside the same instance, so an isolated profile authenticates fine. Every Mac launcher here works for this reason. - Windows — there is no native session. Sign-in leaves for your system browser and returns as a claude:// deep link, which starts a fresh default-profile window. Claude also holds no single-instance lock, so nothing redirects it. Your work account lands in the wrong instance, every time. A per-profile data dir can't fix this, because the break happens outside the profile. That's why "works on my machine" reports pass on Mac and fail on Windows with a work account — it isn't a bug in anyone's launcher, it's where the callback lands. We route that callback back to the window that actually asked for it. It isn't theoretical: @weineran <https://github.com/weineran> tested it against a real corporate IdP on Windows and confirmed it here <https://github.com/anthropics/claude-code/issues/18435#issuecomment-5028823644>, and his field report is what shipped as v2.6 yesterday. It's in daily use on both Mac and Windows, and it goes through a Windows test suite on every change rather than a one-off manual check. If SSO + Windows is your blocker, try it: https://deckspace.dev/claude-accounts/ — $14 one-time, 7-day refund, so you can verify it against your own IdP rather than take my word for it. If you're on Mac only, or your accounts are all email/Google logins, the free options in this thread will genuinely serve you and I'd start there. Still want the native in-app switcher. Until it lands, this is the gap that nothing else covers. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/18435?email_source=notifications&email_token=AAANOYCJUD7N44CMAEIIY235F6RILA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBTGY4TSNZRGI22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5036997125>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANOYHIYE6MRE3DCFBODJ35F6RILAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOBRHE2DONZWGU4KC5QC> . You are receiving this because you were mentioned.Message ID: @.***>

Update (Sep 2026): this thread is about switching accounts, so the thing worth adding is that each instance can now run on a different AI engine, not just a different Anthropic account.

One window stays on your Anthropic subscription while another runs on Kimi (Moonshot), GLM (Z.AI), DeepSeek, OpenAI, OpenRouter or a local Ollama model. That is mostly what you want when you hit a weekly limit: you keep the same Claude Desktop harness and the other window carries on somewhere else instead of you stopping.

The mechanism matters more than the pitch, so: ANTHROPIC_BASE_URL is a global environment variable, which is why doing this by hand flips every window at once. Here each instance carries its own token and a small local bridge resolves token to instance to engine to key, so per-window routing actually holds. The model name gets rewritten in flight as well, because Claude Desktop sends claude-opus-5 and Kimi has no idea what that is; without the rewrite you just get 400s and blame your key.

Disclosure: these are mine, and both are $9.49 on the Microsoft Store. They were free when I first commented in this thread, which I have corrected above.

The per-instance engine lives in Multi Instance Pro: https://apps.microsoft.com/detail/9N3X1FSCLMWK?cid=gh-18435-engine

If all you want is several isolated Claude Desktop accounts side by side and you do not care about other providers, the plain Multi Instance for Claude Desktop is the one: https://apps.microsoft.com/detail/9NG247TJ47P0?cid=gh-18435

Worth knowing what the hard part on Windows actually is, because it decides whether any of these tools works for you.

Every multi-instance workaround (this one, the free Mac launchers, mine) is the same trick underneath: run the official app with its own --user-data-dir so each window is an isolated profile. That part is easy and it works.

Sign-in is where the platforms split:

• macOS — the app runs browser-based sign-in (Google, magic-link, enterprise SSO) through a native in-process auth session, so the callback comes back to the window that asked for it. Isolated instances just work. If you're on a Mac, the free launchers in this thread are genuinely fine — use them.
• Windows — there's 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, not 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.

@radelqui — genuinely curious whether yours handles that, since it's Windows-first: if you create a second profile and sign into it with Google or company SSO (not an email+password account), does the session actually land in that profile? That's the case that broke every version I tried before I went and fixed it.

I sell a paid one that does route those callbacks to the right profile on Windows: https://deckspace.dev/claude-accounts/ ($14 one-time, Mac + Windows, unofficial, not affiliated with Anthropic). Rather than take my word for it — @weineran posted his own results here after using it with a personal Google account and his work SSO: https://github.com/anthropics/claude-code/issues/18435#issuecomment-5028823644. There's a 7-day refund if it doesn't do what you need.

And to be clear about scope: if you're Mac-only, or you sign in with email+password, you do not need to pay anyone — the free options here cover you. The Windows SSO callback is the only thing I'd claim is different.

All of this is duct tape over a missing feature. A real account switcher in the app is what everyone in this thread actually wants — worth upvoting the issue.

Small update for people following the workaround landscape here, because the ground shifted a little this month.

Every tool in this thread (and the CLI-side ones like claude-swap) works the same way underneath: give each account its own place to keep state, then point Claude at it. For the Desktop app that's --user-data-dir; for Claude Code it's CLAUDE_CONFIG_DIR. The two never met — Desktop ignores CLAUDE_CONFIG_DIR entirely, and the CLI switchers don't touch Desktop windows.

Claude Accounts v2.8 (the $14 utility I've mentioned upthread) now joins the two sides: any isolated Desktop account can also open a terminal running Claude Code as that account — same identity in the window and the terminal, separate login/history/settings per account, sessions running side by side. Credentials stay wherever Claude Code itself puts them (Keychain on macOS, per-config-dir file on Windows); nothing is copied or rotated, and nothing about your rate limits changes.

Honest scoping, as always: if you're Mac-only and terminal-only, claude-swap covers you for free — including the VS Code extension, which we don't cover (the extension ignores the env var: #30538). Where ours earns its $14 is the Desktop app itself plus browser-based SSO sign-in on Windows (weineran's confirmation upthread remains the best third-party evidence for that case). Mac + Windows in one purchase, full source included in the download, 7-day no-questions refund: https://deckspace.dev/claude-accounts/?src=github

And a native switcher from Anthropic would still make all of this unnecessary — that's what this issue is actually asking for, and it's the right ask.

Can do this easily using the (Electron) app for Linux. Unfortunately Windows uses the MSIX/UWP abomination.

@Samic333 please stop promoting your app or at the very least make it free for everyone to use in the interim.
This issue is about a native solution, not an ad-spot.

Hey guys, put together a workaround that's been working well for me. Two separate Claude apps, each with its own login and its own Dock icon, both running at the same time.

Repo: https://github.com/brunorodmoreira/claude-desktop-multi-account

The bit I haven't seen mentioned anywhere: the app reads CLAUDE_USER_DATA_DIR and honors it from the LSEnvironment dict in Info.plist, so it survives Dock and Spotlight launches. The usual --user-data-dir trick doesn't.

A couple of rough edges I haven't sorted out: the clone doesn't auto-update, so you re-run the script after Claude updates, and passkey login doesn't work in it (email and Google are fine). Neither bothers me day to day.

Would still love the native switcher though.

<img width="434" height="140" alt="Image" src="https://github.com/user-attachments/assets/a000f841-0957-4051-870b-1fe027d6aa4a" />

@Multiply I hear you, and I'm sorry it's reading as an ad spot — that genuinely isn't how it's meant.

Everyone in here wants the same thing: a native switcher. Until that lands, people are stuck, and a few of us went off and built something so we're not stuck in the meantime. What I've posted has been about that — and most of it came straight out of this thread. @weineran's Windows report is the reason SSO sign-ins route back to the right window now. Others emailed me failures I couldn't reproduce, and those became the next build. Six weeks of this has been fixing what people here told me was broken. I'll keep the updates short and save them for when something actually changes what's possible — but I'd rather post a fix than sit on it.

On making it free, I'd gently push back on the framing. Everyone who ships something in this thread gets something back for their time. For an open-source repo it's stars, reputation, users, maybe an opportunity down the line. For me it's $14 once — no subscription, no per-seat pricing, and every update free forever to anyone who's already bought. Different currency, same idea: the person doing the work gets a little something, and that's what keeps a tool maintained instead of going quiet after the first release. I don't think either of those is the wrong way to do it.

And there are genuinely free options here that work well on macOS — @odahcam's, Lanes, and @brunorodmoreira's just above. If you're on a Mac, those cost nothing and I'd point you at them before mine.

We're all chipping at the same annoyance from different angles, and everyone here is better off for it. No hard feelings on the nudge — it was a reasonable thing to say.

+1 — this would be very useful for my own work/personal setup. I have separate company and personal email accounts, so I cannot use the existing same-email workspace switcher. A quick native account/profile switcher would let me keep the two contexts properly separated without repeatedly signing out and back in.

I need this as well in Mac Desktop - need to run personal, consulting, and work side by side simultaneously. My workaround for this - just got blown up in latest Claude update and all my Claude code work is fu&$*$($

@atemyshorts — that's the Claude auto-update, and it's worth knowing because it hits every workaround in this thread, not just one.

Claude Desktop updates itself by relaunching the app bundle, and the --user-data-dir your account window was opened with doesn't survive that relaunch. The window comes back on the default profile, so the Dock icons no longer match the accounts you opened them for. Nothing is lost — the profiles are all still on disk. Quit your account windows before letting Claude update, reopen them after, and you're back.

The next version handles it for you: it works out which account each window is really on rather than trusting how it was launched, and it tells you when Claude has updated underneath you so you can reopen everything in one click.

That one came in from a user, which is how most of it gets built. @weineran upthread, and a good number of people by email, have asked for things I'd never have found on my own — company SSO sign-in, Claude Code terminals per account, running on locked-down work machines. The app worked fine without any of it; it's better with it, and it's better because people asked. A lot of good feedback landed after my last comment here, and it's all gone the same way.

Everything above applies whichever tool you use — Bento, Lanes, claude-desktop-profiles, or the plain --user-data-dir trick. If you'd rather not maintain your own, mine is here: https://deckspace.dev/claude-accounts/

And I'm still hoping Anthropic ships the native switcher and makes all of this redundant.

+1

On checking before you trust it — fair for anything in this thread, mine included:

Claude Accounts ships as source. On Windows it is the source: a PowerShell script and a batch file, nothing compiled, so you can read every line before you run it. The Mac download includes the Swift source and the build script alongside the app, so you can rebuild it yourself if you'd rather. Read it, change it, keep the parts you want.

It's tested and in daily use on both platforms.

The free workarounds people have posted here are genuinely good. If one of them covers your setup, use it — I'd rather you kept your money.

https://deckspace.dev/claude-accounts/?src=github — unofficial, not affiliated with Anthropic; for multiple accounts you own.

Still hoping for the native switcher. That's the thing that would make all of this unnecessary.

+1, hitting this exact issue. I have Claude Desktop installed with my work account, but need to use Cowork scheduled tasks with my personal account on the same machine. Since scheduled tasks require Claude Desktop to be open, I can't currently automate personal workflows without either logging out of my work account repeatedly or resorting to unofficial workarounds (duplicated app installs, separate data-folder profiles).

The web UI already supports switching between orgs under the same email — extending that same model to accounts with different emails (like Slack/Chrome profiles) would solve this cleanly, and would make Cowork scheduled tasks actually usable for anyone splitting work/personal on one device.

Most of the thread is about workarounds, so here's the mechanism underneath them — it explains why
every workaround looks the way it does, and where a native fix would actually sit.

The credential is fixed when the session process is spawned. The desktop app puts an OAuth token
on the CLI process before any shell runs, so nothing on the machine — shell profile, ssh environment,
a wrapper — can select which account a session bills. It's read once, at process birth.

Two lines from inside an app-spawned session, neither of which prints a token:

# the session process carries a credential…
ps eww -p "$(ps -o ppid= -p $$ | tr -d ' ')" | grep -c CLAUDE_CODE_OAUTH_TOKEN   # → 1
# …while the machine's own login shell has none
sh -lc '[ -n "$CLAUDE_CODE_OAUTH_TOKEN" ] && echo set || echo unset'             # → unset

The session bills an account that exists nowhere in the machine's environment, so it can only have
arrived at spawn. That's the whole constraint, and it's why the workarounds in this thread all end up
running separate app instances rather than switching inside one.

Two things already work, which narrows what's actually missing.

The conversation is a local, account-agnostic transcript. claude --resume <session-id> under a
different credential continues the exact same thread — no history is lost and nothing needs
migrating. So the "lose my current context" part of the original report is already solvable; it's the
credential selection that isn't.

And Remote Control binds to the session, not to the credential. On a desktop remote session I've
had a phone signed into a different account keep rendering and driving a thread across an account
switch. An account-portable thread identity already ships in Claude Code — on the most constrained
surface there is.

So the gap is narrower than the thread suggests. Not "build multi-account", but:

1. A supported credential-selection point for app-spawned sessions — an env var, a config key, or a

per-session flag honored at spawn.

1. Documenting resume-across-accounts as supported behavior. It works today and it is the piece that

makes switching non-destructive.

1. A visible indicator of which account a session is billing when it differs from the app login.

One note on the design discussion above: the original request asks for separate history per account,
and several comments assume that's required. Because the transcript is account-agnostic, it isn't —
per-account history and movable threads are independent choices, and the second one is already
possible today.

Disclosure: I maintain an open-source tool in this space, so I've spent a while measuring this. Happy
to share more measurements or test a build if it's useful.

Can we please get an official response from Anthropic regarding this?

As an AI developer, I routinely get to 100% limit (both on the 5-hour limit and weekly), even on Max 20. In order to maximise my development time, I need to run 2 Claude Windows Desktop apps at the same time, each running a different account. Or, 1 app, with 2 accounts running.

There's lots of workarounds (which I'm grateful for) but no official solution to this problem (at least when using Claude Windows app) Surely, Anthropic can see the need for this?

Windows is the hard case here. There's no native auth session, so sign-in leaves for the system browser and comes back as a claude:// deep link — Windows hands that to the registered protocol handler, which opens a fresh default-profile window rather than the isolated instance that asked for it. So the second account's login completes in the first window. A separate data directory can't fix it, because the break happens outside the profile. (CLAUDE_CONFIG_DIR won't help either — that's CLI-only, Desktop ignores it.)

I hit this and built a launcher that routes the deep link so two Desktop instances stay signed into different accounts at once. Works on Windows and macOS: https://deckspace.dev/claude-accounts/

+1 on the native switcher, though. None of this should be necessary.

+1

Built a simple CLI tool to support multiple claude sessions per project claude-account

Hey!
I'm a freelancer with 2-6 clients. Each one gives me a seat in their own Claude
org, so the usage lands on their bill.

The problem isn't the sign-out friction. It's that I start a task in one repo,
and while it runs I switch to another repo and start something there. Switching
accounts means signing out, which kills whatever is still running. So I can only
work with one client at a time.

What I need: Desktop holding several accounts at once, with each project bound to
one of them. A global account switcher wouldn't help — it'd still interrupt
running work.

Sorry, to take this off thread for a second but this issue is what comes up when searching for "Multiple accounts in Claude Code CLI" and I'm wondering if there is a more correct one specific to Claude Code CLI.

Adding a case that's different from the switching request above: I need concurrent profiles, not sequential ones.

I'm an IT professional running systems for three separate businesses. Switching one-at-a-time wouldn't help me — cross-company work is the job. I need two Claude Desktop instances open at once with separate data, the way Chrome profiles work.

The standard advice — separate macOS user accounts — isn't a workaround for this. It's a different, worse problem:

• Background jobs stop. launchd agents, scheduled syncs and data pipelines don't run in a logged-out account. Anything user-scoped silently dies for whichever company I'm not currently signed into. I find out when a nightly ingest didn't happen.
• Notifications never arrive. Alerts from the other company's Teams, Outlook and ClickUp simply don't reach me until I switch. When you're on the hook for multiple businesses' systems, that isn't friction — it's an outage you don't know about.
• You can't work across companies at all. No shared clipboard, no shared files, no single view of the day. Answering one company's question while working in another's account means logging out, or emailing myself.

(It also breaks Universal Control — two logged-in macOS sessions each run their own UniversalControl agent and they fight over the device advertisement until the link drops. Minor next to the above, but it's another thing the workaround costs.)

The mechanism already exists. Claude Desktop reads CLAUDE_USER_DATA_DIR and relocates userData and logs to it. But in packaged builds the app deletes that variable from its own environment unless a signed CLAUDE_CDP_AUTH token is present, verified against a hardcoded Ed25519 key. Command-line switches are rejected outright, and there's a separate userData relocated check on top of that.

I understand why that's locked down. But it means this isn't "build profile support" from scratch — it's "expose something that already ships." Even a coarse version would solve it: a documented flag, or profiles the app manages itself.

Check my repos as there s one titled claude multiple login or a short distance of that. It works concurrently. Good day!

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Spencer Garner @.*>
Sent: Monday, 31 August 2026 19:54:59
To: anthropics/claude-code @.*>
Cc: Christian IVĂNESCU-MASSINI (148980) @.>; Comment @.>
Subject: Re: [anthropics/claude-code] [FEATURE] Add the ability to manage multiple Claude accounts within the Claude Desktop app with easy switching between profiles. (Issue #18435)

[https://avatars.githubusercontent.com/u/17488257?s=20&v=4]cybervanes left a comment (anthropics/claude-code#18435)<https://github.com/anthropics/claude-code/issues/18435#issuecomment-5481588366>

Adding a case that's different from the switching request above: I need concurrent profiles, not sequential ones.

I'm an IT professional running systems for three separate businesses. Switching one-at-a-time wouldn't help me — cross-company work is the job. I need two Claude Desktop instances open at once with separate data, the way Chrome profiles work.

The standard advice — separate macOS user accounts — isn't a workaround for this. It's a different, worse problem:

• Background jobs stop. launchd agents, scheduled syncs and data pipelines don't run in a logged-out account. Anything user-scoped silently dies for whichever company I'm not currently signed into. I find out when a nightly ingest didn't happen.
• Notifications never arrive. Alerts from the other company's Teams, Outlook and ClickUp simply don't reach me until I switch. When you're on the hook for multiple businesses' systems, that isn't friction — it's an outage you don't know about.
• You can't work across companies at all. No shared clipboard, no shared files, no single view of the day. Answering one company's question while working in another's account means logging out, or emailing myself.

(It also breaks Universal Control — two logged-in macOS sessions each run their own UniversalControl agent and they fight over the device advertisement until the link drops. Minor next to the above, but it's another thing the workaround costs.)

The mechanism already exists. Claude Desktop reads CLAUDE_USER_DATA_DIR and relocates userData and logs to it. But in packaged builds the app deletes that variable from its own environment unless a signed CLAUDE_CDP_AUTH token is present, verified against a hardcoded Ed25519 key. Command-line switches are rejected outright, and there's a separate userData relocated check on top of that.

I understand why that's locked down. But it means this isn't "build profile support" from scratch — it's "expose something that already ships." Even a coarse version would solve it: a documented flag, or profiles the app manages itself.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/18435?email_source=notifications&email_token=B2OKF4GGNEWH737MP4EIJ7D5MWUWHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBYGE2TQOBTGY3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5481588366>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B2OKF4AXIWHA5BLM5ECIRAD5MWUWHAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TGOBRHE2DONZWGU4KC5QC>.
You are receiving this because you commented.Message ID: @.***>

@cybervanes On "command-line switches are rejected outright" — a data point from today (macOS, Claude Desktop 1.40609.0, the current build): launching a second instance of the official app with --user-data-dir=<dir> still works. The spawned process and all its helpers carry the flag, the isolated profile populates in the target directory, and the default profile is untouched. It's the env-var route that's locked down, not the flag.

So the concurrent case you describe — several instances side by side, Chrome-profiles style, with notifications, background jobs and clipboard all in one macOS session — is possible today without separate user accounts. If you'd rather not script and maintain that yourself, this is what my launcher does; you can try it here: https://deckspace.dev/claude-accounts/ — it also handles Windows, where sign-in round-trips through the system browser and lands in the default profile, which a data-dir flag alone can't fix.

+1 to profiles the app manages itself, though — that's the real fix.

PLEASE add a feature to allow me to switch between my work and personal account, which are NOT connected to the same email address. The current switch only allows for a personal account with my work email which makes no sense at all. It takes 4 minutes to get a login code and by the time it comes in with a 10 minute limit, I've multi-tasked away to something else and I miss the 10 minute window. My usage of Claude would probably go up by 30-50% if you fixed this.

The ask, stated precisely

I need two fully independent, simultaneously live Claude desktop sessions running on the same Mac — each signed into a different account, each with its own working state, both active and usable at the same time, side by side.

This is explicitly not a request for account switching. Switching means one context is always suspended while the other is active — sign out, sign back in, lose your place, repeat. That is not the workflow. The workflow is having both open, both alive, both usable in the same ten minutes, the way you'd have two browser windows or two terminal tabs open at once. Right now, the Claude desktop app cannot do this — it supports exactly one signed-in identity, full stop.

Why account switching doesn't solve this

Account switching treats the problem as "I occasionally need to change hats." That's not what's happening. The actual pattern is: I am doing work in Account A, and without closing that work, I need to check something, respond to something, or actively work in Account B, and then come back to A mid-thought. Switching accounts:

Tears down live session state in whichever account you're leaving
Makes it impossible to reference or copy between the two contexts in real time
Trains people into workarounds — like running the CLI in one account and the desktop app in another, or having two people's logins active in overlapping windows — and those workarounds are exactly what caused real, tangible data problems for me this week: two separate coding projects lost their session history because two account contexts touching the same local config file overwrote each other's state. That wasn't a hypothetical risk. That cost me the better part of a day chasing down what looked like — and for one project's chat history, turned out to actually be — lost work.

A tool that can't hold two identities open at once doesn't just create friction. It creates a shared-state hazard the moment a user tries to work around the limitation, because the underlying local storage was never designed to be safely touched by two identities in the same window of time.

Who actually needs this — and why it's not a niche ask

Remote and hybrid employees with a personal account. Nearly every white-collar remote worker now has an employer-managed AI seat and, separately, a personal subscription they pay for out of pocket for their own projects, learning, or side work. These two contexts are not supposed to touch — mixing employer-managed data governance with personal use is exactly the kind of blending IT and legal teams spend real effort preventing. Forcing someone to log out of the employer account to use their personal one (or vice versa) doesn't enforce separation — it just makes people avoid the tool for one of the two purposes, or worse, get sloppy about which one they're in.

Independent contractors and consultants working multiple clients. This is the group I'd push hardest on. A contractor with three active clients often has three separate organizational accounts, each with its own billing, its own data-handling agreement, and — critically — its own conflict-of-interest boundary. A consultant needs to be able to have Client A's engagement open in one live session and Client B's in another, because real consulting work involves moving between client contexts within the same working session, not in tidy sequential blocks. An app that can only be one client at a time isn't just inconvenient for this group — it actively discourages the account separation that protects both the contractor and the client. If the tool makes proper separation painful, people take shortcuts, and shortcuts are how client data ends up somewhere it shouldn't.

Agencies and studios managing several client organizations. Same shape as the contractor case, scaled up. An agency employee routinely needs live access to more than one client's Claude org in a single day, sometimes in the same hour, without a teardown-and-rebuild cycle between them.

IT and technology leaders evaluating the platform for their own organization — which is exactly my seat. I need to run this both as an end user inside my employer's managed environment and, independently, as someone building and testing my own applications on my own account, at the same time, on the same machine, without one corrupting the other's local state. If I can't trust the desktop app to hold two identities cleanly, that's a real mark against recommending it for deployment to an organization where dozens of people will have exactly this same dual-context need — personal device, managed work account, no clean way to keep them apart.

What "solved" looks like

Not a shell alias. Not a third-party app that clones the .app bundle and redirects its data folder as a workaround (which is the current best option, and which I only found by researching third-party tools because the platform doesn't offer this natively). Not a virtual machine. Two identities, two live windows, natively supported, each with its own isolated local state, running in the desktop app at the same time — the way any serious multi-tenant productivity tool already handles this today.

This isn't an edge case. It's the default working pattern for remote employees, contractors, consultants, and agency staff — which is to say, an increasingly large share of the actual user base. The tool should be built for how people already work, not the other way around.

Well-said @atemyshorts, I also need multiple accounts sunning simultaneously, prviate + clients, each own with its own memory, physical isolation of access etc. You can't make Claude an enterprise tool without something like this

@atemyshorts @moseleyi — the distinction you're drawing is the one that actually matters, and I don't think it's been said plainly here: almost every workaround in this thread is serial. CLAUDE_CONFIG_DIR, shell aliases, the CLI switchers — they change which account is active. What you're describing needs both instances alive at the same time, each with its own local state.

That part does work on macOS today, and it doesn't involve cloning the .app bundle: launch the official app a second time with --user-data-dir=<dir> and you get a fully isolated instance beside the first — own window, own history, own Claude Code state — with your default profile untouched. @atemyshorts, that's also the likely cause of the overwrite you hit: without a separate data dir, both identities write the same config file.

If you'd rather not build and maintain that yourself, that's what my launcher does: https://deckspace.dev/claude-accounts/ — it also handles Windows, where sign-in leaves for the system browser and comes back into the default profile, which a data-dir flag alone can't fix. It ships its source, so you can read it before you run it. And if you're on macOS with a Google login, the free tools already mentioned here (bento, Lanes, claude-desktop-profiles) genuinely work — start there.

Native profiles managed by the app are still the right answer, though. +1 to the request.

+1, and adding scope that isn't fully covered in the original request:

This need extends beyond Desktop. As freelancers switching between clients' Teams accounts throughout the day, the same friction exists in:

Claude Code CLI — the current workaround is CLAUDE_CONFIG_DIR, but it only isolates the terminal, not chat history or the Desktop app.
Claude Code VS Code extension — no equivalent switching mechanism today.

Two things that would make this much stronger:

Consistent switching across all three surfaces (Desktop, CLI, VS Code extension), not a separate mechanism per surface.
Confidentiality / clean separation — when working on a client's machine or on multiple clients, no account should leave traces of another, and access should be easy to revoke when an engagement ends. (See #91770 for a related take on per-profile isolation and profile-scoped sign-in.)

Right now the only real alternatives are a paid account per client (limits don't pool) or constant sign-out/sign-in, neither of which scales for a single freelancer working across several clients and machines.

Thanks — #91770 author here. Our cases differ (you switch between clients' own Team accounts; I'm one subscription needing isolated profiles), but they converge on the same missing piece: a credential scoped to one context that can't reach the others and can be revoked per engagement. Whichever design gets built first, that isolation is the part that matters — in Desktop, the CLI and the IDE extensions alike.

Adding a concrete symptom of this limitation: I pay for two separate Claude accounts and use both in Claude Desktop. When I switch from one account to the other, tasks actively running on the first account appear to pause — progress stops until I switch back. Since the docs say cloud sessions should keep running in the background regardless of the app UI, this suggests the "switch" is effectively a sign-out/sign-in rather than a real concurrent session, which defeats the purpose of paying for two accounts. Native multi-account support (or at least not interrupting in-flight tasks on switch) would fix this.

@dleroy78 — that pause is the switch being a sign-out, not a second session. One Desktop instance can only be one identity, so the account you leave stops driving its local tasks until you switch back. Cloud work can keep running on Anthropic's side; the window you just left is no longer that account.

What actually matches “I pay for two accounts” is two Desktop windows open at once, each signed into its own account, each with its own local state. Then neither side has to yield.

That’s what this launcher does: https://deckspace.dev/claude-accounts/

Native multi-account in the app is still the real fix. +1.

Until profiles exist, one piece of this can be worked around today. Claude Code history in Desktop is only hidden on a switch. The transcripts are shared and the sidebar records sit in a per-account and organization folder. I wrote an open-source tool that moves those records to the account you switch to https://github.com/vitaliyhayda/claude-transplant

Another workaround for the Desktop side of this, complementary to claude-transplant above. The Code sidebar records live in a per-account/org folder while the transcripts are shared, so the history is only hidden on a switch, not lost.

claude-code-multi-account-bridge keeps the per-account folders merged rather than moving them: both accounts always list every session, an archive or delete on one account carries to the other, and a macOS LaunchAgent does it in the background, so there is nothing to run when you switch. Merge rule is newest copy wins, tombstones win; backups before every write; Python 3.9 stdlib, no dependencies.

https://github.com/ramonmazinga/claude-code-multi-account-bridge

Pick transplant if you want one list that follows you, the bridge if you want two lists that stay identical. Neither replaces real profiles; still hoping for the native feature.

Another workaround for the Desktop side, going one step further than the sidebar-record tools above: it removes the sign-out/sign-in entirely.

claude-desktop-profiles-macos gives Claude Desktop profiles the way Chrome and Slack have them. Each profile keeps its own sign-in; a menu bar app switches between them (the app relaunches, ~10 s). Code-tab sessions carry over to whichever profile is active, and sessions from the Claude Code CLI / VS Code extension can be imported into the app's sidebar.

It works by parking the app's data directory per profile and swapping it in on a switch — no tokens are read or copied, sign-in always goes through Claude's own flow. Unofficial, MIT, macOS only; it relies on the internal layout, so an app update may break it.

Native profiles would obviously be the real fix — happy to retire this the day that ships.

+1 from a solo operator running three businesses on three separate Claude accounts (different emails).

I switch several times a day. Each switch currently means sign-out / sign-in, and every connector (Gmail, Calendar, Drive) flips with it, so work stops each time. Chrome-profile-style switching between already-signed-in accounts, with the current session kept open, would remove most of that friction.

Two related notes from daily use:

• Workaround cost: I run separate macOS user accounts per Claude account and use Fast User Switching. Because only one user can own the console session, apps that depend on the microphone or Accessibility APIs (voice-input tools, LINE) stop working or need re-authorization on every switch. In-app account switching would make this whole setup unnecessary.
• After one switch, the account reported to the model (the userEmail context) differed from the account actually signed in, which caused real confusion mid-session. Whatever the switcher looks like, the active account should be shown consistently to both the user and the model.

+1
same here and also tried web for the second account but not the same experience

it was shipped to mobile app - hopefully this one will follow soon

@sachi0223 The Fast User Switching cost has a specific cause worth naming: only one macOS login session owns the console, and Accessibility/microphone grants follow it. That's what separate login accounts do — nothing about Claude causes it. Two sign-ins inside one login session avoids it completely; the TCC grants are keyed to the app bundle, so a second instance inherits them.

Your second point is the sharper one. A stale userEmail is what an instance with two identities over time looks like. An instance that never switches has nothing to go stale.

On the tools posted this week — claude-transplant, the bridge, and claude-desktop-profiles-macos — they solve a real half of this and solve it well: your history follows you across a switch. But all three are still serial. One account is live, and erorplex's relaunches the app (~10s) to change which. That's switch faster, not don't switch.

If you want both live at once: on macOS the official app already accepts --user-data-dir=<dir>. Launch it a second time and you get a fully isolated instance beside the first — own window, own history, own Code state. Free, no tooling. Do that before paying anyone.

Windows is the case that flag can't reach. There's no native auth session, so sign-in leaves for the system browser and returns as a claude:// deep link, which Windows hands to a new default-profile window — the break happens outside the profile, so no data-dir setting can catch it. Routing that callback back to the instance that asked is what my launcher does: https://deckspace.dev/claude-accounts/ — it ships its source, so you can read it before running it.

Native profiles in the app are still the right answer. +1.

Mobile shipped this on September 13 (see #36151). There is now an "Add account" button with switching between up to three accounts, each keeping its own history. Requesting the same on desktop.

My case is the common one in this thread: a personal Max plan and a separate organization Team account. Today that means the desktop app is signed into one while a browser PWA handles the other, which splits Cowork, Claude Code and remote control across two surfaces that share no history or settings. The mobile client now proves the multi-account model exists on the backend, so desktop parity looks like mostly a client-side lift.

Any word on whether this is queued would be appreciated.

I hit this daily, so I built a workaround and open-sourced it: [Lanes](https://lanes.synthetixis.com), a macOS menu-bar launcher that opens Claude Desktop with a separate profile per account. Work and personal run side by side, no signing out. This removes the compromise you described. Both accounts are the real desktop app now, not one in a browser. What it isn't: the in-app switcher this issue asks for. No Cmd+Shift+], no single window with a dropdown, it launches separate instances. Parallel windows work better for me, but this doesn't replace the feature request. How it works: each profile gets its own --user-data-dir. Electron's single-instance lock lives inside that directory, so separate dirs give you genuinely independent parallel sessions — separate login, history, and settings each. It never touches your auth tokens. No credential copying, no session-file swapping. It only decides which directory each instance writes to. No network calls, no telemetry, no auto-updater. https://lanes.synthetixis.com https://github.com/synthetixis/lanes (MIT) * macOS 13+, Apple silicon. Not notarized, so first launch needs "Open Anyway", documented on the page. Unofficial, not affiliated with Anthropic. Happy to answer questions on the approach. Still want to see this land natively.

Quick update to my earlier comment, since a few people here are on macOS 27 now.

Lanes v0.1.1 fixes a macOS 27 bug where clicking the menu-bar icon showed only a "Quit" menu instead of your lanes (macOS 27 shows a status item's attached menu on every click, which swallowed the click). It also properly seals the code signature, so on 27 you get the normal one-time Open Anyway prompt instead of a "damaged" warning. Existing profiles carry over untouched. https://github.com/synthetixis/lanes/releases/tag/v0.1.1

Still macOS only, still separate instances rather than the in-app switcher this issue asks for. With mobile shipping account switching this week, hopefully desktop follows and this becomes unnecessary.

Adding a data point I haven't seen made explicitly in this thread, because I think it changes how this request should be weighed.

The standard answer to "I have two Claude accounts" is: put one in the desktop app and the other in a browser tab. I've been running exactly that setup for months. It works only as long as the two clients are interchangeable — and they are not.

The desktop app is a privileged client. It is the only one that can read and write files on my machine, and the only one that can run local MCP servers (WhatsApp, in my case). The browser can do neither.

So "which account goes in the desktop app" is not a convenience preference. It is a decision about which account gets hands. Everything I actually use Claude for — working on documents on disk, local automation, local MCP — is available to exactly one of my two accounts at any given moment, and switching means a full sign-out and sign-in. Running tasks stop when I do it.

The same is true on mobile, which is why #36151 is really the same bug rather than a separate one. The phone app is also a privileged client — camera, voice, the share sheet, notifications — and the mobile browser is not a substitute for any of it. On a phone you can't even fall back on a second browser profile. The account that isn't signed in on the phone app is simply unreachable when I'm away from my desk.

My situation is the common one: a personal account and a seat on my employer's Team plan, on different email addresses. The same-email account switcher is no help — my personal account is not on my employer's domain and cannot be, and account emails can't be changed.

I would happily take the crudest possible fix on desktop: let me install and run two separate instances of Claude Desktop, each with its own profile directory. No in-app switcher, no shared state, no unified anything. Two icons in the dock.

Worth noting that this already works unofficially: launching the Electron app with a separate --user-data-dir yields a fully independent instance, with its own login and its own claude_desktop_config.json, running side by side with the first. The fact that it works at all suggests that supporting it officially is a small step — and even without an in-app switcher, it would be a real improvement over the current situation.

I think this is closely related to #57998

Many of us are running into the same problem with the Claude desktop app on Windows. Claude Code already has an environment variable for it: CLAUDE_CONFIG_DIR relocates the whole config tree, credentials included, so two accounts can coexist cleanly in the CLI. There is no equivalent for the desktop app.

What I don't understand is why there isn't an advanced setup option instead: let us choose where the program is installed, and where its data lives. That single choice would cover both problems, moving data off a full system drive and keeping separate profiles per account.

Wanting to separate a work account from a personal one, and therefore separate the data, is a common need. It's surprising this hasn't been prioritised.

+1 on this. I run multiple Claude accounts (personal + work-related) and regularly want to use Cowork on more than one at a time without losing context. Right now switching accounts in the desktop app means logging out/in and losing session history entirely — that's the bigger issue for me even more than the switching friction itself. Native multi-account support (even just isolated profiles like Chrome or Slack) would make it much more practical to use Cowork across separate work streams.

Worth being precise about what the local workarounds in this thread cover, since Cowork is a different case. The Code tab keeps its session list on disk per account, which is why claude-transplant and the bridge can move or merge it. Cowork keeps no session records locally, only scheduled tasks and agent memory, so its history is server-side per account, like plain claude.ai chat. Nothing local can carry it across a switch. For Cowork, native profiles are the only fix. +1.

+1 My current workaround is a script to find the latest version of Claude in "C:\Program Files\WindowsApps", then start it with a separate user data folder.

Start-ClaudeWork.bat
"
@echo off
rem Starts the newest installed Claude desktop app with a separate profile (work account).
setlocal

set "USERDATA=%APPDATA%\Claude-Work"
set "EXE="

rem Batch can't sort version numbers correctly (2.10000 < 2.9939 as text), so PowerShell picks the newest.
rem WindowsApps is often not listable for normal users; fall back to the package registry.
for /f "usebackq delims=" %%P in (powershell -NoProfile -Command ^
"$p = Get-ChildItem 'C:\Program Files\WindowsApps' -Directory -Filter 'Claude_*' -ErrorAction SilentlyContinue;" ^
"if (-not $p) { $p = Get-AppxPackage -Name Claude | ForEach-Object { Get-Item $_.InstallLocation } };" ^
"$p | Where-Object { $_.Name -match '^Claude_(\d+(\.\d+)+)_' -and (Test-Path (Join-Path $_.FullName 'app\claude.exe')) } |" ^
"Sort-Object { [version]($_.Name -replace '^Claude_(\d+(\.\d+)+)_.*$','$1') } -Descending |" ^
"Select-Object -First 1 | ForEach-Object { Join-Path $_.FullName 'app\claude.exe' }") do set "EXE=%%P"

if not defined EXE (
echo No Claude installation found in C:\Program Files\WindowsApps
pause
exit /b 1
)

echo Starting "%EXE%"
start "" "%EXE%" --user-data-dir="%USERDATA%"
"

Native multi-account support should also allow multiple account profiles to remain open concurrently, rather than only switching the active identity. For example, Personal, Work, and Research accounts should each be able to have independent Claude Desktop windows running simultaneously, with isolated authentication, local data, MCP configuration, Cowork/Code sessions, and settings. Third-party tools such as Parall and the --user-data-dir solutions already demonstrate that this is technically useful and workable on macOS. Profile switching alone would still force users to interrupt active work in another account.

Native multi-account support should also allow multiple account profiles to remain open concurrently, rather than only switching the active identity. For example, Personal, Work, and Research accounts should each be able to have independent Claude Desktop windows running simultaneously, with isolated authentication, local data, MCP configuration, Cowork/Code sessions, and settings. Third-party tools such as Parall and the --user-data-dir solutions already demonstrate that this is technically useful and workable on macOS. Profile switching alone would still force users to interrupt active work in another account.

Exactly that.. All those features are needed to make it work properly. Proper, deterministic isolation but allow to run concurrently. At the moment it is so much hassle to work with Claude

+1, with a concrete failure report (macOS, Claude desktop 2.19675.0)

I use a personal Pro account (gmail) and a company Team account (different email), so the same-email switcher doesn't apply to me.

The common workaround, launching a second instance with --user-data-dir, is not reliable. I've had to repair it twice (Sept and Oct 2026). Each time the personal profile ended up signed in as the work account. Root causes I found:

• Both instances share the bundle ID com.anthropic.claudefordesktop, so they share one Dock tile and one claude:// sign-in callback. A sign-in can land in the wrong instance.
• The app takes no single-instance lock per profile, so a second click starts another instance on the same profile folder.
• Relocating the profile disables local device pairing.
• Claude Code's ~/.claude is shared unless CLAUDE_CONFIG_DIR is also set, and the app strips that variable from settings files.

The app bundle appears to contain native multi-account code already, gated behind a feature flag and an authentication.disableMultiAccount admin policy. Shipping it would solve this.

Ask: an in-app account switcher for accounts with different emails, with separate chats, projects, Claude Code sessions and connectors per account. Ideally both accounts stay signed in.

+1, but I'd like to push this beyond switching: concurrent accounts.

Switching still forces me to choose between work and personal. What I actually need:

• Be signed in to multiple accounts (e.g. personal Max + work Team) at the same time
• Run chats and Code sessions on both accounts simultaneously, in separate windows or tabs
• Each account keeps its own history, settings, MCP servers and Code sessions, fully isolated
• A clear visual indicator (name/color) of which account a window belongs to

Think Chrome profiles: several windows open at once, each tied to its own profile. Not Slack-style switching, where only one workspace is active at a time.

Today I have to run one account in Desktop and the other in a browser profile, which defeats the point of the desktop app.

+1 from an organizational admin use case.

I'm the administrative secretary of a non-profit and use a Claude Team account for its admin work (several legal entities, Microsoft 365 workflows, internal docs). I also need a separate account on a different email, kept apart from the organization's data, for my second job as a web developer, where I rely heavily on Claude Code and Cowork too.

The browser workaround falls short: Cowork with local folders, connectors, scheduled tasks and Code sessions only work in the desktop app, so one of my accounts always loses them. For an organization, account separation is a governance requirement, and constant sign-out/sign-in makes mistakes more likely.

Ideally: multiple accounts signed in at once, fully isolated (chats, memory, connectors, Cowork, Code sessions), with a clear indicator of the active account. Official support for separate profile directories would already be a big step.

+1 and this is unnecessary noise to prevent the bot from closing this issue "due to inactivity."

Workarounds mentioned in this thread:

• MacOS: https://lanes.synthetixis.com/
• Clade Code only: https://github.com/synth1s/cloak

https://github.com/anthropics/claude-code/issues/36151 remains as parallel issue for mobile.

+1 from someone who uses Claude Desktop and Claude Code everyday.

Microsoft, Google, Slack, Github and many others provide a simple way to change the accounts within the same app/product. I'm sure Anthropic can do the same.

Many people work for multiple companies and it makes sense to have a separate Claude account for each so the work stays within that company's account.

At the moment if we have someone who works for multiple companies they often just do the work in their own personal account, which means Anthropic misses out on another user licence every month.

If users were able to easily add accounts to Claude Desktop, Claude Code (including VSC plugin) and switch between them this would enable us to buy and invite users to our company's Claude team/enterprise plan and the work would stay within that account.

So Anthropic this is a simple way to get more user accounts per month and make more money.

Thanks for listening :)

Chris

Until this lands in the app, I built a small open-source workaround: multi-claude.

It runs the official Claude Desktop with a separate data folder per profile, so each one keeps its own sign-in (e.g. work + personal), side by side. Each profile gets a recolored Claude icon and, on Windows, its own taskbar button. No modified app, no admin rights, plain scripts.

irm https://github.com/thomasog/multi-claude/releases/latest/download/install.ps1 | iex

Windows is the main target; macOS is beta and Linux experimental. Known limits (identical tray icons, notifications) are in the README.