如何在 Mac、Windows 和 VS Code 中同時使用兩個 Claude Code 帳戶

Disclosure: I make Claude Sessions Pro, a paid Mac and Windows app for running several Claude accounts at once. Everything below works without it. The app gets one section near the end, clearly marked.

You have a work Claude account and a personal one. Maybe one per client. Claude Code signs in to one of them, and switching means /logout, /login, a browser tab, and losing your place. An hour later you do it again in the other direction.

You don't need to. Claude Code keeps everything about an account (the login, settings, history, MCP servers) in one folder, and you can point it at a different folder whenever you start it. Two folders, two accounts, both open at the same time in two terminals.

This guide covers the setup on macOS, Linux and Windows (PowerShell, cmd and Windows Terminal), how to run both side by side, how to let each project folder pick its own account, VS Code, CI, and the handful of things that quietly put both terminals on the same login. I checked the core of it (the alias, the PowerShell functions, the Windows Terminal profile, the tmux split, auth status and where MCP servers end up) on macOS and Windows 11.

TL;DR

How Claude Code decides which account you're on

When Claude Code starts, it looks at one environment variable, CLAUDE_CONFIG_DIR. If it isn't set, it uses ~/.claude. That folder is the account, for practical purposes:

• The login. On macOS the token goes in the Keychain, in an entry tied to the config folder, so a second folder gets its own entry. On Linux and Windows it's a .credentials.json file inside the folder.
• Settings, including the status line, permissions and model, in settings.json.
• User-scope MCP servers. For the default folder these live in ~/.claude.json, which sits next to ~/.claude, not inside it. When CLAUDE_CONFIG_DIR is set, Claude Code writes them to .claude.json inside that folder instead. Easy to miss, and it matters later.
• Your personal instructions, skills and agents: CLAUDE.md, skills/, agents/, commands/.
• Session history under projects/, which is what --resume and --continue read.

So "a second account" is just "a second folder". Nothing is copied or patched, and your default setup isn't touched.

Step 1 on macOS and Linux: a folder and an alias

Pick a name. I'll use ~/.claude-work throughout; one folder per extra account works the same way (~/.claude-clientA, ~/.claude-personal).

Add this to ~/.zshrc (or ~/.bashrc):

# Default account: plain `claude`, ~/.claude
# Work account: `claude-work`, ~/.claude-work
alias claude-work='CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'

Open a new terminal and run it:

claude-work

Claude Code doesn't find a login in the new folder, so it walks you through first-run setup and opens the browser. Sign in with the other account. That's the only time you'll do it. From now on claude is one account and claude-work is the other, and you can have both running at once.

Check that it worked:

claude auth status
claude-work auth status

