Claude Accounts

CCS lets you create multiple Claude account profiles such as work, personal, and team. Different profiles normally use different Claude config directories. Launching the same profile twice reuses the same directory and shared state.

This page covers native account profiles, which keep each account separate with its own session history. If instead you want several Claude accounts to act as one pool that auto-continues when an account hits its limit, see Account Pools. The two are different lanes and do not share session history.

How It Works

CCS uses CLAUDE_CONFIG_DIR to point Claude at a specific account profile directory:

~/.ccs/instances/work/        # Work account
~/.ccs/instances/personal/    # Personal account

When you run ccs work "task":

CCS points CLAUDE_CONFIG_DIR to ~/.ccs/instances/work/
Claude loads that profile’s credentials and state from the directory
The session reuses the work profile’s account lane

In practice:

ccs work + ccs personal normally use separate account directories
ccs work + ccs work reuses one account directory
Continuity inheritance can make different profile names reuse one account directory on purpose

The recommended two-account route is to create both account profiles, then run the account you want by name. This keeps credentials, tokens, and Claude’s .anthropic state isolated unless you explicitly opt in to shared continuity.

Quick Start

# Create accounts
ccs auth create work
ccs auth create personal

# Use them
ccs work "review this PR"
ccs personal "help with side project"

# Inspect isolation, settings sync, and resume lane
ccs auth show work

# Concurrent sessions (different terminals)
# Terminal 1: ccs work "implement feature"
# Terminal 2: ccs personal "research topic"

Profile Management

# List all accounts
ccs auth list

# Set default account (used when running bare `ccs`)
ccs auth default work

# Remove account
ccs auth remove personal --force

Bare vs Non-Bare Profiles

Mode	Description	Use Case
Standard	Full account profile with its own `~/.ccs/instances/<name>/`	Most users
`--bare`	Thin profile that wraps the default Claude config dir	Minimal isolation

Standard profiles are recommended for most use cases. Non-bare profiles also reuse the shared CCS layout for commands, skills, agents, plugins, settings.json, and user CLAUDE.md. On supported platforms that is usually implemented with symlinks; on Windows, CCS may fall back to copying when symlink creation fails. For settings.json, the normal non-bare path is:

~/.ccs/instances/<account>/settings.json
  -> ~/.ccs/shared/settings.json
  -> ~/.claude/settings.json

That is settings sync, not token sync. Use ccs auth show <account> to confirm whether the profile settings are currently shared with root Claude settings. User instructions follow the same chain, with ~/.claude/CLAUDE.md as the canonical source. See Shared Data for conflict recovery behavior. By default each account keeps its own project context. Use shared context only when you explicitly want multiple accounts to reuse the same project workspace.

# ~/.ccs/config.yaml
accounts:
  alice:
    context_mode: shared
    context_group: "team-alpha"
  bob:
    context_mode: shared
    context_group: "team-alpha"   # Same group = shared context
  charlie:
    context_mode: shared
    context_group: "team-beta"    # Different group = separate project context

Accounts in the same context_group share:

Project workspace via the projects/ area
Optional deeper continuity artifacts when you enable deeper continuity

Shared context is explicit opt-in. Use an explicit context_group when configuring shared mode so the scope is obvious in both CLI and dashboard workflows.

Deeper Continuity

Enable cross-session memory persistence with the --deeper-continuity flag:

ccs work --deeper-continuity "continue the refactor from yesterday"

This keeps additional continuity artifacts aligned for that shared context group, including session-env, file-history, shell-snapshots, and todos. For existing accounts, configure both accounts with shared mode and the same group from Dashboard -> Accounts -> Sync, or recreate the intended lane with:

ccs auth create work2 --share-context --context-group daily --deeper-continuity

Concurrent Sessions

Running the same profile in two terminals is allowed, but both terminals reuse the same CLAUDE_CONFIG_DIR and shared mutable state. Use different profiles when you want stronger separation.

# Separate state:
# Terminal 1
ccs work "implement auth"

# Terminal 2
ccs personal "write tests"

# Shared state on purpose:
# Terminal 1: ccs work "task A"
# Terminal 2: ccs work "task B"

Instance Directory Structure

~/.ccs/instances/work/
├── .anthropic/        # Claude-managed metadata
├── session-env/       # Chat history and context
├── todos/             # Task lists
├── logs/              # Execution logs
├── file-history/      # Recent file context
├── shell-snapshots/   # Shell continuity artifacts
├── debug/             # Debug artifacts
├── commands/          # Shared link/copy in non-bare profiles
└── skills/            # Shared link/copy in non-bare profiles

Default Account

# Set work as default
ccs auth default work

