Вход в Codex на сервере без браузера: код, порт 1455, auth.json

На машине без браузера в Codex CLI входят одним из трёх способов, и все три описаны в документации OpenAI. Если под рукой есть любое другое устройство с браузером, запустите codex login --device-auth и введите одноразовый код на странице OpenAI. Если вы подключаетесь по SSH со своего компьютера, пробросьте порт 1455 и пройдите обычный вход в своём браузере. Если не подходит ни то ни другое, войдите на машине с браузером и перенесите на сервер файл ~/.codex/auth.json. Для CI и скриптов вход через ChatGPT обычно не нужен совсем: там работает API-ключ или токен доступа.

Команды ниже взяты из документации OpenAI по аутентификации Codex, тексты ошибок и пределы — из исходного кода Codex CLI 0.160.0 (стабильная версия по состоянию на 2 октября 2026 года). Часть поведения запускалась на практике, часть известна только по документации и коду, и эту границу стоит видеть до того, как вы начнёте.

Что запускалось на практике. Одноразовая облачная машина с Ubuntu 24.04, glibc 2.39, OpenSSH 9.6p1 и Codex CLI 0.160.0, 2 октября 2026 года:

• краткая запись 127.1 разрешается в IPv4-адрес петлевого интерфейса;
• настоящий проброс ssh -L с целью, записанной как 127.1, передаёт запросы слушателю на этом адресе;
• такой же проброс доходит до слушателя обратного вызова самого Codex: на запрос к /auth/callback без параметров авторизации через туннель пришёл ответ 400 Bad Request с текстом State mismatch, то есть ответил именно Codex и отклонил пустой запрос;
• при занятом порте 1455 команда codex login поднимает сервер входа на порту 1457;
• codex login --device-auth печатает приглашение с адресом страницы, одноразовым кодом и сроком 15 минут.

Что не делалось. Ни один из способов не доведён до завершённого входа: для этого нужны аккаунт и подтверждение в браузере, и ни то ни другое не использовалось. Поэтому страницы, которые браузер показывает после подтверждения, не наблюдались. Перенос auth.json на вторую машину, обновление и отзыв токенов на практике не проверялись — о них известно из документации и исходного кода. Системы с musl, например Alpine, не проверялись. Оба конца туннеля находились на одной машине, так что путь через реальную сеть между двумя хостами остался вне проверки.

Почему codex login не завершается на сервере без браузера

Обычный вход устроен так, что браузер должен вернуть результат на ту же машину, где запущен Codex. Команда codex login поднимает временный сервер на петлевом интерфейсе, печатает адрес страницы авторизации и ждёт, пока браузер после входа обратится к обратному вызову /auth/callback на порту 1455. В документации это описано одной фразой: после входа браузер возвращает учётные данные в Codex.

На сервере, к которому вы подключены по SSH, этот круг не замыкается. Браузера там нет, а если открыть напечатанный адрес на своём ноутбуке, то после авторизации браузер обратится к порту 1455 на ноутбуке, где его никто не слушает. Страница сообщит об ошибке соединения, а codex login на сервере продолжит ждать. То же происходит в контейнере, в WSL и в виртуальной машине, когда сетевые настройки не пропускают обращение к петлевому адресу.

Отдельного флага вроде --no-browser или выбора порта у команды нет. Справка версии 0.160.0 показывает три флага входа и одну подкоманду:

Старый флаг --api-key удалён: по исходному коду, команда с ним печатает подсказку передать ключ через конвейер и завершается с кодом 1. Сама codex login без флагов на сервере с Ubuntu 24.04 печатает строку «Starting local login server on» с именем петлевого хоста и портом 1455, затем «If your browser did not open, navigate to this URL to authenticate:» и адрес страницы авторизации на auth.openai.com. По исходному коду, тем же сообщением она подсказывает выход: на удалённой машине использовать codex login --device-auth.

Какой способ выбрать: код устройства, туннель, файл или ключ

Выбор определяют четыре вопроса: есть ли у вас другое устройство с браузером, можете ли вы изменить настройку безопасности в ChatGPT, работает ли проброс портов по SSH и кто будет запускать Codex — человек или автоматизация.

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

Вход по коду устройства: codex login --device-auth

Вход по коду устройства (device code authentication) не требует, чтобы браузер достучался до сервера: вы подтверждаете вход на странице OpenAI с любого устройства, а Codex сам опрашивает OpenAI и получает учётные данные. Поэтому браузер может быть на телефоне.

Порядок действий по документации:

