Два аккаунта в Codex CLI: как разделить рабочий и личный вход
Почему --profile не переключает учётную запись и как настроить отдельные CODEX_HOME для рабочих и личных задач с проверкой входа и оплаты.
Содержание

При использовании Codex CLI для личных проектов и рабочих задач возникает необходимость разделить контексты и учетные записи. Флаг --profile для этой цели не предназначен: согласно документации по базовой конфигурации, профили лишь накладывают файл $CODEX_HOME/<name>.config.toml поверх основного конфига (изменяя модель, уровень песочницы или MCP-серверы), но не переключают учетную запись.
Чтобы использовать разные учетные записи, задают независимые каталоги через переменную окружения CODEX_HOME и выполняют процедуру входа (codex login) для каждого каталога отдельно.
Риски ручного копирования файлов сессии
В статье на Habr описан пример пользовательской автоматизации: автор переключал аккаунты подменой файлов авторизации с помощью bash-скрипта и запрашивал остаток квот через недокументированный эндпоинт веб-интерфейса. Автор прямо указал на главный недостаток такого решения — зависимость от внутреннего API, который может измениться в любой момент.
Манипуляции с файлами авторизации могут нарушать жизненный цикл сессий: при обновлении refresh-токена в одном месте дубликат в другом каталоге рискует стать недействительным. Подобный случай с ошибкой авторизации после копирования файла описан в issue #15410. Единичный отчет не доказывает, что любая копия обязательно сломается, однако перенос файлов вручную создает ненужные риски. Штатный путь — дать CLI самостоятельно управлять сессиями в отдельных каталогах.
Хранилище учетных данных и ограничения политик
Перед настройкой каталогов важно учитывать, как и где сохраняются данные аутентификации. Согласно документации по авторизации, параметр cli_auth_credentials_store поддерживает следующие режимы:
file— учетные данные сохраняются в локальном файлеauth.jsonвнутри каталогаCODEX_HOME.keyring— данные помещаются в системное хранилище ключей (Keychain на macOS, Secret Service на Linux).auto— CLI пытается использовать системный keyring, а при его недоступности переходит на файловое хранилище.ephemeral— сессия удерживается только в оперативной памяти текущего процесса.
При планировании разделения профилей следует учитывать ограничения:
- Отдельные каталоги
CODEX_HOMEне гарантируют полную изоляцию, если на машине действуют централизованные политики организации (Managed configuration / requirements.toml). Если администратор принудительно задал метод входа или тип хранилища, эти правила имеют приоритет над локальными параметрами. - В исходном коде CLI сервис связки ключей различает каталоги по хэшу пути к
CODEX_HOME(см. storage.rs), поэтому утверждать, что разные каталоги автоматически разделяют одну запись в keyring, неверно. Тем не менее это не дает гарантий полной изоляции: фактическое поведение хранилища зависит от платформы и настроек системы, поэтому его стоит проверить на рабочей машине. - Нельзя заранее утверждать, что токены находятся исключительно в каталоге, пока не подтвержден активный режим хранилища.
Пошаговая настройка двух окружений
Настроим два явных каталога: $HOME/.codex-personal и $HOME/.codex-work. Существующий каталог ~/.codex при этом не изменяется и не удаляется.
Шаг 1. Подготовка каталогов
Создайте каталоги с правами доступа только для текущего пользователя:
mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"
Если политики вашей организации разрешают файловое хранилище, до выполнения входа в каждом каталоге можно явно задать параметр cli_auth_credentials_store = "file" в config.toml:
cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF
cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF
Если на устройстве применяются обязательные корпоративные требования к аутентификации, используйте одобренный администратором режим.
Шаг 2. Независимая авторизация
Вход через браузер связывается с сессией, активной в веб-интерфейсе chatgpt.com. Браузерное меню профиля показывает лишь текущую браузерную сессию, а не доказывает, какие credentials сохранились в данном CODEX_HOME. Проверять выбранный аккаунт и Workspace необходимо во время каждого browser login:
- перед входом в личное окружение переключитесь на персональную учетную запись;
- перед входом в рабочее окружение выберите соответствующий корпоративный аккаунт или Workspace.
Выполните вход для каждого окружения по отдельности:
env CODEX_HOME="$HOME/.codex-personal" codex login
env CODEX_HOME="$HOME/.codex-work" codex login
В каждом случае подтвердите запрос на авторизацию в открывшемся окне браузера. При любых сомнениях выполните штатный env CODEX_HOME="..." codex logout и повторите вход именно для нужного каталога, заново проверив аккаунт в браузере (читать или вручную копировать файлы токенов не следует).
Шаг 3. Проверка статуса входа
Проверьте статус авторизации в обоих каталогах:
env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status
Команда codex login status показывает лишь метод аутентификации, но не подтверждает личность конкретного пользователя. Обратите внимание на источник оплаты: ChatGPT-вход использует подписку или включенный лимит соответствующего плана и Workspace, тогда как вход по API-ключу оплачивается отдельно в OpenAI Platform.
Для данной инструкции ожидался именно ChatGPT-вход для двух разных аккаунтов. Если status показывает API key, сценарий нельзя считать выполненным — проверьте вход в этом каталоге.
Шаг 4. Тестовый запуск задачи
Для проверки рабочего окружения выполните реальную задачу в тестовом рабочем репозитории, ограничив права песочницей read-only:
cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Прочитай README.md и назови назначение проекта. Не меняй файлы"
Короткий read-only тест подтверждает работоспособность сессии и песочницы. Проверка раздела статистики (Usage) после теста в соответствующем аккаунте или Workspace дает лишь косвенный сигнал с задержкой, а не подтверждение личности. Если остаются сомнения, выполните штатный env CODEX_HOME="$HOME/.codex-work" codex logout и повторите вход, проверяя активный аккаунт в браузере.
Ежедневное использование
Для регулярной работы можно вызывать команды напрямую с явным указанием CODEX_HOME либо объявить две функции в конфигурационном файле оболочки (~/.zshrc или ~/.bashrc):
codex-personal() {
env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}
codex-work() {
env CODEX_HOME="$HOME/.codex-work" codex "$@"
}
Примеры вызова с передачей аргументов через "$@":
codex-work login status
cd /path/to/work-project
codex-work exec --sandbox read-only "Прочитай README.md и назови назначение проекта. Не меняй файлы"
codex-personal