ccslot

Multiple Claude Code accounts on one machine.
Separate logins, shared brain.

$ npx ccslot add work

zero dependencies · macOS, Linux, Windows · Node 22+ · MIT

the problem

One folder, one seat

Claude Code keeps everything in ~/.claude — your login, but also your project history, your skills, your settings, your saved plans.

That's fine until you have two accounts. Then it's one seat two people are fighting over, and switching means /logout → /login → browser → approve → and the session you were mid-way through is gone.

Do that four times a day and you go looking for a better way.

the old way

/logout
/login
… browser opens, pick account, approve …

# twenty minutes later, in reverse

the fix

Separate the auth, share the rest

Claude Code reads CLAUDE_CONFIG_DIR. Point it somewhere else and you get a blank install. ccslot creates that directory, then symlinks the parts worth sharing back to the original — so the second account has its own identity and the same brain.

~/.claude

projects
skills
plans
settings.json

the original

~/.claude-work

projects
skills
plans
settings.json
its own login

a slot

Linked names read and write the originals. Everything else Claude Code writes stays inside the slot.

in practice

Two accounts, both live

~/code

$ npx ccslot add work
  created ~/.claude-work
    shared  projects
    shared  skills
    shared  plans
    shared  settings.json
  alias ccwork added to ~/.zshrc

$ ccslot list
  * work        ccwork      4 shared
    personal    ccpersonal  4 shared

$ ccslot personal --resume
  resuming a conversation started
  under the other account…

Two terminals, two accounts, neither aware of the other's login. The part that still makes me happy is /resume: a conversation started under one account, picked up under a different one, in the same repo.

The history lives in the shared projects/, so it doesn't matter which identity wrote it. Hit your limit mid-task? Switch accounts, resume, keep going.

Adding a third takes about eight seconds.

reference

Commands

ccslot add <name>: create ~/.claude-<name>, link the shared paths, add a shell alias
ccslot list: list slots — * marks the one active in this shell
ccslot view <name>: what a slot shares, and what is its own
ccslot delete <name>: remove the slot dir and its alias — shared targets untouched
ccslot <name> [args…]: launch Claude Code as that slot
ccslot run <name> [args…]: the same, explicit form
ccslot use <name>: switch the current shell (needs eval)
ccslot install: check for Claude Code, and show how to install it

Don't have Claude Code yet?

ccslot manages Claude Code's config dirs — it doesn't ship Claude Code. If claude isn't on your PATH, anything that would launch it stops with instructions instead of an ENOENT, and ccslot install will offer to open the official docs for you.

ccslot install

  Claude Code is not installed (no `claude` on your PATH).
  ccslot only manages its config dirs — it needs the CLI itself.

  install Claude Code   curl -fsSL https://claude.ai/install.sh | bash
  or with npm           npm install -g @anthropic-ai/claude-code
  then log in           claude

  docs   https://code.claude.com/docs/en/overview

On Windows the first line is irm https://claude.ai/install.ps1 | iex.

Three ways to run as a slot

pick one

$ ccslot work --resume        # launch directly, args pass through
$ ccwork --resume             # the alias ccslot wrote for you
$ eval "$(ccslot use work)"   # switch this whole shell

use needs the eval because a child process cannot change its parent shell's environment — no CLI can. Run it bare and it prints the exact line for your shell; fish, PowerShell and cmd each get their own syntax.

the bonus nobody expects

A second identity for your MCP servers

OAuth-based MCP connections are stored per config dir, exactly like your Claude login. So a slot isn't only a second Claude account — it's a second set of credentials for everything Claude connects to.

~/.claude-work

Jira you@company.com
Drive work account
Linear company workspace

~/.claude-client

Jira you@client.io
Drive personal
Linear client workspace

Same MCP server, different identity, no re-authorizing when you switch — while skills and history stay shared across both. Useful for contractors, anyone in two orgs, or keeping a personal Notion well away from a company one.

The cost is the flip side of the same coin: each new slot authorizes its MCP servers once. That's the isolation doing its job, just pointed at something less convenient than your login.

the line

What crosses, and what never does

Shared

projects: /resume works across accounts
skills: write a skill once, every account has it
plans: plans made in one account readable from another
settings.json: one place for permissions, hooks, preferences

Per slot

the login: macOS Keychain, keyed per config dir — never a shared file
MCP auth: a different Jira or Drive identity per slot
sessions, history.jsonl: live sessions write these; sharing means two processes, one file
.claude.json, plugins: per-account state that updates independently

ccslot refuses to share .credentials.json even if you put it in your config. Sharing auth defeats the entire point.

before you commit

Things that will bite you

Same repo, two accounts, at once. They share projects/, so two live sessions in one repo are two processes writing near the same place. Nothing has corrupted in practice — but if you want it guaranteed, drop projects from the shared list and lose cross-account /resume.
Windows without Developer Mode. Symlinks need a privilege there, so ccslot falls back to junctions for directories and hard links for files. Same behaviour; ccslot view tells you which kind you got.
Backup tools and symlinks. If you sync ~/.claude, check whether your tool follows symlinks — some back up the same data once per slot.
Use accounts you're entitled to. Your own, or one your employer gave you. This isn't a way to farm accounts around limits.

The whole thing is one environment variable and four symlinks.

$ npx ccslot add work

source · npm · file a bug · contributing