1. Включите вход по коду устройства: для личного аккаунта — в настройках безопасности ChatGPT, для рабочего пространства — в разрешениях, которые задаёт администратор.
2. На сервере выполните команду или выберите в интерактивном окне первого запуска пункт Sign in with Device Code.
3. Откройте напечатанную ссылку в браузере, войдите в аккаунт и введите одноразовый код.

codex login --device-auth

Версия 0.160.0 на Ubuntu 24.04 печатает такое приглашение (сам код здесь скрыт; он не вводился, и вход на этом шаге остановлен):

Follow these steps to sign in with ChatGPT using device code authorization:

1. Open this link in your browser and sign in to your account
   https://auth.openai.com/codex/device

2. Enter this one-time code (expires in 15 minutes)
   CODE-REDACTED

Continue only if you started this login in Codex. If a website or another person gave you this code, cancel.

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

Три границы этого способа:

• Срок действия. Срок 15 минут указан в самом приглашении. По исходному коду, если код не введён за это время, команда завершается с сообщением device auth timed out after 15 minutes. Запустите её заново и получите новый код.
• Настройка аккаунта. Сотрудник OpenAI в обсуждении на GitHub указал, где находится переключатель: chatgpt.com/#settings/Security для личного аккаунта и chatgpt.com/admin/permissions для администратора рабочего пространства. Официального названия переключателя, его состояния по умолчанию и списка тарифов, где он есть, в документации нет. Название «Enable Codex Device Code Authorization» в разделе Security известно только со слов пользователей на GitHub; сам переключатель на практике не открывался.
• Рабочие пространства. Если администратор не разрешил вход по коду устройства, участник включить его сам не может. Пользователи сообщали о сообщении с просьбой обратиться к администратору рабочего пространства; в этом случае остаются туннель и перенос файла.

Флаг появился в стабильной версии 0.44.0 от 3 октября 2025 года, а публичная бета была объявлена 8 декабря 2025 года. Инструкции старше этих дат описывают только обходные пути. Если Codex на сервере давно не обновлялся, начните с обновления: установка и настройка Codex CLI в Windows, macOS и Linux разобраны отдельно.

Проброс порта 1455 по SSH: вход через браузер на своём компьютере

Туннель SSH замыкает тот самый круг, который рвётся при удалённой работе: обращение браузера к порту 1455 на вашем компьютере передаётся на петлевой интерфейс сервера, где ждёт Codex. Сам вход остаётся обычным, и настройку кода устройства менять не нужно.

Со своего компьютера откройте сессию с пробросом порта:

ssh -L 1455:127.1:1455 user@remote

В этой сессии выполните codex login и откройте напечатанный адрес в браузере на своём компьютере. По документации, после входа браузер обращается к порту 1455 локально, SSH передаёт запрос на сервер, и команда завершается.

В документации OpenAI цель туннеля записана именем петлевого хоста. Здесь та же цель записана как 127.1 — это стандартная краткая форма IPv4-адреса петлевого интерфейса. Разница имеет практический смысл: начиная с версии 0.158.0 от 28 сентября 2026 года сервер обратного вызова слушает только IPv4-адрес петлевого интерфейса, а имя петлевого хоста на некоторых системах сначала разрешается в IPv6-адрес. Явная IPv4-цель совпадает с тем, что принимает Codex.

На Linux эта запись наблюдалась в работе — Ubuntu 24.04, glibc 2.39, OpenSSH 9.6p1, Codex CLI 0.160.0:

• getent ahosts 127.1 возвращает IPv4-адрес петлевого интерфейса. Слушатель, привязанный только к этому адресу, отвечает на запрос к 127.1, а соединение с IPv6-адресом петлевого интерфейса отклоняется.
• Проброс ssh -L с целью 127.1 передал запрос такому слушателю, ответ — 200. Команда ssh -G показывает разобранный проброс как localforward 1455 [127.1]:1455.
• При запущенном codex login проброс с целью 127.1:1455 дошёл до слушателя обратного вызова Codex. Запрос к /auth/callback без параметров авторизации вернул через туннель то же, что и напрямую:

HTTP/1.1 400 Bad Request

State mismatch

Ответ State mismatch означает, что Codex получил запрос и отклонил его, потому что в нём нет параметра состояния OAuth. Это подтверждает, что запись цели доводит запрос до Codex, но не подтверждает завершённый вход: настоящий обратный вызов после авторизации в браузере через туннель не проходил. Оба конца туннеля были на одной машине; цель проброса в любом случае разрешается на стороне сервера, однако сетевой путь между двумя разными хостами остался непроверенным.

Системы с musl, например Alpine, не проверялись. Если на вашем сервере краткая запись не сработает, используйте форму из документации OpenAI.