Each prints a small JSON block. Look at email and configDirectory: the first should show your default account and ~/.claude, the second your work account and ~/.claude-work. (auth status needs a recent Claude Code; run claude update if it isn't recognised.)

Don't point the variable at the default folder

It's tempting to make things symmetrical with a second alias, claude-personal='CLAUDE_CONFIG_DIR=~/.claude claude'. Don't. On macOS, setting the variable at all, even to the default path, makes Claude Code look for a different Keychain entry, so your personal account suddenly appears signed out. It's tracked as issue #92252. Leave your main account on plain claude with the variable unset, and give every extra account its own new folder.

Step 1 on Windows: PowerShell, cmd and Windows Terminal

The idea is the same, but PowerShell has no VAR=value command shorthand. If you just run $env:CLAUDE_CONFIG_DIR = ... and then claude, the variable stays set for every later command in that window, and the next plain claude is your work account too.

This function sets the variable for one call and puts it back afterwards, even if Claude Code exits with an error:

function claude-work {
  $prev = $env:CLAUDE_CONFIG_DIR
  $env:CLAUDE_CONFIG_DIR = Join-Path $HOME '.claude-work'
  try { claude @args } finally { $env:CLAUDE_CONFIG_DIR = $prev }
}

Put it in your profile so it's always there. notepad $PROFILE opens the file (create it if Notepad asks). Open a new PowerShell window, run claude-work, sign in with the second account, and check both with claude auth status and claude-work auth status as above. @args passes everything through, so claude-work --resume and claude-work mcp list work as you'd expect.

cmd.exe: quote the whole assignment, or cmd keeps the space before && as part of the folder name:

set "CLAUDE_CONFIG_DIR=%USERPROFILE%\.claude-work" && claude

This one does stay set for the rest of that cmd window, so use a dedicated window for it.

Windows Terminal profile. If you'd rather have a "Claude (work)" entry in the new-tab menu, open Settings, then Open JSON file, and add a profile to profiles.list:

{
  "name": "Claude (work)",
  "commandline": "powershell.exe -NoExit -Command \"$env:CLAUDE_CONFIG_DIR = Join-Path $HOME '.claude-work'; claude\"",
  "startingDirectory": "%USERPROFILE%",
  "tabTitle": "WORK"
}

The variable only exists inside that tab, so every other tab is untouched. -NoExit keeps the window open when you quit Claude Code, so you can start it again with the same account by typing claude.

Step 2: both accounts on screen at once

Once the folders exist, "side by side" is just two terminals.

tmux (macOS and Linux). One command, two panes, one account each:

tmux new-session -s claude 'claude' \; split-window -h 'CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude'

Left pane: default account. Right pane: work. Each pane closes when you quit Claude Code in it.

iTerm2. Settings, Profiles, duplicate your profile and name it "Claude work". Under General, set Send text at start to export CLAUDE_CONFIG_DIR="$HOME/.claude-work", and put WORK in Badge, which draws a large faint label behind the text. Now split a pane with that profile (right-click a pane, Split Pane with Profile).

macOS Terminal. Settings, Profiles, duplicate a profile and name it "Claude work". On the Shell tab, tick Run command and Run inside shell, and enter CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude. A new window with that profile opens straight into Claude Code on the work account. Give the profile a different background colour while you're there.

Windows Terminal. Hold Alt and click "Claude (work)" in the new-tab dropdown: it opens as a split pane next to the current one instead of a new tab. Alt+Shift+- and Alt+Shift+Plus split the current pane if you'd rather start from a plain shell.

Step 3: let the project folder pick the account

The alias works, but you still have to remember which one to type. If your work repos all live under one folder, let the folder decide.

direnv (macOS, Linux, WSL). Install it (direnv.net), hook it into your shell, then in the root of your work folder:

# ~/work/.envrc
export CLAUDE_CONFIG_DIR="$HOME/.claude-work"

Run direnv allow once. Now cd ~/work/anything sets the variable and leaving unsets it, so plain claude uses the right account in every repo below that folder. Add .envrc to your global gitignore if your repos are shared.

No direnv? A shell function does the same check every time you start Claude Code:

# ~/.zshrc or ~/.bashrc
claude() {
  case "$PWD/" in
    "$HOME/work/"*) CLAUDE_CONFIG_DIR="$HOME/.claude-work" command claude "$@" ;;
    *)              command claude "$@" ;;
  esac
}

command claude calls the real binary rather than the function again. Add one line per client folder if you have more than two accounts.

PowerShell can do the same inside the function from earlier:

function claude {
  $prev = $env:CLAUDE_CONFIG_DIR
  if ($PWD.Path -like (Join-Path $HOME 'work\*')) {
    $env:CLAUDE_CONFIG_DIR = Join-Path $HOME '.claude-work'
  }
  try { claude.exe @args } finally { $env:CLAUDE_CONFIG_DIR = $prev }
}

If claude.exe isn't found, check what Get-Command claude -All lists and call that name instead (npm installs a claude.cmd, so it's claude.cmd @args in that case).

VS Code and other editors