# Now bare `ccs` uses the work account
ccs "review this code"

Before changing the default lane, back up the current native lane:

ccs auth backup default
ccs auth default work

Setting the default only affects future plain ccs sessions. It does not import old native ~/.claude/projects history into the selected account profile.

Resume the Correct Session Lane

Claude stores session history under the active CLAUDE_CONFIG_DIR. The ANTHROPIC_BASE_URL only selects where requests are sent; changing it does not move, merge, or change ownership of session history. When you resume by session ID, use the account profile that owns the session:

ccs work --resume '<session-id>'

CCS checks the native lane and registered account profiles with valid names for explicit session IDs. Discovery only trusts a normal projects/ tree contained inside its lane; symlinked project roots, project directories, or session files that point elsewhere are ignored. If the session belongs to another account, CCS prints that account’s exact resume command. Back up that lane before changing its setup:

ccs auth backup work

If the session belongs to the native Claude lane and plain ccs still uses that lane, resume normally:

ccs --resume '<session-id>'

If plain ccs is mapped to an account with ccs auth default, it searches that account lane instead. CCS prints a command for the detected shell that clears provider routing credentials, selects the native config directory, and resumes with claude. Copy the command CCS prints; these examples show its shape:

Bash / Zsh
Fish
PowerShell
Command Prompt

unset ANTHROPIC_BASE_URL; unset ANTHROPIC_AUTH_TOKEN; unset ANTHROPIC_API_KEY; export CLAUDE_CONFIG_DIR="$HOME/.claude"; claude --resume 00000000-0000-4000-8000-000000000000

set -e ANTHROPIC_BASE_URL; set -e ANTHROPIC_AUTH_TOKEN; set -e ANTHROPIC_API_KEY; set -gx CLAUDE_CONFIG_DIR "$HOME/.claude"; claude --resume 00000000-0000-4000-8000-000000000000

Remove-Item Env:ANTHROPIC_BASE_URL -ErrorAction SilentlyContinue; Remove-Item Env:ANTHROPIC_AUTH_TOKEN -ErrorAction SilentlyContinue; Remove-Item Env:ANTHROPIC_API_KEY -ErrorAction SilentlyContinue; $env:CLAUDE_CONFIG_DIR = "$HOME/.claude"; claude --resume 00000000-0000-4000-8000-000000000000

set "ANTHROPIC_BASE_URL=" && set "ANTHROPIC_AUTH_TOKEN=" && set "ANTHROPIC_API_KEY=" && set "CLAUDE_CONFIG_DIR=%USERPROFILE%\.claude" && claude --resume 00000000-0000-4000-8000-000000000000

This explicit native route leaves the configured default account unchanged and does not merge history. If CCS cannot locate an explicit session ID, recover the original plain lane first, back it up, then optionally make the intended account the default for future plain ccs sessions:

ccs -r
ccs auth backup default
ccs auth default work

Do not copy or combine projects/ histories between account directories to fix a resume mismatch. Resume from the owning lane instead.

Cost

Each account requires its own Claude Pro (

20/month) or Max (

200/month) subscription.

Tier	Access	Cost
Claude Pro	Claude Opus 4.6, Sonnet 4.6, Sonnet 4.5, Haiku 4.5	$20/month
Claude Max	All Pro models with extended usage limits	$200/month

Next Steps

API Profiles

Combine Claude accounts with API key providers

Provider Overview

Compare Claude accounts vs OAuth providers

Configuration

Config file format for accounts

Tutorials: Multi-Account

Step-by-step multi-account setup guide

Getting Started

Providers

Features

Tutorials

Claude Accounts

Claude Accounts

How It Works

Quick Start

Profile Management

Bare vs Non-Bare Profiles

Deeper Continuity

Concurrent Sessions

Instance Directory Structure

Default Account

Resume the Correct Session Lane

Cost

Next Steps

API Profiles

Provider Overview

Configuration

Tutorials: Multi-Account

​Claude Accounts

​How It Works

​Quick Start

​Profile Management

​Bare vs Non-Bare Profiles

​Context Groups (Opt-in Sharing)

​Deeper Continuity

​Concurrent Sessions

​Instance Directory Structure

​Default Account

​Resume the Correct Session Lane

​Cost

​Next Steps

API Profiles

Provider Overview

Configuration

Tutorials: Multi-Account

Claude Accounts

How It Works

Quick Start

Profile Management

Bare vs Non-Bare Profiles

Context Groups (Opt-in Sharing)

Deeper Continuity

Concurrent Sessions

Instance Directory Structure

Default Account

Resume the Correct Session Lane

Cost

Next Steps