Команда codex login в Codex CLI: авторизация, синтаксис и примеры

Команда codex login в Codex CLI служит для входа в учётную запись и подготовки среды командной строки к работе с Codex. Она связывает установленный CLI с аккаунтом ChatGPT через браузерную авторизацию или сохраняет API-ключ, переданный безопасным способом через стандартный ввод. Без этого шага Codex может не получить доступ к моделям, даже если сама программа установлена правильно и запускается без ошибок.

Интересный факт: API-ключ обычно не нужно и не следует указывать прямо в аргументах команды. Codex CLI может принять его через стандартный ввод, поэтому секрет не оказывается в истории команд оболочки.

На практике codex login используется в двух основных сценариях: разработчик входит через браузер с учётной записью ChatGPT либо передаёт API-ключ в автоматизированной среде, где открыть браузер невозможно. Ниже разберём синтаксис команды, способы авторизации, проверку текущего состояния, особенности работы на удалённых машинах и правила обращения с токенами и секретами.

Обзор команды codex login

Команда codex login отвечает именно за аутентификацию, то есть за подтверждение того, кто запускает Codex и от имени какой учётной записи должны выполняться запросы. Она не меняет модель, режим подтверждения действий или рабочую папку проекта. Эти параметры настраиваются отдельно.

Авторизация и разрешения — не одно и то же. Успешный вход подтверждает личность пользователя, но не отменяет ограничения безопасности Codex, правила доступа к файлам и необходимость подтверждать потенциально опасные операции.

При обычном интерактивном входе CLI запускает процесс авторизации в браузере. Пользователь открывает ссылку, подтверждает вход в аккаунт и возвращается в терминал. В зависимости от операционной системы браузер может открыться автоматически или потребуется скопировать URL вручную.

Вместо ChatGPT OAuth можно использовать API-ключ. Такой вариант особенно удобен для серверов, контейнеров, CI/CD и других сред, где нет графического интерфейса. Ключ передаётся через стандартный ввод с параметром --with-api-key. Codex CLI не получает его из командной строки в явном виде.

Задача	Команда	Когда использовать
Интерактивный вход	codex login	Рабочая станция с браузером и аккаунтом ChatGPT
Вход по API-ключу	codex login --with-api-key	Сервер, контейнер, CI/CD или локальная среда без браузера
Авторизация через устройство	codex login --device-auth	Удалённый терминал, если этот режим доступен в установленной версии
Проверка состояния	codex login status	Проверить, есть ли действующая сессия
Выход	codex logout	Удалить сохранённые данные авторизации из текущей среды

Набор функций может зависеть от версии Codex CLI. Поэтому перед использованием нового параметра полезно выполнить codex login --help. Это особенно важно в автоматизированных сценариях: старая версия CLI может не знать новый флаг, а обновлённая — изменить поведение отдельного режима.

Синтаксис команды codex login

Синтаксис команды небольшой, но у его элементов разные роли. У команды есть основной интерактивный режим, подкоманда проверки состояния и специальные параметры для API-ключа или авторизации через устройство.

Форма	Назначение	Интерактивность
codex login	Вход через браузерный поток авторизации	Да
codex login status	Показать состояние входа	Обычно нет
codex login --with-api-key	Принять API-ключ через стандартный ввод	Зависит от способа передачи ключа
codex login --device-auth	Запустить поток авторизации для устройства	Минимальная
codex login --help	Показать справку по доступным вариантам	Нет

Базовая форма без аргументов

Команда без параметров запускает стандартный интерактивный способ входа. Обычно Codex предлагает открыть страницу авторизации в браузере, после чего результат возвращается в CLI.

Запись	Ожидаемый результат
codex login	Запуск браузерной авторизации
codex login --help	Показ справки вместо входа

Подкоманда status

Подкоманда status используется для проверки текущего состояния авторизации. Она помогает отличить проблему со входом от проблемы с сетью, моделью, правами доступа или конфигурацией проекта.

