Кілька акаунтів Claude Code на одному пристрої

Я користуюсь Claude Code щодня — і для особистих проєктів, і для роботи в компанії. Проблема: це два абсолютно різні акаунти з різними OAuth-сесіями, різними CLAUDE.md інструкціями, різними MCP-серверами та різною пам'яттю проєктів. Ось як я запускаю їх паралельно на одному пристрої за допомогою одного alias'а в шеллі.

Проблема

Claude Code за замовчуванням зберігає все в ~/.claude — OAuth-токен, історію розмов, глобальний CLAUDE.md, пам'ять проєктів, конфіги MCP-серверів і налаштування. Коли у тебе два акаунти, потрібні два повністю ізольовані середовища:

• Особистий акаунт: власна підписка Max/Pro, персональний CLAUDE.md з твоїми преференціями, твої MCP-сервери (Obsidian, особисті інструменти)
• Корпоративний акаунт: план компанії, робочий CLAUDE.md з інструкціями для Jira/Slack, корпоративні MCP-сервери
• Різні OAuth-сесії: неможливо бути залогіненим у два акаунти в одній директорії конфігурації
• Різна пам'ять проєктів: ти не хочеш, щоб контекст робочих проєктів потрапляв у особисті сесії і навпаки

Розлогінюватись і логінитись кожного разу при зміні контексту — не варіант. Ти втрачаєш стан сесії, і це просто болісно.

Рішення: CLAUDE_CONFIG_DIR

Claude Code підтримує одну змінну середовища: CLAUDE_CONFIG_DIR. Вкажи будь-який шлях — і Claude використовуватиме цю директорію замість ~/.claude для всього: авторизації, історії, налаштувань, пам'яті. Весь процес займає 60 секунд.

Крок 1: Створити другу директорію конфігурації

Обери назву, яка відповідає твоєму випадку:

mkdir ~/.claude-work

Все. Claude заповнить її необхідною структурою при першому запуску.

Крок 2: Авторизувати другий акаунт

Запусти Claude з новою директорією конфігурації для OAuth-логіну:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Відкриється браузер. Залогінся корпоративним акаунтом. OAuth-токен збережеться в ~/.claude-work — повністю окремо від особистої сесії в ~/.claude.

Крок 3: Додати shell alias

Додай це в конфіг шеллу, щоб не запам'ятовувати змінну:

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

Перезавантаж шелл:

source ~/.zshrc

Що отримуєш

Тепер у тебе два повністю ізольовані середовища Claude:

• claude — запускає з особистим акаунтом, персональним CLAUDE.md, особистою пам'яттю
• claude-work — запускає з корпоративним акаунтом, робочим CLAUDE.md, окремою пам'яттю
• Ізольована історія: робочі розмови залишаються в роботі, особисті — в особистому
• Окремі MCP-сервери: твій Obsidian vault MCP не з'являється в робочих сесіях
• Незалежні налаштування: різні дозволені інструменти, різні рівні дозволів, різні преференції моделей для кожного акаунту

Як це працює під капотом

Директорія конфігурації — єдине джерело істини для стану Claude Code. Ось що живе всередині кожної:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

Коли запускаєш claude-work, Claude читає все з ~/.claude-work. Він не знає про існування ~/.claude. Два інстанси повністю незалежні — можеш навіть запускати їх одночасно в різних вкладках терміналу.

Масштабування на N акаунтів

Патерн розширюється на будь-яку кількість акаунтів. Фрілансер з кількома клієнтами? Додай більше alias'ів:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Кожен alias отримує власну директорію конфігурації, власну OAuth-сесію, власний CLAUDE.md з інструкціями для конкретного клієнта. Для клієнта A — CLAUDE.md з конвенціями його кодової бази і Jira-проєктом, для клієнта B — абсолютно інший.

Практичні поради

• Називай директорії чітко: ~/.claude-work, ~/.claude-clientname — подякуєш собі, коли їх буде три-чотири
• Пиши окремий CLAUDE.md для кожного: робочий може включати інструкції компанії (як створювати Jira-тікети, Slack-канали, процедури деплою). Особистий залишається мінімальним.
• Різні MCP-сервери для кожного акаунту: налаштуй робочі інструменти (Jira MCP, Slack MCP, внутрішні API) тільки в робочому конфігу. Тримай особистий чистим.
• Перевір який акаунт активний: запусти claude config list в сесії, якщо не впевнений — покаже шлях до директорії конфігурації

Де цей підхід ламається

CLAUDE_CONFIG_DIR розділяє по акаунту, а не по проєкту. Всередині одного профілю Claude бачить усі MCP-сервери, які ти зареєстрував для цього акаунту — по всіх своїх проєктах. Для соло-використання це зазвичай не проблема. Але як тільки під одним акаунтом з'являється кілька production-критичних проєктів, особливо в дотичних доменах (білінг, адмінка, інфраструктура), виникає реальний cross-project ризик: AI-асистент може викликати tool з проєкту A під час роботи над проєктом B, особливо коли обидва експонують подібні за назвою операції.

Профіль відповідає на питання який це акаунт. Він не відповідає на питання tools якого проєкту мають бути активні зараз. Для роботи з вищими ставками — додай другий шар ізоляції поверх розподілу по акаунтах:

• Один профіль на кожен production-критичний проєкт, а не лише на акаунт: замість ~/.claude і ~/.claude-work створи ~/.claude-work-billing і ~/.claude-work-admin. Кожен профіль бачить лише ті MCP-сервери, які йому реально потрібні.
• Project-scope MCP через .mcp.json: поклади .mcp.json у корені проєкту з MCP-серверами лише цього проєкту. Claude підхопить їх, коли запущений з цієї директорії. Тримай глобальний конфіг мінімальним — лише універсальні інструменти (нотатки, пошук), жодних production-ендпоінтів.
• Іменуй MCP-сервери однозначно: уникай generic-назв на кшталт admin, billing, mcp-server. Префіксуй назвою проєкту: acme_billing_prod, acme_admin_stage. Описова назва змушує зупинитись, коли щось от-от викличеться з неправильного контексту.
• Перечитуй кожен MCP tool call перед approve: виклики на кшталт *_create_*, *_delete_*, *_charge_* заслуговують на свідомий другий погляд. Швидкість, яку дає blanket auto-approval, випаровується першого ж разу, коли tool з не того проєкту вистрелить у production.

Загальне правило: дроби профілі агресивно, тримай production-grade MCP подалі від default-профілю, і будь-яке перетинання назв tools між проєктами вважай як smell, що варто рефакторити.

Висновок

Одна змінна середовища. Один alias. Повна ізоляція між акаунтами. Ніякого logout/login, ніяких конфліктів конфігурацій, ніякого витоку контексту. Це рішення, яке майже розчаровуюче просте — але саме це робить його хорошим. Налаштуй один раз і більше ніколи не думай про це.