Порт выбрать нельзя:

• Порт обратного вызова зашит в программу: 1455. Ни флага, ни ключа конфигурации для него нет — это видно в справке и в исходном коде. Параметр mcp_oauth_callback_port относится к авторизации MCP-серверов, а не к входу в Codex.
• При занятом порте 1455 Codex переходит на 1457. Это наблюдалось на Ubuntu 24.04: когда порт 1455 занимал другой процесс, codex login напечатал в строке «Starting local login server on» порт 1457. По истории изменений, переход появился в версии 0.128.0 от 30 апреля 2026 года. Документация запасной порт не упоминает.
• Если заняты оба, вход, по исходному коду, завершается ошибкой Port … is already in use.

Отсюда следствие, которого в документации нет: если Codex на сервере перешёл на 1457, туннель только для 1455 обратный вызов не получит. При запуске codex login печатает порт, на котором поднялся сервер входа, — пробрасывайте именно его. Чтобы не переподключаться, можно сразу пробросить оба порта. Это совет, а не проверенный приём: в документации такого варианта нет, и команда в таком виде не запускалась.

ssh -L 1455:127.1:1455 -L 1457:127.1:1457 user@remote

Порт 1455 должен быть свободен и на вашем компьютере. Если там уже запущен локальный codex login или другой процесс занял порт, ssh сообщит, что не может открыть проброс.

Про автоматический проброс портов в VS Code Remote-SSH и JetBrains Gateway официальных указаний нет. Сбои обратного вызова в WSL и Remote-SSH сотрудники OpenAI в обсуждениях на GitHub объясняли локальной сетевой конфигурацией — брандмауэром или VPN — и советовали перейти на код устройства.

Перенос auth.json с машины, где есть браузер

Если вход выполнен на машине с браузером, кэш учётных данных можно скопировать на сервер — документация описывает это как третий способ. Порядок: выполнить codex login на машине с браузером, убедиться, что файл ~/.codex/auth.json существует, и перенести его в ~/.codex/auth.json на сервере.

ssh user@remote 'mkdir -p ~/.codex'
scp ~/.codex/auth.json user@remote:~/.codex/auth.json

Вариант одной командой без scp:

ssh user@remote 'mkdir -p ~/.codex && cat > ~/.codex/auth.json' < ~/.codex/auth.json

Для контейнера Docker документация даёт такую последовательность:

CONTAINER_HOME=$(docker exec MY_CONTAINER printenv HOME)
docker exec MY_CONTAINER mkdir -p "$CONTAINER_HOME/.codex"
docker cp ~/.codex/auth.json MY_CONTAINER:"$CONTAINER_HOME/.codex/auth.json"

Способ работает при трёх условиях.

Учётные данные лежат в файле. Место хранения задаёт параметр cli_auth_credentials_store: file — файл auth.json в каталоге CODEX_HOME (по умолчанию ~/.codex), keyring — системное хранилище учётных данных, auto — хранилище при наличии, иначе файл, ephemeral — только память текущего процесса. Документация значение по умолчанию не называет; в исходном коде 0.160.0 это file на всех системах. Если на исходной машине выбрано системное хранилище, файла не будет и копировать нечего. Если вы задаёте CODEX_HOME на сервере сами, каталог должен существовать заранее.

С файлом обращаются как с паролем. Формулировка документации: в нём токены доступа, его нельзя коммитить, вставлять в тикеты и пересылать в чатах. В файле находятся поля auth_mode, OPENAI_API_KEY, tokens (внутри — id_token, access_token, refresh_token, account_id) и last_refresh. Это не один токен, а целый кэш, включая токен обновления, который Codex со временем меняет. После копирования имеет смысл ограничить права командой chmod 600 ~/.codex/auth.json; это обычная практика, в документации её нет.