The Claude Code extension has a setting for environment variables, claudeCode.environmentVariables, and it would be the obvious place for CLAUDE_CONFIG_DIR. The catch: it's a machine-scoped setting. VS Code ignores it in a workspace's .vscode/settings.json, so you can't give one project the work account and another the personal one this way. Set it in your user settings and it applies to every window. If you do set it there, use an absolute path; ~ isn't expanded.

What does work per project is the integrated terminal. In the work project's .vscode/settings.json:

{
  "terminal.integrated.env.osx": { "CLAUDE_CONFIG_DIR": "/Users/you/.claude-work" },
  "terminal.integrated.env.linux": { "CLAUDE_CONFIG_DIR": "/home/you/.claude-work" },
  "terminal.integrated.env.windows": { "CLAUDE_CONFIG_DIR": "C:\\Users\\you\\.claude-work" }
}

New terminals in that window get the variable, and claude run there uses the work account. VS Code asks you to trust the workspace before it applies terminal environment settings. Cursor and Windsurf read the same keys. JetBrains IDEs have the same idea under Settings, Tools, Terminal, Environment variables.

Make the two accounts impossible to mix up

Two identical terminals with different accounts is a recipe for running the client job on your personal plan. Give the work folder a status line that says so. Create ~/.claude-work/statusline.sh:

#!/bin/sh
# Claude Code pipes session info as JSON on stdin; we only need a label.
cat > /dev/null
printf '\033[44;97m WORK \033[0m %s' "$(basename "$PWD")"

Make it executable (chmod +x ~/.claude-work/statusline.sh) and point the work folder's ~/.claude-work/settings.json at it:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude-work/statusline.sh"
  }
}

The default account keeps its own settings.json, so only the work sessions show the blue WORK tag. Combined with a coloured terminal profile or an iTerm2 badge, you can tell them apart from across the room. And when in doubt, /status inside a session shows the account it's signed in to.

What to share between accounts, and what never to share

A new folder starts empty: no CLAUDE.md, no skills, no agents. You probably want those to be the same everywhere. Symlink them:

ln -s ~/.claude/CLAUDE.md ~/.claude-work/CLAUDE.md
ln -s ~/.claude/skills    ~/.claude-work/skills
ln -s ~/.claude/agents    ~/.claude-work/agents
ln -s ~/.claude/commands  ~/.claude-work/commands

(On Windows, New-Item -ItemType SymbolicLink does the same, but needs Developer Mode or an admin prompt. Copying the files is fine too.)

Never share or symlink .credentials.json, .claude.json or the whole folder. Those hold the login and per-account state. Sharing them is how you end up with one account in both terminals, or each terminal signing the other one out.

MCP servers don't come along. User-scope servers live in the account's own .claude.json (see the diagram), so the work account starts with none. Add them again through the work alias:

claude-work mcp add --scope user --transport http notion https://mcp.notion.com/mcp
claude-work mcp list

Project-scope servers (a .mcp.json checked into the repo) are read from the repo, so they work for both accounts without doing anything.

Settings can be shared by symlinking settings.json, but most people want the work one to differ, at least for the status line above.

The gotchas that put both terminals on the same account

If both auth status calls show the same email, one of these is almost always why.

1. An API key in your shell profile. If ANTHROPIC_API_KEY is exported in ~/.zshrc or your Windows user environment, and you've approved it in Claude Code, it's used ahead of the subscription login in every folder. Both "accounts" are then billing the same API key. Unset it, or only set it in the one place you need it.
2. A long-lived token in the environment. claude setup-token prints an OAuth token for CI. If you export it as CLAUDE_CODE_OAUTH_TOKEN globally, it also wins over /login in every folder. Same fix.
3. The variable set to the default path. The macOS Keychain issue from Step 1.
4. Settings files can't set it. CLAUDE_CONFIG_DIR in a project's .claude/settings.json or settings.local.json is ignored, because Claude Code has already chosen the folder by the time it reads them. It has to come from the environment: the alias, direnv, the terminal profile.
5. Your company may force one organisation. Managed settings on a work laptop can include forceLoginOrgUUID, which only allows sign-ins to the company's organisation, in any folder. If your personal login is refused on the work machine, that's policy, not a bug. Ask IT rather than working around it.
6. /logout only signs out the folder you're in. That's the point, but it surprises people who expect it to sign out "Claude".