Запрос статуса не выполняет новый вход и не обновляет токен вручную. Если сессия устарела или отсутствует, CLI сообщит об этом, после чего можно снова запустить codex login.

Параметр --with-api-key

Параметр --with-api-key указывает Codex CLI, что секрет будет передан через стандартный ввод. Это предпочтительнее, чем писать ключ непосредственно после команды или помещать его в аргумент оболочки.

Способ передачи	Пример	Оценка безопасности
Ввод вручную	codex login --with-api-key	Хороший вариант для локального терминала
Переменная окружения	printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key	Допустимо, если переменная защищена
Секрет CI/CD	printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key	Подходит при маскировании вывода
Аргумент команды	codex login --with-api-key sk-...	Не следует использовать

Параметр --device-auth

Параметр --device-auth запускает поток авторизации, рассчитанный на устройство или терминал, где обычное автоматическое открытие браузера неудобно. CLI может показать код и адрес страницы, которые пользователь открывает на другом устройстве.

Доступность этого режима зависит от версии Codex CLI и текущей реализации сервиса авторизации. Если установленная версия не поддерживает параметр, справка сообщит об ошибке. В таком случае нельзя заменять его произвольным флагом: используйте обычный codex login с ручным копированием ссылки или API-ключ через --with-api-key.

Параметр --help

Параметр --help выводит справочную информацию о команде и доступных параметрах. Это наиболее надёжный способ проверить локальный интерфейс перед написанием скрипта.

Особенно полезно проверять справку после обновления CLI или при переносе сценария между компьютером разработчика, сервером и CI-системой. Не стоит полагаться только на пример из старой статьи: интерфейс командной строки развивается, а доступные способы входа могут расширяться.

Практические примеры использования

Ниже приведены типовые сценарии, с которыми сталкиваются разработчики. Они показывают не только саму команду, но и безопасный способ встроить авторизацию в повседневную работу.

Практический пример 1: первый вход на локальном компьютере

На рабочем компьютере с установленным браузером достаточно запустить базовую команду. Этот способ удобен для личной разработки, потому что не требует копировать API-ключ в терминал.

$ codex login
Откройте страницу авторизации в браузере.
После подтверждения входа вернитесь в терминал.
Авторизация успешно завершена.

Если браузер не открылся автоматически, CLI обычно выводит URL. Его можно скопировать вручную. Не следует изменять адрес, удалять параметры из него или передавать ссылку посторонним людям: временная ссылка авторизации может быть чувствительной.

Практический пример 2: проверка успешного входа

После авторизации полезно сразу проверить состояние. Это особенно удобно в новом окружении, где непонятно, использует ли Codex текущую сессию, старые credentials или вообще не видит сохранённые данные.

$ codex login status
Authenticated: yes
Authentication method: ChatGPT

Точный текст вывода может отличаться между версиями. Важен смысл: CLI должен показать, что авторизация обнаружена и может использоваться.

Практический пример 3: вход через API-ключ вручную

Если нужен API-доступ, запустите команду без указания ключа в самой строке и вставьте секрет, когда CLI ожидает ввод. Такой вариант не помещает ключ в историю shell-команд.

$ codex login --with-api-key
Введите API-ключ через стандартный ввод:
[вставьте ключ и нажмите Enter]
Авторизация успешно завершена.

После вставки убедитесь, что терминал не выводит введённое значение обратно на экран. Если секрет случайно появился в логе, истории терминала или записи экрана, его следует считать раскрытым и заменить.

Практический пример 4: передача ключа из переменной окружения

Для локального скрипта можно передать ключ через переменную окружения и конвейер. Команда printf предпочтительнее некоторых вариантов echo, потому что предсказуемее обрабатывает специальные символы и не добавляет лишние параметры.

$ printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key
Авторизация успешно завершена.

Переменная окружения сама по себе не является идеальным хранилищем: её могут увидеть дочерние процессы, диагностические инструменты или неправильно настроенный CI. Поэтому такой способ следует применять только в доверенной среде и очищать переменную после завершения работы.

