Best practices

Two Claude Code Accounts on One Computer: The Complete Isolation and Shared Skills Setup Guide

If you build custom agent skills or author complex prompts, you quickly hit a common constraint: you need more than one Claude Code account on the same workstation. Perhaps you manage an enterprise client account alongside your personal open-source profile, or you need to test team rate limits without burning your personal subscription tier. Switching between accounts should not mean logging in and out of the browser ten times a day or duplicating your skill repository across multiple directories.

Claude Code resolves this cleanly through an environment variable named CLAUDE_CONFIG_DIR. By pointing different editor instances or terminal tabs to distinct configuration directories, you can operate two or more completely independent Claude Code personas simultaneously. The key architectural trick is knowing what must stay strictly isolated, and what can be safely shared across accounts using filesystem junctions.

Dual Claude Code Architecture on One Machine diagram showing isolated account containers and canonical shared skills hub
Dual Claude Code Architecture: isolating credentials and session transcripts while sharing a single canonical skill library via directory junctions.

1. The Core Architecture: Isolation vs Shared Knowledge

Every Claude Code installation stores its internal state in a configuration folder. By default on Windows, this lives at %USERPROFILE%\.claude (or ~/.claude on macOS and Linux). When you set CLAUDE_CONFIG_DIR, you redirect Claude Code to read and write all state in an alternate location.

To avoid silent corruption or credential leakage, you must draw a hard boundary between identity state and shared knowledge:

  • Never share across accounts: .credentials.json (OAuth tokens), .claude.json (account state and local MCP registrations), settings.json (user preferences and hook choices), projects/ (conversation transcripts and session logs), and plugins/ (mutable cache).
  • Safely share across accounts: skills/ (your custom SKILL.md packages), CLAUDE.md (global project instructions), and helper scripts or CLI utilities.

If you already have a working Claude Code profile in your user directory, you do not need to move it. Keep the default profile as Account A, and create a single new folder for Account B. On our test workstation, the default profile handles primary development, while a second dedicated directory manages client testing.

2. Directory Layout and Storage Planning

Choose a dedicated root folder accessible to your user account. Here is a clean, production-tested folder topology for Windows:

D:\Claude\
  accounts\
    personal\               Claude Code Account A
      .credentials.json     Created upon sign-in (keep private)
      .claude.json          Account state and MCP registrations
      settings.json         Account-specific settings
      CLAUDE.md             Import stub pointing to shared instructions
      skills\               Directory junction -> ..\..\shared\skills
      projects\             Account-specific session transcripts
    work\                   Claude Code Account B
      .credentials.json     Created upon work sign-in
      .claude.json
      settings.json
      CLAUDE.md
      skills\               Directory junction -> ..\..\shared\skills
      projects\
  shared\
    skills\                 Canonical skill folders (version-controlled repo)
    CLAUDE.md               Global instructions both accounts read
    scripts\                Shared helper scripts and utilities

3. Linking Shared Skills with Directory Junctions

Rather than copying your skills between account folders, use directory junctions on Windows or symbolic links on macOS and Linux. On Windows, directory junctions are superior to symlinks because they do not require elevated administrator privileges and behave as native filesystem pointers.

Close your code editors, create the directory structure, and create the junctions with PowerShell:

$sharedSkills = 'D:\Claude\shared\skills'
$accountA = 'D:\Claude\accounts\personal'
$accountB = 'D:\Claude\accounts\work'

# Create base directories if they do not exist
New-Item -ItemType Directory -Force -Path $sharedSkills, $accountA, $accountB

# Create directory junctions for the skills folder
New-Item -ItemType Junction -Path "$accountA\skills" -Target $sharedSkills
New-Item -ItemType Junction -Path "$accountB\skills" -Target $sharedSkills

On macOS or Linux, standard symbolic links achieve the same result:

mkdir -p "$HOME/Claude/accounts/personal" "$HOME/Claude/accounts/work" "$HOME/Claude/shared/skills"
ln -s "$HOME/Claude/shared/skills" "$HOME/Claude/accounts/personal/skills"
ln -s "$HOME/Claude/shared/skills" "$HOME/Claude/accounts/work/skills"

Whenever you add, modify, or debug a skill in the shared directory, both accounts immediately see the changes. Progressive disclosure functions normally because Claude Code indexes the junction target on demand.

