How to Run Two Claude Desktop Accounts on One Mac (Work + Personal)

My work Claude account and my personal Claude account use different email addresses. Claude Desktop holds exactly one login at a time, and there is no account switcher in the app. For a while I was signing out and back in several times a day, which is exactly as tedious as it sounds.

There is a better way, and it doesn’t require buying anything. This guide sets up a second, fully isolated Claude instance on macOS — separate login, separate chats, separate MCP servers — while leaving your work account exactly where it is.

Tested on: macOS, Claude Desktop (Electron), and the Claude Code CLI.

Table of contents

First, check whether you even need this

If your work organization invited the same email address as your personal account, stop here. Claude has a native account switcher built in:

• Click your initials or name in the lower-left corner
• A blue checkmark marks the active account
• Click the other one to switch

The catch is at invite time. When you accept the org invite, choose “Keep both accounts.” The other option migrates your personal content into the company workspace, and it’s one-way — it cannot be moved back.

This native switcher only works for one login that spans a personal account and a Team or Enterprise org. Two different email addresses means two separate logins, and the desktop app holds one at a time. That’s the case the rest of this guide solves.

Why Claude Desktop has no account switcher (and how to work around it)

Claude Desktop is an Electron app, which means it accepts the Chromium --user-data-dir flag. That directory holds everything account-specific:

• Session cookies and login state
• Chat and project cache
• claude_desktop_config.json, which defines your MCP servers

Point a second launch at a different directory and you get a completely separate instance. Your work account keeps the default ~/Library/Application Support/Claude/ and is never touched.

One distinction that trips people up: ~/.claude is Claude Code’s config directory, not the desktop app’s. A lot of guides conflate the two. They are separate problems with separate solutions, and both are covered below.

Set up a second Claude Desktop account on macOS

Step 1 — Quit Claude completely

Cmd+Q, and confirm it’s gone from the Dock. Closing the window is not enough. If you’re unsure, check Activity Monitor for stray Claude processes.

Step 2 — Create the personal profile

open -n -a /Applications/Claude.app --args \
  --user-data-dir="$HOME/Library/Application Support/Claude-Personal"

A fresh login screen appears. Sign in with your personal email.

The window will be completely empty. That is expected — a new profile has no history because nothing has happened in it yet. It is not data loss.

If this opens straight into your work account instead of a login screen, the app didn’t fully quit. Go back to Step 1.

Step 3 — Verify the isolation before going further

Quit, then launch Claude normally from the Dock. Confirm your work chats, projects, and MCP servers are all still there. If they are, the split worked. Quit both before continuing.

Step 4 — Build a launcher so you never touch the terminal again

Open Script Editor (Spotlight → “Script Editor”). New document, and paste:

set personalDir to (POSIX path of (path to home folder)) & "Library/Application Support/Claude-Personal"
do shell script "open -n -a /Applications/Claude.app --args --user-data-dir=" & quoted form of personalDir

Here’s what each piece is doing, because every part of that line is load-bearing:

Without quoted form of, the shell reads --user-data-dir=/Users/you/Library/Application and treats Support/Claude-Personal as a separate argument. Claude then silently falls back to the default profile and you see your work account — with no error to tell you why.

path to home folder is used instead of $HOME because do shell script runs with a stripped-down environment.

The final string the shell actually receives:

open -n -a /Applications/Claude.app --args --user-data-dir='/Users/you/Library/Application Support/Claude-Personal'

Step 5 — Export it as an application

File → Export, then:

• File Format: change from Script to Application ← this is the key setting
• Show startup screen: unchecked (otherwise a dialog appears before Claude launches)
• Stay open after run handler: unchecked (the script should end immediately)
• Run-only: unchecked (it strips the source for no real benefit)
• Code Sign: Don't Code Sign is fine for local use

Name it Claude Personal and save it to /Applications.

The startup-screen and stay-open checkboxes stay greyed out until you switch File Format to Application. That’s the giveaway if you missed it.

Step 6 — Give it a distinct icon

Both instances are otherwise identical in the Dock and in Cmd-Tab. Do this before you start using it for real, or you will eventually type something into the wrong account.

1. Open an image in Preview → Cmd+A → Cmd+C. Copying the file in Finder doesn’t work — that copies a file reference, not image data.
2. Select Claude Personal.app → Cmd+I
3. Click the tiny icon in the top-left corner of the Info window, next to the filename — not the large preview below it. It should highlight.
4. Cmd+V. An admin password may be required for /Applications.

If that doesn’t stick, replace the icon file directly. This is more reliable for AppleScript apps:

1. Convert your image to .icns (Image2icon, or sips plus iconutil)
2. Right-click the app → Show Package Contents → Contents/Resources/
3. Replace applet.icns, keeping that exact filename
4. Run touch /Applications/Claude\ Personal.app to bust the icon cache

If the Dock still shows the old icon, drag the app out and back in, or killall Dock.

Renaming alone is enough in a pinch — the Dock tooltip and Cmd-Tab both show the name. The icon is just faster to read at a glance.

Step 7 — Test it and pin it

Double-click Claude Personal.app. It should open already logged into your personal account. Right-click its Dock icon → Options → Keep in Dock.

The result: Claude.app is work, Claude Personal.app is personal, and both can be open at the same time.

MCP servers don’t carry over — and that’s the point

The new instance reads claude_desktop_config.json from Claude-Personal/, so it starts with zero MCP servers configured. This is a feature, not a bug. It’s a real credential boundary between the two accounts.

If your work profile has infrastructure credentials wired in — AWS, Sentry, Linear, Supabase — leave the personal side empty, or add only what it genuinely needs.

# edit the personal config (create the file if it doesn't exist)
open -e ~/Library/Application\ Support/Claude-Personal/claude_desktop_config.json