Практический пример 5: авторизация на удалённом сервере

На сервере без графической оболочки можно использовать режим устройства, если он доступен в установленной версии. CLI покажет инструкцию, которую можно выполнить в браузере на другом компьютере.

$ codex login --device-auth
Откройте страницу авторизации на другом устройстве.
Введите показанный код:
ABCD-EFGH
Ожидание подтверждения...
Авторизация успешно завершена.

Не публикуйте код устройства в общем чате и не оставляйте его в открытом терминальном логе. Такой код предназначен для связывания конкретного процесса входа с конкретной сессией.

Практический пример 6: вход в контейнере

Контейнер обычно не должен хранить персональную авторизацию разработчика. Если контейнер используется как временная среда, передавайте секрет через механизм секретов платформы, а не записывайте его в Dockerfile или образ.

$ docker run --rm 
  -e OPENAI_API_KEY 
  my-codex-image 
  sh -c "printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key"
Авторизация успешно завершена.

В реальной инфраструктуре лучше использовать secret mount или встроенное хранилище секретов оркестратора. Переменная окружения в примере показана для понимания механики, а не как универсальная рекомендация для production.

Практический пример 7: авторизация в CI/CD

В CI ключ должен храниться в защищённом разделе переменных проекта. В логах необходимо маскировать секрет, а команда не должна печатать его значение через режимы отладки оболочки.

script:
  - printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key
  - codex login status
  - codex exec "проверить состояние проекта"

Синтаксис YAML зависит от используемой CI-системы, но принцип одинаков: секрет подставляется системой выполнения, передаётся в стандартный ввод и не записывается в файл репозитория.

Практический пример 8: проверка входа перед запуском задачи

Перед дорогой или длительной операцией можно добавить предварительную проверку. Это позволяет завершить задачу с понятной ошибкой ещё до обращения к модели.

if codex login status >/dev/null 2>&1; then
  codex exec "проанализировать тесты"
else
  printf '%sn' "Codex не авторизован" >&2
  exit 1
fi

Скрипт ориентируется на код завершения команды. Точный текст статуса может меняться, поэтому для автоматизации лучше проверять именно код возврата, а не искать конкретную фразу в выводе.

Практический пример 9: повторный вход после смены аккаунта

Если нужно перейти с одной учётной записи на другую, сначала завершите текущую сессию. Это снижает риск случайно отправить запросы не из того профиля.

$ codex logout
Сохранённые данные авторизации удалены.

$ codex login
Запущена новая авторизация в браузере.

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

Практический пример 10: диагностика неизвестного параметра

Если команда из документации не выполняется, сначала запросите локальную справку. Это помогает отличить ошибку синтаксиса от ограничения версии.

$ codex login --help
Использование:
  codex login [OPTIONS]
  codex login status

Параметры:
  --with-api-key
  --device-auth
  -h, --help

Если в выводе нет конкретного параметра, не используйте его в скрипте. Обновите CLI из доверенного источника или выберите поддерживаемый вариант входа.

Вход через браузер и ChatGPT OAuth

Браузерный вход — самый простой вариант для человека, который работает на обычном компьютере. Команда открывает поток OAuth: Codex CLI направляет пользователя на страницу входа, сервис подтверждает личность, а CLI получает результат авторизации без ручного копирования постоянного API-ключа.

Главное преимущество браузерного входа — секрет аккаунта не вводится в терминал и не сохраняется в скрипте. Но это не означает, что авторизация полностью лишена рисков: нужно проверять адрес страницы и не подтверждать вход в подозрительном окне.

Обычно процесс выглядит так:

1. Запустить codex login.
2. Открыть предложенный URL в браузере.
3. Войти в нужную учётную запись.
4. Подтвердить предоставление доступа Codex.
5. Вернуться в терминал и дождаться сообщения об успешной авторизации.
6. Проверить результат командой codex login status.

