Codex не входит в систему или не загружается

Если Codex останавливается на экране входа, сообщает, что не может загрузить требования входа, или после настройки opencodex все запросы моделей завершаются ошибкой, вероятнее всего Codex всё ещё направлен на прокси opencodex, который сейчас не работает. Об этом сообщалось в #5261.

Почему это происходит

При стандартной настройке loopback opencodex не создаёт для Codex отдельного провайдера. Он направляет встроенный провайдер Codex openai на прокси, записывая корневое переопределение в $CODEX_HOME/config.toml (%USERPROFILE%\.codex на Windows):

model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
# Auto-injected by opencodex (undo: ocx restore)
openai_base_url = "http://127.0.0.1:10100/v1"
# Auto-injected by opencodex (undo: ocx restore)
experimental_realtime_ws_base_url = "http://127.0.0.1:10100/v1"

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

Прокси может отсутствовать по обычным причинам. Подключение интеграции Codex не устанавливает фоновый сервис: для этого нужна отдельная команда ocx service install. Поэтому после перезагрузки прокси может не запуститься. Зарегистрированная задача Windows запускается при входе пользователя, а не при загрузке ОС; она также может быть отключена, не запуститься или уступить порт другому процессу.

Как снова запустить Codex

Выберите нужный результат. Оба варианта безопасны при остановленном прокси.

Вернуть Codex к собственному аккаунту и эндпоинтам:

ocx restore

Команда убирает добавленную маршрутизацию, переопределение realtime и указатель на каталог opencodex. Для неё не нужны работающий прокси, сессия дашборда или сеть. После этого Codex входит и работает обычным образом. Когда снова понадобится opencodex, ocx restore back направит Codex на прокси.

Либо вновь запустить прокси:

ocx start
ocx service install   # keep it running across restarts

ocx status показывает, отвечает ли прокси и направлен ли через него Codex. ocx doctor подробнее объясняет состояние и рекомендуемое исправление.

Если ocx недоступен

Маршрутизацию можно отменить вручную. Откройте $CODEX_HOME/config.toml и удалите три строки: openai_base_url, experimental_realtime_ws_base_url и любую строку model_catalog_json, заканчивающуюся на opencodex-catalog.json. Вместе с первыми двумя удалите комментарий # Auto-injected by opencodex, стоящий непосредственно над каждой из них.

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

Удаляйте строку model_catalog_json вместе с маршрутизацией, а не отдельно. Если model_catalog_json указывает на несуществующий файл, Codex вообще не может загрузить конфигурацию; это выглядит как та же блокировка, но имеет другую причину.

Аккаунты не добавляются или не отображаются

Ошибки добавления аккаунтов в пул и отсутствие добавленных аккаунтов в списке отличаются от описанной выше блокировки, даже если происходят в одной сессии. Пул обслуживает API управления прокси, поэтому и сценарий ocx account login openai, и список дашборда требуют работающего прокси. Браузерный вход также возвращается на фиксированный адрес http://localhost:1455/auth/callback, который нельзя перенести на другой порт. Если порт 1455 занят или браузер не запускается, используйте вход через устройство:

ocx account login openai --device

Подробнее о добавляемых настройках и выборе маршрута см. в разделе Интеграция Codex.