На исходной машине вы после этого не входите заново и не выходите. С середины июня 2026 года каждый codex login — и через браузер, и по коду устройства — сначала отзывает и удаляет учётные данные, уже сохранённые на этой машине (PR #27674); codex logout тоже отправляет запрос на отзыв. Из этого следует вывод, которого в документации нет и который на практике не проверялся: копия на сервере содержит тот же токен обновления, поэтому повторный вход или выход на исходной машине может сделать её недействительной. По исходному коду, отозванный токен обновления даёт сообщение «Your access token could not be refreshed because your refresh token was revoked. Please log out and sign in again.»

Можно ли использовать один auth.json на двух серверах

Нет: документация OpenAI требует отдельный файл на каждую машину. В руководстве по CI сказано использовать один auth.json на один раннер или на один последовательный поток задач и не делить один файл между параллельными задачами и несколькими машинами.

Причина в обновлении токенов. Для входа через ChatGPT Codex обновляет токены автоматически во время работы: по руководству, файл обновляется и перезаписывается, когда last_refresh старше примерно 8 дней, а также после ответа 401. При обновлении токен обновления заменяется новым. Машина, обновившаяся первой, получает новый токен, а у второй остаётся прежний. Сотрудник OpenAI в обсуждении #10332 пояснял, что прежний токен обновления можно повторно использовать в течение ограниченного окна — порядка часа, — после чего он становится недействительным навсегда. Поэтому две машины с одним файлом какое-то время работают обе, а затем одна выпадает.

Практическое правило: на каждый сервер — свой вход. Для второго сервера выполните вход по коду устройства или через туннель прямо на нём, а не копируйте файл с первого.

CI и скрипты: API-ключ, CODEX_API_KEY или токен доступа

Автоматизации вход через ChatGPT обычно не нужен: документация рекомендует для CI/CD аутентификацию по API-ключу. Браузер для неё не требуется:

printenv OPENAI_API_KEY | codex login --with-api-key

Это не способ пользоваться подпиской ChatGPT без браузера, а другой способ оплаты. Работа по ключу оплачивается по стандартным тарифам API, а не из лимитов тарифа ChatGPT; функции, которым нужен доступ к рабочему пространству ChatGPT или облачным сервисам, ограничены или недоступны, а Codex cloud требует входа через ChatGPT. Как выбирать между двумя вариантами оплаты, разобрано в материале «Codex API-ключ или подписка ChatGPT: какой маршрут выбрать».

Для неинтерактивного запуска сохранять вход не обязательно:

• codex exec по умолчанию использует сохранённую аутентификацию CLI, так что любой из трёх способов выше подходит и для него.
• Переменную CODEX_API_KEY читают codex exec, codex review, TypeScript SDK и codex exec-server --remote. Интерактивный codex её не читает.
• Обычная OPENAI_API_KEY в окружении в таблице переменных документации как учётные данные для codex exec не значится.

В управляемых рабочих пространствах есть ещё токены доступа Codex для доверенных неинтерактивных сценариев. Их создают на странице chatgpt.com/admin/access-tokens после того, как владелец рабочего пространства включит разрешение; срок действия выбирается из 7, 30, 60 или 90 дней, минимум — 1 день. Владельцы и администраторы могут отозвать любой токен, участники — только свои.

printenv CODEX_ACCESS_TOKEN | codex login --with-access-token

О том, кому токены доступны, страницы OpenAI говорят по-разному: страница аутентификации называет рабочие пространства ChatGPT Enterprise, а страница о токенах доступа — Business и Enterprise.

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

Проверка входа: codex login status и журнал codex-login.log

Результат любого способа проверяется одной командой:

codex login status

При успешном входе через ChatGPT она печатает Logged in using ChatGPT, при ключе — Logged in using an API key с замаскированным ключом, при токене доступа — Logged in using access token; код завершения, по документации, равен 0. Строки для успешного входа взяты из исходного кода и на практике не наблюдались. Без учётных данных версия 0.160.0 выводит Not logged in и завершается с кодом 1 — это наблюдалось на Ubuntu 24.04 и удобно для проверки в скриптах.

Если вход не проходит, откройте журнал: запуски codex login пишут в файл codex-login.log в каталоге журналов, по умолчанию ~/.codex/log/codex-login.log.

За корпоративным TLS-прокси или с собственным корневым сертификатом задайте путь к нему до входа:

export CODEX_CA_CERTIFICATE=/path/to/corporate-root-ca.pem
codex login

Если переменная не задана, Codex использует SSL_CERT_FILE; настройка действует на вход, HTTPS и WebSocket.

Сообщение в терминале при входе и что с ним делать

Тексты ниже — из исходного кода Codex CLI 0.160.0; на практике из них наблюдалась только строка Not logged in. Сообщение о рабочем пространстве известно только по словам пользователей, а первая строка таблицы — вывод из устройства входа, а не наблюдение.

Ограничение forced_login_method работает жёстко: при несовпадении способа Codex, по документации, разлогинивает пользователя и завершает работу. Если процесс использует идентификацию рабочей нагрузки (workload identity), команды codex login и codex logout отклоняются.

Две соседние ошибки имеют другие причины и разобраны отдельно: когда вход доходит до конца, но заканчивается отказом 403, — в материале «Ошибка обмена токена Codex 403: вход, прокси, регион и кэш»; когда вход выполнен, а запросы возвращают 401, — в материале «Codex: ошибка 401 Incorrect API key — сбой, вход или ключ».