You can copy the whole config over, but understand that it defeats the isolation you just built:

# copy it, then prune what the personal account shouldn't reach
cp ~/Library/Application\ Support/Claude/claude_desktop_config.json \
   ~/Library/Application\ Support/Claude-Personal/

# or share one file via symlink (not recommended across accounts)
ln -s ~/Library/Application\ Support/Claude/claude_desktop_config.json \
      ~/Library/Application\ Support/Claude-Personal/claude_desktop_config.json

Multiple Claude Code accounts: a different mechanism

The Claude Code CLI doesn’t use --user-data-dir. It uses the CLAUDE_CONFIG_DIR environment variable, which relocates auth, CLAUDE.md, skills, agents, and session history together.

The default stays ~/.claude for work. Add a personal directory alongside it:

# optional backup of the existing (work) config
cp -r ~/.claude ~/.claude-backup

# authenticate the personal account into its own directory
CLAUDE_CONFIG_DIR=~/.claude-personal claude /login

# alias it so you don't retype the variable
echo 'alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude"' >> ~/.zshrc
source ~/.zshrc

Now both accounts stay logged in simultaneously, in parallel terminals:

claude              # work (default ~/.claude)
claude-personal     # personal (~/.claude-personal)

How to check which Claude account you’re signed into

Run /status inside a session, or claude /status from outside. It shows the login method, organization, email, and config directory.

Run both to confirm the split actually took:

claude /status            # should show work
claude-personal /status   # should show personal

Two things /status may flag on a fresh config directory

6 need auth under MCP servers is expected. Server definitions may have carried over, but OAuth tokens are stored per config directory. Run /mcp and re-authorize only what that account should be able to reach.

Running native installation but config install method is 'not set' is cosmetic. The directory was created fresh rather than migrated, so installMethod was never recorded. It may affect auto-update detection on that profile. To clear it:

CLAUDE_CONFIG_DIR=~/.claude-personal claude config set installMethod native

Claude Code inside the desktop app

This one is worth verifying rather than assuming. It should follow the instance’s data directory, but it may shell out to ~/.claude like the CLI does — in which case both desktop instances share the work account there.

Open Claude Personal.app → Code tab → /status. If it reports the work account, the isolation doesn’t extend there. Use the terminal with claude-personal for personal work and treat the desktop Code tab as work-only.

What is actually isolated, and what isn’t

Separated:

• Chats, projects, and login state. Different directories, no crossover. Signing out of one doesn’t touch the other.
• MCP servers. Each instance reads its own config file.
• Claude Code CLI. Separate auth, memory, CLAUDE.md, and session history.
• Billing and usage limits. Two accounts, counted independently.

Not separated:

• The app bundle. One Claude.app, one auto-updater. Not a privacy issue, but a bad release breaks both instances at once.
• Anything outside the data directory. A Filesystem MCP server pointed at ~/ from either side can read the other profile’s files on disk. The isolation is config-level, not an enforced sandbox. Scope filesystem access per instance.

So: separate in every way that matters for keeping the two accounts from mixing. It is not a security sandbox, if that was the bar you had in mind.

What happens when Claude updates

Both instances run the same /Applications/Claude.app. The updater replaces that bundle, and the launcher points at the path rather than a copy — so the next launch of Claude Personal is simply the new version. Nothing to redo.

Profile directories live outside the bundle, so logins, chats, and MCP config all survive an update untouched.

Two practical notes:

• Quit both before updating. Electron updaters swap the bundle on relaunch. One instance mid-update while another runs the old bundle can behave strangely.
• Whichever instance is running does the updating. The other picks up the new version silently on next launch. There’s no separate update to run.

Troubleshooting: common failure modes

The update-breakage case is the real risk here. The check after any noticeable update takes two seconds: open Claude Personal and confirm it’s still personal.

One known limitation: deep links (claude://) route to whichever instance LaunchServices picks. That’s effectively unpredictable and not controllable.

Lighter alternatives

• Browser profiles. Keep work in the desktop app and run personal as a separate Chrome profile with claude.ai installed as a PWA. Zero maintenance, but you lose desktop-only features on the personal side.
• Separate macOS user accounts. Complete isolation, but fast user switching interrupts everything else you’re doing.
• Paid third-party launchers. Several exist. They wrap the same separate-profile trick this guide does manually.

Frequently asked questions

Can you have two Claude accounts on one Mac?

Yes. If both accounts share one email address, use Claude’s built-in account switcher. If they’re different email addresses, launch a second Claude Desktop instance with --user-data-dir pointing at its own profile directory, as described above.

Does Claude Desktop have an account switcher?

Only for a single login that spans a personal account and a Team or Enterprise org — click your initials in the lower-left corner. There is no switcher for two separate logins with different email addresses.

Do I need to install Claude Desktop twice?

No. Both instances run the same /Applications/Claude.app bundle. Only the profile directory differs, which is also why a single update covers both.

Does this work for Claude Code too?

Yes, but through a different mechanism. Claude Code uses the CLAUDE_CONFIG_DIR environment variable instead of --user-data-dir. See the Claude Code section above.

Will an update break the setup?

It can. The flag is a standard Electron one, so it’s unlikely to disappear, but a release that moves auth into the Keychain would break the isolation. Check after major updates — it takes two seconds.

Is running two Claude accounts against the terms of service?

This organizes accounts you already pay for. What’s prohibited is sharing one login between people or evading usage limits, and neither applies here. If your work account is Enterprise, check with whoever owns it first. That’s not a technical problem, just courtesy.

Quick reference

That’s the whole setup. Two Dock icons, two accounts, both signed in, no logout dance. If you’re setting up a new Mac anyway, I’ve also written up the apps I install on every Mac before doing anything else.