Claude Code тримає лише один вхід за раз. Ось як запустити кілька.

Є момент, який трапляється майже з кожним, хто використовує Claude Code і для роботи, і для власних проєктів. Ви завершуєте робочу сесію, перемикаєтесь на побічний проєкт і розумієте, що агент досі авторизований в обліковому записі, за який платить ваш роботодавець. Тож ви виходите, входите знову зі своїм власним обліковим записом, а через півгодини доводиться робити все навпаки.

Цей цикл не є відсутньою функцією. Це наслідок того, де Claude Code зберігає дані входу, і щойно ви дізнаєтесь, де саме, паралельний запуск кількох облікових записів стає деталлю конфігурації, а не проблемою робочого процесу.

Одна змінна середовища вирішує, який обліковий запис активний

Claude Code не зберігає облікові дані в базі даних чи в записі зв'язки ключів, прив'язаному до профілю. Він читає все потрібне з одного каталогу: облікові дані, метадані сесій та історію по проєктах.

Цим каталогом є той, на який вказує CLAUDE_CONFIG_DIR. Якщо ви ніколи не задавали цю змінну, це ~/.claude.

Це весь механізм, і він має корисну властивість: оскільки обліковий запис є каталогом, а не глобальним налаштуванням, два облікові записи означають два каталоги. Між ними немає нічого спільного. Обидва залишаються авторизованими необмежено довго, і жоден із них не знає про існування іншого.

Тож наївний варіант працює:

# особистий
CLAUDE_CONFIG_DIR=~/.claude claude

# робочий
CLAUDE_CONFIG_DIR=~/.claude-work claude

Виконайте /login один раз у другому, і у вас буде два активні облікові записи на одній машині.

Де підхід через shell починає дошкуляти

Наведений вище варіант із двох рядків справді нормальний, якщо ви відкриваєте по одному терміналу за раз і ви дисципліновані. Він перестає бути нормальним із трьох причин, і вони накопичуються.

Змінна діє на процес, а не на машину. Кожен новий термінал, кожна нова панель, кожен вбудований у редактор shell стартує зі значення за замовчуванням із вашого профілю. Експортуйте її в .zshrc, і ви просто перемістите проблему: тепер ви постійно забуватимете про інший обліковий запис.

Ніщо не підказує вам, який обліковий запис активний. Claude Code не виводить обліковий запис у своєму запрошенні. Якщо у вас відкрито два термінали й один із них працює на робочому обліковому записі, вони виглядають однаково. Момент, коли ви це помічаєте, зазвичай збігається з моментом, коли ви перевіряєте рахунок.

Він не витримує паралелізму. Цікаві конфігурації запускають кілька агентів одночасно на кількох проєктах. Щойно ви виходите за межі двох одночасних сесій, запам'ятовування того, яка панель була запущена з якою змінною, стає не проблемою дисципліни, а проблемою дизайну.

Виправлення полягає не в тому, щоб додати ще shell. Воно полягає в тому, щоб перестати ухвалювати рішення в момент запуску й почати прив'язувати обліковий запис до того, що насправді його визначає: до проєкту.

Прив'яжіть обліковий запис до проєкту, а не до термінала

Зазвичай вам потрібне правило, а не команда. Щось на кшталт: репозиторій цього клієнта завжди працює на обліковому записі цього клієнта. Щойно таке правило існує, нікому не треба нічого пам'ятати.

Зробити це як слід означає визначати обліковий запис у чітко заданому порядку, бо правило потребує винятків. Значення за замовчуванням на рівні проєкту підходить у більшості випадків, але якомусь конкретному агенту може знадобитися працювати деінде: одноразовий експеримент на тестовому обліковому записі або агент код-рев'ю на місці з більшою квотою.

Читайте згори вниз: перемагає перше правило, яке збігається. Перевизначення на рівні агента перемагає прив'язку до проєкту. Прив'язка до проєкту перемагає те, що ви задали як загальне значення за замовчуванням. Якщо ніде нічого не налаштовано, ви потрапляєте в ~/.claude, і саме це вже робить свіже встановлення. Цей останній запасний варіант важливий: він означає, що додавання цього до наявної конфігурації нічого не змінює, доки ви явно щось не закріпите.

Саме цю модель реалізує AgentsRoom. Кожен обліковий запис є керованим каталогом, вхід відбувається всередині застосунку, а не в shell, а описане вище визначення виконується під час запуску агента й задає CLAUDE_CONFIG_DIR лише для цього процесу. Якщо ви вже користуєтесь стороннім перемикачем на кшталт CCS, ви можете вказати обліковому запису наявний каталог профілю замість того, щоб входити знову.

Та сама проблема існує в Codex, лише з іншою змінною

Якщо ви використовуєте більш ніж одного провайдера, ви зіткнетеся з цим двічі. Форма проблеми ідентична, а змінна ні, тому перемикач, створений для одного, не покриває іншого. Ми документуємо частину про Codex окремо: мультиакаунт для Codex, включно з тим, що відрізняється у процесі входу.

