Бонусы за приглашения

Как работают бонусы за приглашения

Поделитесь ссылкой. Когда друг зарегистрируется по ней и пополнит баланс, вы получите указанный бонус за его последующие пополнения.

Два аккаунта в Codex CLI: как разделить рабочий и личный вход

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

Содержание
Два аккаунта в Codex CLI: как разделить рабочий и личный вход

При использовании 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

Готовы оптимизировать LLM workflow?

Подключите единый API, управляйте ключами и контролируйте расходы на AI-модели в BetterToken.

Начать бесплатно