> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ccs.kaitran.ca/llms.txt
> Use this file to discover all available pages before exploring further.

# Claude Accounts

> Manage multiple Claude subscriptions with separate account profiles

# 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.

<Note>
  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](/features/pool). The two are different lanes and do not share
  session history.
</Note>

## 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"`:

1. CCS points `CLAUDE_CONFIG_DIR` to `~/.ccs/instances/work/`
2. Claude loads that profile's credentials and state from the directory
3. 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

```bash theme={null}
# 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

```bash theme={null}
# 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`, and `settings.json`. 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:

```text theme={null}
~/.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.

## Context Groups (Opt-in Sharing)

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.

```yaml theme={null}
# ~/.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

<Note>
  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.
</Note>

## Deeper Continuity

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

```bash theme={null}
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:

```bash theme={null}
ccs auth create work2 --share-context --context-group daily --deeper-continuity
```

## Concurrent Sessions

<Warning>
  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.
</Warning>

```bash theme={null}
# 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

```bash theme={null}
# 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:

```bash theme={null}
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.

## 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

<CardGroup cols={2}>
  <Card title="API Profiles" icon="key" href="/providers/concepts/api-profiles">
    Combine Claude accounts with API key providers
  </Card>

  <Card title="Provider Overview" icon="grid" href="/providers/concepts/overview">
    Compare Claude accounts vs OAuth providers
  </Card>

  <Card title="Configuration" icon="gear" href="/getting-started/configuration">
    Config file format for accounts
  </Card>

  <Card title="Tutorials: Multi-Account" icon="users" href="/tutorials/multi-account-setup">
    Step-by-step multi-account setup guide
  </Card>
</CardGroup>