DEV Community

Cover image for Run Two Claude Code Accounts Side by Side Without Logging Out
Gabriel Anhaia
Gabriel Anhaia

Posted on AI-assisted

Run Two Claude Code Accounts Side by Side Without Logging Out

#claudecode #ai #productivity #tutorial

At 6 p.m. you type /logout, then /login with your personal account, because the side project deserves your own Max plan and not the company's seat. At 9 a.m. you open the work repo, type claude, and start a refactor. It runs on your personal plan, burning your own usage limits on your employer's code, and nothing made you look.

Claude Code keeps one login per configuration directory, and by default there is one directory: ~/.claude. Switching accounts with /logout and /login works, but the docs note that logging out also resets your first-launch setup, so the next run walks you through login and setup again (authentication docs).

You don't have to live like that. Anthropic documents a way to stay signed in to a work account and a personal account at the same time, and it takes one environment variable.

Why Claude Code only knows one login

Everything that makes an account yours lives under one directory. The env vars reference describes CLAUDE_CONFIG_DIR as the override for that directory, default ~/.claude: "All settings, session history, and plugins are stored under this path."

Credentials follow the same rule. On Linux and Windows the login sits in .credentials.json inside the config directory. On macOS it goes to the Keychain, and the credential management section says that with CLAUDE_CONFIG_DIR set, Claude Code "keys the macOS Keychain entry to that directory too, so a session with a different CLAUDE_CONFIG_DIR reads a different entry."

Two directories means two independent logins. The same docs page has a section called "Log in with multiple accounts" that recommends exactly this, with an alias as the example.

Two brass keys on separate rings, each hanging from its own small folder, one marked with an orange tag
One config directory per account, each with its own login.

Step 1: a second config directory and an alias

Keep your personal account on the default directory and give the work account a new one. Add this to ~/.zshrc or ~/.bashrc; it is the alias from the authentication docs:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'
Enter fullscreen mode Exit fullscreen mode

Open a new terminal and run claude-work. Claude Code sees an empty directory, so it walks you through login and setup. Sign in with the work account there. Your personal login in ~/.claude is untouched.

Check which account each command uses before you trust it. claude auth status prints JSON, exits 0 when you are logged in, and from v2.1.268 includes a configDirectory field:

claude auth status
claude-work auth status
Enter fullscreen mode Exit fullscreen mode

Look at configDirectory and authMethod in each. Both should say claude.ai, and the directories should differ.

The Keychain trap on macOS. Don't "tidy up" by setting CLAUDE_CONFIG_DIR=~/.claude for the personal account. Issue #92252, open since September 5, 2026, reports that setting the variable to the default path selects a different Keychain entry than leaving it unset, and the login appears lost. Leave the personal account on the unset default and only set the variable for the second account.

Step 2: let the folder pick the account

An alias still relies on you remembering to type it. The fix is to make the folder decide. You can't do this from the repo's .claude/settings.json: the env vars reference says CLAUDE_CONFIG_DIR is ignored in project and local settings. For per-folder routing, it has to come from your shell.

With direnv, put one .envrc in the parent folder that holds your work repos. direnv checks the current directory and its parents before each prompt and unloads the variables when you leave:

# ~/work/.envrc
export CLAUDE_CONFIG_DIR="$HOME/.claude-work"
Enter fullscreen mode Exit fullscreen mode

Hook direnv into your shell once with eval "$(direnv hook zsh)" (or bash) in your rc file (hook docs), then run direnv allow in ~/work. Now plain claude inside any repo under ~/work runs on the work account, and plain claude anywhere else runs on your personal one. If a work repo already has its own .envrc, add source_up at its top so it still loads the parent file (direnv stdlib).

No direnv? A shell function does the same job by path:

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

command claude skips the function and runs the real binary, so it doesn't call itself.

A folder tree on the left with branches routing into two separate terminal windows, one outlined in burnt orange
The folder you start in decides which account runs.

Step 3: the gotchas that follow each account

A new config directory starts with its own settings, history and plugins. Here is what that means once you work in both every day.

The status line. It is set in settings.json under the config directory, so the work account has none until you add one (status line docs). Use it to make the account impossible to miss. The script receives session JSON on stdin, including rate_limits for Pro and Max subscribers after the first response, so you also see whose 5-hour window you are spending:

#!/bin/sh
# ~/.claude-work/statusline.sh
input=$(cat)
model=$(echo "$input" | jq -r '.model.display_name')
five=$(echo "$input" \
  | jq -r '.rate_limits.five_hour.used_percentage // empty')
echo "WORK | $model${five:+ | 5h ${five}%}"
Enter fullscreen mode Exit fullscreen mode 
{
  "statusLine": {
    "type": "command",
    "command": "~/.claude-work/statusline.sh"
  }
}
Enter fullscreen mode Exit fullscreen mode

Add the JSON to ~/.claude-work/settings.json and run chmod +x ~/.claude-work/statusline.sh. For the personal account, copy the script into ~/.claude with a PERSONAL label, then add a statusLine key pointing at that copy to your existing ~/.claude/settings.json rather than replacing the file, which holds your other settings. The script needs jq.

MCP servers and plugins. Your personal MCP servers live in .claude.json, the file that also holds your sign-in session (settings docs), and plugins sit under the config directory. The authentication docs say each directory has its own settings, session history and claude.ai login. In practice, a server added with claude mcp add --scope user on one account doesn't show up on the other. Add it again with claude-work mcp add ... if you want it there. Project-scoped servers in a repo's .mcp.json load for both, because they live in the repo (MCP docs).

claude.ai connectors follow the account. Connectors you added on claude.ai show up in Claude Code when you are signed in with that claude.ai account. On Team and Enterprise plans, only admins can add them (MCP docs). Your work session gets the company's connectors, your personal session gets yours, and neither leaks into the other.

An API key in your shell beats both logins. In the authentication precedence, ANTHROPIC_API_KEY ranks above subscription logins from /login. Interactive sessions ask you once to approve the key and remember the answer, and -p runs use it whenever it is set, without asking. Either way, usage bills to the key instead of your plan. An exported key sits in the environment of every folder you open, so keep it out of your global rc file.

A company laptop may refuse the personal account. Admins can set forceLoginOrgUUID in managed settings, and Claude Code then exits at startup when the claude.ai credential in use belongs to another organization. Managed settings are system-level, outside any config directory, so a second directory doesn't get around them. If you hit this, the policy is doing its job: keep side projects on your own machine.

Limits stay separate. Each login has its own plan and its own usage windows, so running both does not pool your limits.

Here is the whole setup on one screen:

Piece Personal Work
Config directory ~/.claude (unset) ~/.claude-work
How it starts claude claude-work, or claude in ~/work
Status line PERSONAL script WORK script
User MCP servers added once here added again here
Check claude auth status claude-work auth status

Doing it in Hermes IDE

I build Hermes IDE, so weigh this section with that in mind. Hermes runs each agent's own interface in a real terminal, with the agent's own CLI sign-in (for Claude: Pro, Max or an API key), and it never asks for your tokens. It supports several accounts per agent (README).

When you start a task with ⌘N (Ctrl+Shift+N on Windows and Linux), you pick the agent, model, effort and account for that task. Combinations you use often can be saved as presets: one for the work repo on the company account, one for side projects on your Max plan. The New Session wizard also preselects the last agent you used and how you ran it. Each task starts on its own hermes/<name> branch in its own worktree.

When one agent hits its usage limit, you can continue the task in another agent.

What it doesn't change: each account's plan, limits and policies are still Anthropic's, and a managed laptop that blocks your personal organization blocks it in Hermes too. Hermes is free, source-available under BSL 1.1, runs on macOS, Windows and Linux, and is not affiliated with Anthropic or Nous Research. The current release is 2.3.3, from October 13, 2026.

If this was useful

If you juggle accounts because you juggle agents, Hermes IDE puts the account next to the agent, model and effort on every task. It is free, and if it saves you a wrong-plan morning, a star on GitHub helps other developers find it.

Once the right account runs in the right repo without you thinking about it, the hard part of the day goes back to the design work itself. The System Design Pocket Guide: Interviews walks through 15 real system designs step by step, with the trade-offs spelled out, which helps whether you are preparing for an interview loop or arguing a design in review. It is one of the Pocket Guides for Developers, a series of 8 short books on agents, RAG, prompts, observability, events, databases and system design.

System Design Pocket Guide: Interviews — 15 Real System Designs, Step by Step

Top comments (0)