Загальну думку варто озвучити один раз: ізоляція облікових записів є механізмом, специфічним для кожного провайдера. Будь-який інструмент, який заявляє, що обробляє це глобально, або обгортає кожного провайдера окремо, або підтримує лише одного.

Знайте, який обліковий запис насправді витрачає токени

Розділення облікових записів є лише половиною причини, чому люди це роблять. Друга половина полягає в тому, щоб знати, куди йде споживання, особливо коли платить клієнт.

Саме ця частина тихо ламається при підході через shell. Лічильники використання, які дивляться лише в ~/.claude, почнуть занижувати показники тієї миті, коли агент запуститься деінде, а цифри виглядають достатньо правдоподібно, щоб тижнями цього ніхто не помічав. Лічильник, який враховує облікові записи, має обходити кожен налаштований каталог, а не лише той, що за замовчуванням.

Якщо вам потрібні цифри по облікових записах і по сесіях, ми описали бік вимірювання в статті як перевірити використання токенів Claude Code, а живий перегляд є на сторінці використання токенів.

Для чого це не призначено

Одне уточнення, бо це питання виникає й заслуговує на пряму відповідь, а не на мовчання.

Усе описане вище стосується розділення облікових записів, які вже існують легітимно. Місце, за яке платить ваш роботодавець, і особиста підписка, за яку платите ви, це дві різні комерційні угоди, і тримати їх на одній машині без взаємного змішування є реальною, звичайною потребою. Так само як і виставляти клієнту рахунок за спожиті ним токени, і так само як і тримати експериментальний обліковий запис подалі від робочого.

Створення додаткових облікових записів заради обходу лімітів потужності вашого тарифного плану є іншою річчю, і саме на це спрямовані політики використання. Описаний тут механізм не робить це прийнятним, а інструмент, який би це автоматизував, допомагав би вам порушити угоду, яку ви підписали. Якщо ваш другий обліковий запис існує тому, що за нього платить хтось інший, ви на твердому ґрунті. Якщо він існує, щоб скинути ліміт швидкості, то ні. Орієнтиром є політики використання Anthropic, а не ця стаття.

Питання, які люди справді ставлять

Чи можу я використовувати два облікові записи Claude Code на одному комп'ютері?

Так. Claude Code читає свої облікові дані, метадані сесій та історію проєктів із каталогу, на який вказує CLAUDE_CONFIG_DIR, а за замовчуванням це ~/.claude. Спрямуйте цю змінну на другий каталог, увійдіть там, і ви матимете два незалежні облікові записи на одній машині. Між цими двома каталогами немає нічого спільного, тож обидва залишаються авторизованими одночасно.

Як перемкнути облікові записи Claude Code, не виходячи з системи?

Виходити взагалі не потрібно. Вихід і повторний вхід використовують той самий каталог, тож ви втрачаєте першу сесію, щоб отримати другу. Натомість дайте кожному обліковому запису власний каталог конфігурації й обирайте між ними, задаючи CLAUDE_CONFIG_DIR під час запуску CLI. Обидва набори облікових даних залишаються дійсними на диску, а перемикання нічого не коштує.

Де Claude Code зберігає дані входу?

У каталозі, на який вказує CLAUDE_CONFIG_DIR, тобто в ~/.claude, якщо ви його не змінювали. Самі облікові дані потрапляють у файл .credentials.json усередині цього каталогу, поруч із метаданими сесій та історією по проєктах. Цей єдиний каталог і є всім обліковим записом, і саме тому його підміна є чистим перемиканням, а не хаком.

Чи можуть два агенти працювати на двох різних облікових записах Claude одночасно?

Так, якщо кожен процес агента отримує власний CLAUDE_CONFIG_DIR у своєму середовищі. Змінна читається для кожного процесу під час запуску, а не глобально, тож два агенти, запущені з двома різними значеннями, працюють на двох різних облікових записах паралельно. Саме це робить робочий і особистий проєкти придатними для роботи в одному вікні.

Чи суперечить умовам Anthropic наявність більш ніж одного облікового запису Claude?

Мати окремі облікові записи для різних цілей цілком нормально: місце, за яке платить ваш роботодавець, і особиста підписка, за яку платите ви, це дві різні комерційні угоди. Політики використання спрямовані проти створення облікових записів заради обходу лімітів потужності вашого тарифного плану. Якщо ваш другий обліковий запис існує тому, що за нього платить хтось інший, ви на твердому ґрунті. Якщо він існує, щоб скинути ліміт швидкості, то ні. Орієнтиром є політики використання Anthropic.

Коротка версія

Claude Code зберігає обліковий запис як каталог, а CLAUDE_CONFIG_DIR вирішує, який із них активний. Два каталоги означають два облікові записи, які постійно авторизовані й нічим не діляться між собою.

Варіант через shell працює, доки у вас відкрито не більше одного термінала. Після цього вам потрібно, щоб обліковий запис був властивістю проєкту, з перевизначенням на рівні агента для винятків, аби правильні облікові дані підставлялися в момент запуску й нікому не доводилося нічого пам'ятати.