Несколько аккаунтов 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 с инструкциями для конкретного клиента.

Практические советы

• Называй директории чётко: ~/.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 — особенно когда оба экспонируют похожие по названию операции.

Профиль отвечает на вопрос which account am I in?. Он не отвечает на вопрос which project's tools should be active right now?. Для работы с более высокими ставками — добавь второй слой изоляции поверх разделения по аккаунтам:

• Один профиль на каждый 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, никаких конфликтов конфигураций, никакой утечки контекста. Решение, которое почти разочаровывающе простое — но именно это делает его хорошим. Настрой один раз и больше никогда не думай об этом.