Ситуация	Рекомендуемый вариант	Почему
Ноутбук разработчика	codex login	Удобно и не требует ручного управления API-ключом
Удалённый сервер с SSH	--device-auth или API-ключ	На сервере может не быть браузера
Общий компьютер	Временный вход с последующим codex logout	Не оставляет сессию следующему пользователю
Скрипт сборки	--with-api-key	Подходит для неинтерактивного запуска

Если браузер открыл страницу не на том компьютере, не копируйте туда случайные cookies или файлы профиля браузера. Надёжнее использовать предусмотренный CLI поток, ручную передачу ссылки или режим устройства, если он поддерживается.

Вход по API-ключу

API-ключ — это отдельный способ доступа, ориентированный на программное использование API. Он не равен паролю и не должен восприниматься как обычный текст: любой человек или процесс, получивший ключ, потенциально сможет выполнять запросы от имени его владельца в пределах доступных прав.

API-ключ следует считать паролем без кнопки «забыли пароль»: если он утёк, безопаснее немедленно отозвать его и создать новый, а не надеяться, что никто не успел им воспользоваться.

Корректный поток выглядит так: секрет извлекается из защищённого хранилища, подаётся в стандартный ввод команды и после завершения не сохраняется в открытом файле. Для локальной работы можно вставить ключ вручную, а для CI/CD — использовать секретную переменную или secret manager.

Источник ключа	Как передать	Основной риск
Ручной ввод	codex login --with-api-key	Случайная запись в журнал или скриншот
Переменная окружения	printf '%s' "$OPENAI_API_KEY" | codex login --with-api-key	Утечка через окружение процесса
Secret manager	Передача в stdin из защищённого источника	Ошибки настройки прав доступа
Файл в репозитории	Не использовать	Попадание ключа в историю Git и резервные копии
Аргумент командной строки	Не использовать	История shell и список процессов

Не добавляйте API-ключ в команды вроде codex login --with-api-key "$OPENAI_API_KEY", если интерфейс ожидает секрет через stdin. Такой вызов не только может не сработать, но и увеличивает вероятность раскрытия значения через историю команд или диагностику процессов.

Работа в терминале

Терминал передаёт программе данные через несколько каналов: аргументы, стандартный ввод, стандартный вывод и переменные окружения. Для авторизации особенно важно различать эти каналы, потому что секрет, введённый в аргумент, обычно защищён хуже, чем значение, поступившее через stdin.

Канал	Пример	Подходит для секрета
Аргументы	codex login --with-api-key ...	Нет
Стандартный ввод	printf '%s' "$KEY" | codex login --with-api-key	Да, при защищённом источнике
Переменная окружения	OPENAI_API_KEY=...	Временно и с осторожностью
Файл конфигурации	Локальное хранилище Codex CLI	Только с корректными правами доступа
Вывод терминала	Логи и отладка	Никогда не печатать секрет

Остерегайтесь включения трассировки shell, например set -x. В таком режиме оболочка может печатать выполняемые команды и раскрывать значения переменных. Перед авторизацией в CI и скриптах также проверьте, не включён ли подробный режим логирования.

Если команда ждёт ввода, не отправляйте секрет через пробелы или случайные управляющие символы. Для ключей, полученных из файлов, важно контролировать перевод строки: обычно printf '%s' позволяет передать значение без добавочного символа конца строки.

Авторизация в автоматизированной среде

CI/CD, cron-задачи, контейнеры и удалённые агенты не должны зависеть от браузерного окна и ручного подтверждения. Для них предназначен неинтерактивный путь с API-ключом, передаваемым через стандартный ввод. Авторизацию лучше выполнять на старте временной среды, а не встраивать секрет в образ или исходный код.

Хорошая автоматизация не просто «умеет войти», а не оставляет после себя секретов в логах, артефактах, образах и кэше.