Running both accounts in CI

Same idea in a pipeline: one token per account. On your machine, run setup-token with each account's folder:

claude setup-token          # default account
claude-work setup-token     # work account

Store each token as a separate secret (CLAUDE_CODE_OAUTH_TOKEN_PERSONAL, CLAUDE_CODE_OAUTH_TOKEN_WORK) and map the right one to CLAUDE_CODE_OAUTH_TOKEN in each job. The runner never needs a config folder or a browser login.

What about Claude Desktop?

None of this applies to the Claude Desktop app. It ignores CLAUDE_CONFIG_DIR and signs in to one account at a time, including in its Code tab. To use two accounts there, you're back to signing out and in, or running a second copy of the app with its own profile, which is fiddly to set up by hand. That's the gap the next section is about.

The no-setup way: Claude Sessions Pro

This is the product section mentioned at the top.

I built Claude Sessions Pro because I wanted my accounts side by side in the desktop app as well as the terminal, without maintaining aliases and profiles on two operating systems.

• One app per account on Mac, one window per account on Windows. Each is a full Claude Desktop session with its own login, chats and Code tab, open at the same time.
• Claude Code in the terminal, per profile. Each profile has Open in Terminal, which starts claude with that profile's own config folder, and Copy Export Command if you'd rather paste the line into your own shell or script. It's the same CLAUDE_CONFIG_DIR approach from this post, just managed for you.

• A usage meter for every account in the menu bar (Mac) or system tray (Windows), with an alert at 80% and 95% so a long session doesn't hit the limit by surprise.

It's for accounts you already have, not a way to get more usage: each account keeps its own limits, and Anthropic's terms apply to each one. It runs on macOS 14 or later and Windows 10 and 11, costs $15 once for two computers, and has a free one-hour preview and a 14-day refund. It's an independent app, not made by or affiliated with Anthropic.

Try Claude Sessions Pro free for an hour →

Troubleshooting

FAQ

Is running two accounts like this allowed?
You're signing in to two accounts you already have, one per folder, instead of signing out and back in. Each account is still bound by Anthropic's terms and its own plan limits. Don't use extra accounts to get around a limit.

Do the usage limits combine?
No. Each account has its own limits and its own usage, exactly as if you'd switched with /logout.

Can I run three or more?
Yes. One folder and one alias (or one direnv folder) per account.

Does it work in WSL?
Yes, the Linux instructions apply inside WSL. Note that WSL and Windows keep separate folders, so an account signed in on the Windows side isn't signed in inside WSL, and vice versa.

Will a Claude Code update break it?
CLAUDE_CONFIG_DIR is a documented setting, so it's been stable across updates. If something changes, claude auth status is the quickest way to see which folder a session is really using.

Can I move my existing history to the new account?
Session history is per folder. You can copy a project's folder from ~/.claude/projects/ to ~/.claude-work/projects/ to make it resumable there. Only do it when the conversation belongs with that account, for example work code moving to the work account.

Wrapping up

The whole trick is one environment variable: a folder per account, and a way to start Claude Code with the right one. An alias on macOS and Linux, a small function on Windows, direnv if you want it automatic, a status line so you never guess. The rest of this post is the edge cases that bite after the first day.

If you'd rather have it done for you, in the terminal and in Claude Desktop, Claude Sessions Pro is $15 once, with a free hour to try it. There are longer write-ups on running two Claude Code accounts in the terminal and switching Claude Code accounts on the site.

If you've hit a gotcha that isn't here, tell me in the comments and I'll add it.