4. Sharing Global Instructions via Absolute Imports

Both accounts often need the same high-level system rules, behavioral standards, and formatting guidelines. Instead of duplicating text across multiple CLAUDE.md files, place a canonical instruction file in your shared directory and import it using the @ syntax.

In each account directory (for example, D:\Claude\accounts\work\CLAUDE.md), create a one-line file:

@D:/Claude/shared/CLAUDE.md

Claude Code resolves absolute @ references at session startup. Any rules you update in shared\CLAUDE.md instantly govern both environments while preserving account-level autonomy.

5. Routing Your Editors via Settings

The most elegant way to run dual accounts is assigning one account to your primary editor (such as VS Code or Antigravity) and the second account to an alternate editor (such as Cursor). This gives you visual separation with zero terminal toggling.

Configure the claudeCode.environmentVariables property inside each editor user settings. In Cursor, open settings.json and configure Account A:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CONFIG_DIR", "value": "D:\\Claude\\accounts\\personal" }
  ]
}

In Antigravity or Visual Studio Code, configure Account B:

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CONFIG_DIR", "value": "D:\\Claude\\accounts\\work" }
  ]
}

6. Running Dedicated Terminal Sessions

When working outside the editor GUI, your command line shell does not inherit editor extension variables. To launch a CLI session in a specific account, export the variable in your current terminal session before launching:

You type: $env:CLAUDE_CONFIG_DIR = "D:\Claude\accounts\work"
You type: claude
Claude announces: Claude Code (Work Profile)
Output: Active config: D:\Claude\accounts\work
Output: Loaded 14 skills from shared junction
Launch Claude Code in the work account from a standalone terminal.

7. Authentication and the Logout Boundary

Authentication is strictly bound to the active CLAUDE_CONFIG_DIR. When you execute /logout or trigger Claude Code: Logout from the command palette, you sign out only the directory used by that active session. The sibling account remains completely authenticated.

When completing browser authorization for the second account, verify which email address is active in your browser tab. If your browser defaults to your personal Google or Anthropic account, switch profiles before clicking authorize.

Interactive Claude Code Session: Dual Account Routing and Junction Verification
claude-code-workspace/Dual Account Routing: Verify Isolation
Verify our dual Claude Code configuration. Confirm the active CLAUDE_CONFIG_DIR points to our isolated work profile, check directory junctions to shared skills, and prove that credentials remain segregated.
Active configuration directory confirmed. Claude Code is operating in the isolated work profile under D:\Claude\accounts\work with its own private credentials and session transcripts. The shared skills directory is linked cleanly via Windows directory junction with zero cross-account credential leakage.
#89claude-code-workspace
config/dual-account-isolationVerified
To configure your dual accounts, read the full isolation guide and link your shared skills.
Auto
OpusExtra high
Interactive session: inspect active CLAUDE_CONFIG_DIR, verify directory junctions, and test shared skill triggering without auth leaks.

Mastering multi-account isolation is part of our structured learning curriculum for professional tool builders:

  1. Step 1: Skill Authoring and Progressive Disclosure. Write modular SKILL.md packages that load only required context into memory.
  2. Step 2: Filesystem Junctions and Shared Repositories. Maintain one canonical skill library and link it across isolated execution containers without duplicating code.
  3. Step 3: Multi-Account Context Orchestration. Route specialized roles (such as client audits vs open-source authoring) to dedicated Claude profiles with zero cross-contamination.

Cross-Site Perspectives

For open-source maintainers and DevOps teams managing Git worktrees, SSH keys, GPG signing, and automated CI/CD pipelines, read our companion piece on Claude Skills Hub: [Multi-Account Claude Code Architecture: Git Worktrees, Identity Isolation, and Terminal DevOps Pipelines](https://claudeskillsgithub.com/blog/multi-account-claude-code-devops-git-worktrees).

For enterprise systems architects and engineering leaders evaluating tenant data governance, SOC2 compliance boundaries, and token economics, explore the breakdown on ClaudeSkillsGuide: [Multi-Tenant Claude Code Architecture: Identity Boundaries, Shared Knowledge Topologies, and Enterprise Governance](https://claudeskillsguide.com/blog/multi-tenant-claude-code-architecture-enterprise-governance).

Stay connected

Never miss a post

Updates on format changes, community features, and skill building.