Среда	Предпочтительная схема	Что проверить
GitHub Actions и аналоги	Secret variable → stdin	Маскирование вывода и отсутствие debug-логов
Docker	Secret mount или временная передача	Ключ не попал в слой образа
Kubernetes	Secret → переменная или файл с ограниченными правами	RBAC и отсутствие вывода значения
SSH-сервер	--device-auth или API-ключ	Кто имеет доступ к хосту и терминалу
Локальный cron	Защищенное окружение пользователя	Права файла и окружение процесса

Для повторяемых пайплайнов полезно разделять этапы: сначала получить секрет из хранилища, затем выполнить codex login --with-api-key, после чего вызвать рабочую команду Codex. Если токен нужен только для одного задания, используйте временную среду и удаляйте её сразу после завершения.

Не сохраняйте каталог с авторизационными данными в публичный артефакт CI. Даже если сам API-ключ не виден в исходном YAML, сохранённый кэш или архив домашнего каталога может содержать credentials.

Безопасное обращение с токенами и секретами

Утечка токена происходит не только из-за публикации в Git. Частые причины — история команд, логи CI, скриншоты, резервные копии домашнего каталога, слишком широкие права на файлы и передача секрета в стороннюю команду через конвейер.

• Не вставляйте ключ в исходный код, README, issue, чат или команду запуска.
• Не передавайте API-ключ аргументом после codex login.
• Используйте отдельные ключи для локальной разработки, CI и production-задач.
• Ограничивайте права и срок жизни ключей, если такая возможность доступна в вашей организации.
• Регулярно отзывайте неиспользуемые ключи.
• Проверяйте журналы после настройки автоматизации.

Ошибка	Чем опасна	Безопасная замена
Ключ в команде	Попадание в history и список процессов	Передача через stdin
Ключ в .env в Git	Публикация во всей истории репозитория	Secret manager и исключение файла из Git
Ключ в Dockerfile	Остаётся в слоях образа	Секрет во время запуска
Общий ключ команды	Нельзя определить источник утечки	Персональные или ролевые ключи
Открытый debug-лог	Секрет виден в CI	Маскирование и отключение трассировки

Если ключ оказался в публичном репозитории, недостаточно просто удалить строку и сделать новый commit. Старое значение останется в истории, форках, кэшах и возможных копиях. Сначала отзовите ключ у провайдера, затем очистите историю и проверьте логи использования.

Что делать при подозрении на утечку

Порядок действий должен быть быстрым и последовательным. Чем дольше скомпрометированный ключ действует, тем выше вероятность несанкционированных запросов и расходов.

1. Немедленно отозвать или деактивировать скомпрометированный ключ.
2. Создать новый ключ с минимально необходимыми правами.
3. Заменить значение в secret manager и CI/CD.
4. Проверить историю Git, логи и артефакты.
5. Проверить активность аккаунта и расходы.
6. Повторно выполнить codex login --with-api-key только в очищенной среде.

Проверка состояния авторизации и выход

Команда codex login status — первый инструмент диагностики. Она позволяет проверить, обнаружены ли данные входа, не пытаясь сразу запускать полноценную задачу Codex.

Симптом	Что проверить	Следующий шаг
Авторизация отсутствует	codex login status	Запустить codex login
Старая учётная запись	Текущий профиль и окружение	codex logout, затем новый вход
Неверный API-ключ	Источник переменной и срок действия ключа	Создать или выбрать действующий ключ
Команда не знает параметр	codex login --help	Проверить версию CLI
Нет доступа к сервису	Сеть, прокси и DNS	Исправить соединение, а не повторять вход бесконечно

Команда codex logout предназначена для удаления сохранённых данных авторизации из текущей среды. Её стоит использовать перед передачей компьютера другому человеку, удалением временного окружения или переключением между аккаунтами.

Выход из Codex CLI не обязательно отзывает сам API-ключ на стороне сервиса. Если ключ был скомпрометирован, его нужно отдельно отозвать или удалить в панели управления API.

Типичные ошибки и их исправление

