How to Use Multiple Claude Code Accounts on One Computer

If you only want the commands, the step-by-step guide to switching Claude Code accounts covers saving, switching and verifying profiles. This page is the why behind it: what you are actually switching, and how to tell whether your setup can keep two accounts apart at all.

Where Claude Code keeps your login

A Claude Code login is a credential payload plus some account metadata. Where the payload lives depends on the platform and the Claude Code version:

• Linux and Windows: a file, ~/.claude/.credentials.json. If~/.claude does not exist but ~/.config/claude does, the file is read from there instead. If CLAUDE_CONFIG_DIR is set, the file is$CLAUDE_CONFIG_DIR/.credentials.json.
• macOS: a generic password in the login Keychain. Claude Code reads the Keychain even when a .credentials.json file is also on disk, so the Keychain item is the one that counts.
• Account metadata: the oauthAccount field in~/.claude.json, which holds the display name and organization Claude Code shows you.

The payload is more than an access token. It also carries the refresh token and any MCP server OAuth tokens (mcpOAuth), so a stale copy loses those too.

Two Keychain schemes on macOS

The Keychain item has changed shape between Claude Code releases, and this one detail decides whether per-account config directories work on a Mac:

• Legacy shared: one item, service name Claude Code-credentials, used no matter what CLAUDE_CONFIG_DIR is. aisw treats Claude Code 2.1.19 and older this way.
• Scoped by config directory: the default ~/.claude still usesClaude Code-credentials, but any other config directory gets its own item,Claude Code-credentials- followed by eight hex characters derived from a SHA-256 hash of the directory path. aisw treats 2.1.121 and newer this way.
• Unknown: versions in between. aisw warns rather than guessing.

Check your version with claude --version before deciding which approach below applies to you.

Logging out and back in

Running /login with the other account is the native way to change accounts, and for occasional use it is fine. It breaks down as soon as switching is routine:

• There is one login slot. Signing in as personal overwrites the work credential, so going back means a full browser sign-in again, every time.
• Nothing records which account a terminal is using. You find out from the account name in Claude Code, or from the bill.
• A Claude Code process that is already running keeps the credential it loaded. Changing the login underneath it does not move that session to the new account.

Fine when: you have one main account and switch a few times a month.

One CLAUDE_CONFIG_DIR per account

The common manual setup is a shell alias per account, each pointing Claude Code at its own config directory:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'
alias claude-personal='CLAUDE_CONFIG_DIR=~/.claude-personal claude'

Each directory gets its own settings, history and extensions. Whether it also gets its own login depends on where the credential lives:

• File-backed installs (Linux, Windows): it works. The credential file follows the config directory, so each alias has its own.credentials.json.
• macOS, scoped Keychain: it works. Each directory maps to its own Keychain item.
• macOS, legacy shared Keychain: it breaks, quietly. Both aliases read and write the single Claude Code-credentials item, so the last account you signed into is the account every alias uses. The separate history makes it look isolated when the login is not.

Even where it works, the aliases only cover Claude Code, nothing tells you which one a repository should use, and a plain claude still opens the default directory.

Fine when: you use only Claude Code, on Linux, Windows or a recent macOS build, and you trust yourself to type the right alias.

Copying credential files around

The other manual route is to keep .credentials.json.work and.credentials.json.personal and copy one over the live file before launching. It fails in three ways:

• macOS ignores it. Claude Code reads the Keychain item first, so a copied file changes nothing while a Keychain credential exists.
• OAuth copies go stale. Claude Code refreshes tokens and writes the new ones back to the live location. Your saved copy still holds the old refresh token, and restoring it later can put an expired login back in place.
• Metadata drifts. The account name comes from oauthAccount in~/.claude.json, which the copy does not touch, so Claude Code can show one account while using another.

Fine when: the credential is an API key on Linux or Windows. A key does not refresh, so a copy stays valid.

What aisw does instead

aisw keeps each account as a profile directory under ~/.aisw/profiles/claude/. Here are two API-key profiles added in a throwaway home, and the files that produced:

$ aisw add claude work-api-key --api-key "$WORK_KEY" --credential-backend file
Added profile
─────────────

  Tool          : Claude Code
  Profile       : work-api-key
  Auth          : api_key
  Backend       : file
  Claude auth   : api_key
  Activation    : stored

$ aisw list claude
Claude Code
  ○ personal-api-key [api-key]
  ○ work-api-key [api-key]

$ find ~/.aisw/profiles -type f
~/.aisw/profiles/claude/personal-api-key/.credentials.json
~/.aisw/profiles/claude/work-api-key/.credentials.json

Each profile directory holds a .credentials.json in the same format Claude Code uses ({"apiKey":"sk-ant-api03-…"} for a key). That is what lets a profile directory double as a CLAUDE_CONFIG_DIR. OAuth profiles also keep theoauthAccount metadata so aisw can restore it with the credential.

Isolated mode

Isolated mode, the default, points Claude Code at the profile directory. This is what the shell hook evaluates when you run aisw use:

$ aisw use claude work-api-key --emit-env
export CLAUDE_CONFIG_DIR='/Users/you/.aisw/profiles/claude/work-api-key'

It is the alias approach with a name attached. Each profile gets its own config, history and extensions, and on a scoped-Keychain Mac, aisw add runs Claude Code's login against the profile directory so the Keychain item belongs to that profile. A child process cannot change its parent shell's environment, so the variable only reaches your shell through the hook that aisw init offers to install, or an explicit eval "$(aisw use claude work --emit-env)".

Where isolation cannot hold, aisw says so instead of pretending. On a legacy shared Keychain install, aisw add warns:

Claude OAuth on this install uses the legacy shared live Keychain credential, so this profile is not a durable isolated account container. Use shared mode for this profile, or prefer an API key or long-lived auth token for repeatable switching.

and an isolated switch is refused before anything is written:

isolated-mode Claude OAuth switching is unsupported for profile 'work'.
  This Claude install uses the legacy shared live Keychain credential, so CLAUDE_CONFIG_DIR isolates config/history but not the live OAuth credential.
  This is an expected upstream limitation, not an aisw corruption bug.
  Use shared mode instead: aisw use claude work --state-mode shared

Shared mode

Shared mode leaves Claude Code in its standard directory and swaps the credential itself:

$ aisw use claude work-api-key --emit-env --state-mode shared
unset CLAUDE_CONFIG_DIR

aisw then writes the profile's credential to whatever Claude Code reads (theClaude Code-credentials Keychain item on macOS, the live.credentials.json elsewhere) and restores oauthAccount in~/.claude.json. On macOS it tells you first that the switch "may trigger a macOS Keychain prompt so aisw can update Claude's active credentials." Settings, history and MCP configuration stay shared between accounts. aisw remembers the mode you last passed, so you only add --state-mode when you change it.

Shared mode is the copy-the-file approach done properly. Before switching away from an OAuth profile, aisw checks whether the live credential still belongs to the same account and, if so, saves the refreshed tokens back into that profile. That is the step a manual copy misses, and the reason restored logins stay signed in. Every write goes through a transaction with a backup, so a failed switch rolls back rather than leaving a half-written login.

Which approach fits your setup

• One account, occasional switch: /login is enough.
• Claude Code only, on Linux, Windows or Claude Code 2.1.121+ on macOS:CLAUDE_CONFIG_DIR aliases work. aisw's isolated mode is the same mechanism with names, aisw status and a repository check.
• macOS with a legacy shared Keychain: config directories will not keep OAuth logins apart. Use aisw's shared mode, or API-key profiles.
• Several tools, or repositories that must never use the wrong account:use profiles plus a context and a workspace binding, covered in preventing the wrong account in a repository. The same model extends to Codex CLI, Gemini CLI and Antigravity CLI.

Switching is not running two accounts at once

Every approach above changes the account for the next Claude Code process. None of them moves a running conversation to another account, and aisw does not bypass provider terms or limits. Claude Code's documented worktree workflow isolates files and session context, but a worktree is not an account boundary. Two concurrent sessions on different accounts need two config directories that each own their credential, which brings you back to the question of which storage scheme your install uses.

If a switch looks like it did not take, the troubleshooting guide for Claude Code account switching walks through the usual causes.