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

> Codex CLI на сервере без браузера: вход по коду устройства, проброс порта 1455 по SSH или перенос auth.json. Для CI вместо входа — ключ или токен доступа.

- URL: https://blog.laozhang.ai/ru/posts/codex-headless-login
- Published: 2026-10-02
- Updated: 2026-10-02
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ru/about)
- Category: Инструменты разработки ИИ
- Tags: OpenAI Codex, Codex CLI, codex login, SSH, вход по коду устройства, auth.json

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

Команды ниже взяты из [документации OpenAI по аутентификации Codex](https://learn.chatgpt.com/docs/auth#login-on-headless-devices), тексты ошибок и пределы — из исходного кода 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 минут.

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

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

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

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

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

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

| Что | Назначение |
|---|---|
| `--device-auth` | вход по коду устройства; в справке у флага нет описания |
| `--with-api-key` | читает API-ключ из стандартного ввода |
| `--with-access-token` | читает токен доступа из стандартного ввода |
| `status` | показывает, каким способом выполнен вход |

Старый флаг `--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 — человек или автоматизация.

| Ситуация | Способ | Что нужно | Главное ограничение |
|---|---|---|---|
| Есть телефон или ноутбук с браузером, настройку ChatGPT можно включить | `codex login --device-auth` | включённый вход по коду устройства в настройках безопасности; проверьте его до начала входа | код действует 15 минут; в рабочем пространстве решает администратор |
| Подключение по SSH со своего компьютера, проброс портов разрешён | `ssh -L` и обычный `codex login` | браузер на своём компьютере | порт 1455, при занятом — 1457; другой порт задать нельзя |
| Проброс закрыт, код устройства недоступен | перенос `~/.codex/auth.json` | вход на любой машине с браузером | один файл — одна машина; повторный вход на исходной машине отзывает учётные данные |
| CI, cron, скрипты без человека | API-ключ, `CODEX_API_KEY` или токен доступа | ключ платформы OpenAI либо управляемое рабочее пространство | оплата по тарифам API, часть функций недоступна |

![Схема выбора способа входа в Codex CLI по ситуации: код устройства, проброс порта по SSH, перенос auth.json, API-ключ или токен доступа для CI](https://blog.laozhang.ai/posts/ru/codex-headless-login/img/login-method-by-situation.webp)

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

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

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

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

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

```bash
codex login --device-auth
```

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

```text
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, а затем страницу согласия с неактивной кнопкой продолжения. Поля для кода на ней не было; вместо него стояло сообщение: включите в настройках безопасности ChatGPT вход по коду устройства для Codex, Excel, PowerPoint и Word и снова запустите `codex login --device-auth`. Интерфейс был на упрощённом китайском, поэтому сообщение передано по смыслу, а не дословно. На этом попытка остановлена: переключатель не включался, код не вводился, вход не завершён.

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

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

- **Срок действия.** Срок 15 минут указан в самом приглашении. По исходному коду, если код не введён за это время, команда завершается с сообщением `device auth timed out after 15 minutes`. Запустите её заново и получите новый код.
- **Настройка аккаунта.** Сотрудник OpenAI в [обсуждении на GitHub](https://github.com/openai/codex/issues/2798) указал, где находится переключатель: `chatgpt.com/#settings/Security` для личного аккаунта и `chatgpt.com/admin/permissions` для администратора рабочего пространства. На личном аккаунте первая ссылка открывает страницу безопасности аккаунта и входа по адресу `chatgpt.com/settings/security`. Переключатель стоит на ней последним, в группе настроек безопасности приложений. В его подписи названы Codex, Excel, PowerPoint и Word и вход по коду устройства; пояснение под ним говорит, что коды устройства нужны для входа в Codex в удалённых окружениях и окружениях без браузера и для входа в ChatGPT внутри Excel, PowerPoint и Word, и предупреждает, что такой код могут выманить мошенники и передавать его никому нельзя. Подпись наблюдалась в интерфейсе на упрощённом китайском, так что точная формулировка на других языках интерфейса может отличаться; в более ранних сообщениях пользователей на GitHub пункт назывался «Enable Codex Device Code Authorization». На аккаунте, проверенном 2 октября 2026 года, переключатель был выключен; менял ли его кто-то раньше, неизвестно. Это наблюдение на одном аккаунте: документация значение по умолчанию и список тарифов, где настройка есть, не называет. Поэтому проверьте переключатель до начала входа. Сам он при этом только просматривался и не включался.
- **Рабочие пространства.** Если администратор не разрешил вход по коду устройства, участник включить его сам не может. Пользователи сообщали о сообщении с просьбой обратиться к администратору рабочего пространства; в этом случае остаются туннель и перенос файла.

Флаг появился в стабильной версии 0.44.0 от 3 октября 2025 года, а публичная бета была объявлена 8 декабря 2025 года. Инструкции старше этих дат описывают только обходные пути. Если Codex на сервере давно не обновлялся, начните с обновления: [установка и настройка Codex CLI в Windows, macOS и Linux](https://blog.laozhang.ai/ru/posts/codex-cli-install) разобраны отдельно.

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

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

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

```bash
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` без параметров авторизации вернул через туннель то же, что и напрямую:

```text
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` печатает порт, на котором поднялся сервер входа, — пробрасывайте именно его. Чтобы не переподключаться, можно сразу пробросить оба порта. Это совет, а не проверенный приём: в документации такого варианта нет, и команда в таком виде не запускалась.

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

![Путь обратного вызова через туннель SSH: браузер на своём компьютере, порт 1455, петлевой интерфейс сервера 127.1 и codex login, с запасным портом 1457](https://blog.laozhang.ai/posts/ru/codex-headless-login/img/ssh-tunnel-callback-path.webp)

Порт 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` на сервере.

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

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

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

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

```bash
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](https://github.com/openai/codex/pull/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](https://github.com/openai/codex/issues/10332) пояснял, что прежний токен обновления можно повторно использовать в течение ограниченного окна — порядка часа, — после чего он становится недействительным навсегда. Поэтому две машины с одним файлом какое-то время работают обе, а затем одна выпадает.

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

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

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

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

Это не способ пользоваться подпиской ChatGPT без браузера, а другой способ оплаты. Работа по ключу оплачивается по стандартным тарифам API, а не из лимитов тарифа ChatGPT; функции, которым нужен доступ к рабочему пространству ChatGPT или облачным сервисам, ограничены или недоступны, а Codex cloud требует входа через ChatGPT. Как выбирать между двумя вариантами оплаты, разобрано в материале [«Codex API-ключ или подписка ChatGPT: какой маршрут выбрать»](https://blog.laozhang.ai/ru/posts/codex-api-key-vs-subscription).

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

- `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 день. Владельцы и администраторы могут отозвать любой токен, участники — только свои.

```bash
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`

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

```bash
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-прокси или с собственным корневым сертификатом задайте путь к нему до входа:

```bash
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`. Сообщение о выключенной настройке наблюдалось в браузере на одном личном аккаунте и передано по смыслу. Сообщение о рабочем пространстве известно только по словам пользователей, а первая строка таблицы — вывод из устройства входа, а не наблюдение.

| Сообщение или симптом | Что произошло | Действие |
|---|---|---|
| Браузер после входа показывает ошибку соединения, `codex login` ждёт | обратный вызов ушёл на порт 1455 вашего компьютера, а не сервера | открыть туннель `ssh -L` или перейти на `--device-auth` |
| `device auth timed out after 15 minutes` | код не введён за 15 минут | запустить `codex login --device-auth` заново |
| `device code login is not enabled for this Codex server` | конечная точка кода устройства ответила 404 | использовать вход через браузер по туннелю; проверить адрес сервера, если он переопределён |
| Страница в браузере не показывает поле для кода и просит включить вход по коду устройства для Codex, Excel, PowerPoint и Word | настройка выключена в аккаунте (наблюдалось на одном личном аккаунте) | включить переключатель внизу страницы безопасности аккаунта и запустить `codex login --device-auth` снова |
| Просьба обратиться к администратору рабочего пространства (по сообщениям пользователей) | вход по коду устройства запрещён в рабочем пространстве | попросить администратора включить или взять туннель либо перенос файла |
| `Port … is already in use` | заняты и 1455, и 1457 | завершить прежний `codex login` или процесс, занявший порты |
| `…your refresh token was revoked. Please log out and sign in again.` | токен обновления отозван, например повторным входом на исходной машине | войти на сервере заново |
| `ChatGPT login is disabled. Use API key login instead.` | администратор задал `forced_login_method = "api"` | войти по API-ключу |
| `API key login is disabled. Use ChatGPT login instead.` | администратор задал `forced_login_method = "chatgpt"` | войти через ChatGPT одним из трёх способов |
| `Not logged in` после копирования файла | файл лежит не в том `CODEX_HOME` или не был создан на исходной машине | проверить путь `~/.codex/auth.json` и значение `cli_auth_credentials_store` |

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

Две соседние ошибки имеют другие причины и разобраны отдельно: когда вход доходит до конца, но заканчивается отказом 403, — в материале [«Ошибка обмена токена Codex 403: вход, прокси, регион и кэш»](https://blog.laozhang.ai/ru/posts/codex-token-exchange-failed-403); когда вход выполнен, а запросы возвращают 401, — в материале [«Codex: ошибка 401 Incorrect API key — сбой, вход или ключ»](https://blog.laozhang.ai/ru/posts/codex-401-incorrect-api-key).