Ошибки при входе часто выглядят одинаково, хотя причины различаются. Правильная диагностика начинается с определения режима: браузерный вход, устройство или API-ключ.

Сообщение или ситуация	Вероятная причина	Решение
Браузер не открылся	Нет GUI или системный обработчик ссылок недоступен	Скопировать URL вручную или использовать device flow
Неизвестный параметр	Старая версия CLI	Проверить codex login --help и обновить CLI
API-ключ не принимается	Неверное значение, пробелы, отозванный ключ	Проверить секрет и передать его через stdin
Статус не показывает вход	Другая домашняя директория или контейнер	Проверить пользователя и окружение процесса
Работает локально, но не в CI	Секрет не доступен job или замаскирован неправильно	Проверить настройки секретов и права job
Вход зависает	Проблема сети, прокси или callback	Проверить соединение и выбрать удалённый способ входа

Не стоит многократно запускать авторизацию наугад. Сначала проверьте версию, локальную справку, сетевое соединение и способ хранения credentials. Повторные попытки не исправят неправильно переданный stdin или отсутствующий секрет в CI.

Как отличить проблему авторизации от проблемы окружения

Если codex login status подтверждает вход, но рабочая команда всё равно завершается ошибкой, причина может находиться за пределами авторизации. Например, сервис может быть недоступен, выбранная модель — недоступна для аккаунта, а рабочая директория — не иметь нужных прав.

$ codex login status
Authenticated: yes

$ codex exec "проверить проект"
Ошибка: сервис недоступен или запрос отклонён.
Вывод: авторизация есть, нужно проверять сеть, модель или права.

Рекомендации для разных сценариев

Один способ входа не является лучшим для всех ситуаций. Выбор зависит от наличия браузера, продолжительности работы среды, количества пользователей и требований к автоматизации.

Сценарий	Лучший выбор	Чего избегать
Личная разработка на ноутбуке	codex login	Постоянно хранить API-ключ в shell-профиле
Одноразовый удалённый сервер	--device-auth или временный API-ключ	Оставлять credentials после завершения работы
Долгоживущий CI-агент	Секретное хранилище и stdin	Запекать ключ в образ агента
Командный проект	Раздельные роли и персональные доступы	Один общий ключ для всех разработчиков
Тестовый контейнер	Временный секрет на время job	Коммитить файл credentials в образ

Для обычного пользователя оптимальна последовательность codex login → подтверждение в браузере → codex login status. Для автоматизации — secret manager → stdin → проверка кода завершения. Для удалённой интерактивной машины — device flow, если он присутствует в локальной версии CLI.

Главное правило простое: выбирайте способ, который соответствует среде, и не смешивайте личную браузерную сессию с машинной автоматизацией без необходимости. Такой подход облегчает отзыв доступа, расследование ошибок и контроль расходов.

Краткий чек-лист перед использованием

Перед запуском Codex в новом окружении достаточно пройти несколько проверок. Они занимают меньше минуты, но предотвращают большинство типичных проблем.

• Установлена поддерживаемая версия Codex CLI.
• Команда codex login --help показывает нужный способ авторизации.
• Для локальной работы выбран правильный аккаунт ChatGPT.
• Для автоматизации API-ключ хранится в secret manager, а не в репозитории.
• Ключ передаётся через --with-api-key и стандартный ввод.
• В логах отключён вывод секретных переменных.
• Состояние проверено командой codex login status.
• После работы во временной среде выполнен codex logout или среда удалена.

Команда codex login сама по себе проста, но правильный способ её применения зависит от контекста. Браузерный вход удобен человеку, API-ключ через stdin — автоматизации, device flow — удалённому терминалу, а codex login status помогает быстро понять, действительно ли среда готова к работе.

Если соблюдать базовые правила — не передавать секреты в аргументах, не сохранять их в репозитории, проверять локальную справку и разделять личные и машинные доступы, — авторизация в Codex CLI остаётся предсказуемой и безопасной как на рабочем компьютере, так и в серверной инфраструктуре.