Codex account/read failed during TUI bootstrap: причина в хвосте

Если codex печатает одну строку и выходит, не показав интерфейс, выглядит это так:

Error: account/read failed during TUI bootstrap: account/read failed: workspace routing discovery failed (code -32603)

Всё до второго account/read failed: одинаково во всех случаях: интерактивный Codex при старте запросил у фонового сервера данные аккаунта (account/read), а сервер не ответил. Код -32603 — это «internal error» протокола JSON-RPC, такой же общий, как «что-то пошло не так»; это не HTTP-статус и не причина. Причина — в хвосте, и от него зависит, что делать:

• workspace routing discovery failed и workspace routing discovery timed out — чаще всего состояние или версия общего фонового сервера (daemon), реже прокси и сеть. В отчётах с 9 по 15 октября 2026 года ошибку снимал codex app-server daemon restart или обновление сервера до версии CLI.
• failed to load workspace requirements — хвост, по которому ответов меньше всего: в одном отчёте под ним прятался отозванный токен ChatGPT, а на 0.163.0 он всё ещё воспроизводится 17 октября, причём выход и повторный вход не помогли.
• workspace routing discovery unauthorized (401) — токен больше не принимается после изменений в аккаунте; помогал повторный вход на той машине, где лежат учётные данные, и завершение старого процесса codex app-server.
• duplicate workspace in routing discovery — проблема на стороне аккаунта (два одинаковых рабочих пространства Personal); исправления, доступного пользователю, нет.
• plan type is required for chatgpt authentication (code -32600) — учётные данные не от официального входа ChatGPT или смешанный вход; codex logout, затем один способ входа.

Ошибка не воспроизводилась, а исправления ниже не проверялись на практике: на локальной установке codex-cli 0.163.0-alpha.10.2 запускались только три команды диагностики — codex login status, codex doctor --summary --no-color и codex app-server daemon version, их вывод приведён как образец. Каждое исправление в тексте — сообщение пользователя с датой и номером обсуждения на GitHub или на форуме разработчиков OpenAI, а не результат собственной проверки. Официального разбора причин у OpenAI по состоянию на 17 октября 2026 года нет: документация Codex не упоминает ни account/read, ни workspace routing.

Если codex login status при этом отвечает Logged in using ChatGPT, а codex exec работает — это не противоречие, а подсказка: падает именно обязательный шаг старта интерфейса. Почему так, разобрано в разделе про codex exec ниже.

Что значит account/read failed during TUI bootstrap и код -32603

Интерактивный интерфейс Codex (TUI) не ходит к серверам OpenAI напрямую: он подключается к локальному процессу app-server и перед показом экрана делает несколько обязательных запросов. Один из них — account/read: «под каким аккаунтом работаем». Если app-server возвращает ошибку, TUI оборачивает её в account/read failed during TUI bootstrap: … и завершает работу. Тот же шаблон есть у шагов model/list, configRequirements/read, thread/start и thread/fork — это другие ошибки старта со своими обсуждениями; все обёртки лежат в файле codex-rs/tui/src/app_server_session.rs репозитория Codex.

Что происходит внутри account/read при входе через ChatGPT. App-server выполняет workspace routing discovery: спрашивает у бэкенда ChatGPT (accounts/check), к какому рабочему пространству и серверу относить этот аккаунт, и загружает набор требований пространства (workspace requirements) из облачной конфигурации. Рабочее пространство (workspace) здесь — пространство ChatGPT, личное или организации, которое выбирают при входе, а не папка проекта и не workspace VS Code. Весь запрос ограничен таймаутом в 15 секунд; истёк — хвост workspace routing discovery timed out. Ошибки маршрутизации app-server возвращает как JSON-RPC internal_error, то есть -32603; недопустимое состояние аккаунта — как invalid_request, -32600. Это коды протокола, а не HTTP: 401 от бэкенда или 407 от прокси, если они были, спрятаны внутри хвоста или не показаны вовсе. Всё это читается в исходном коде маршрутизации рабочих пространств в репозитории Codex на ветке main; константа 15 секунд оттуда же, и обе полевые записи — 15 002 мс в журнале десктопного приложения (#49921) и 15,016 с в WSL2 (#51052) — с ней совпадают.

Хвостов в коде больше, чем встречается в поиске: кроме перечисленных во вступлении есть workspace routing requires a ChatGPT account id, account changed during workspace routing discovery, configuration changed during workspace routing discovery; retry account/read, workspace routing discovery missing backend origin и другие. У хвоста про requirements в текущем main появляется уточнение после двоеточия — cloud config: authentication failed (HTTP 401), cloud config: request timed out, cloud config: invalid bundle — а выпущенные 0.162.1 и 0.163.0 печатают его без причины (#54184 от 15 октября, тема сообщества от 17 октября). Если у вас после requirements стоит двоеточие и текст, сборка уже новее, и причина написана прямо в нём.

Почему одна первая строка с апреля означала разное. Первый отчёт (issue #17800 в репозитории Codex, 14 апреля 2026 года, 0.120.0) пришёл от пользователя API-ключа: строка была вообще без хвоста, а причиной оказалось сочетание requires_openai_auth = true у собственного провайдера с устаревшим кешем входа ChatGPT. С 0.157.0 (25 сентября 2026 года) интерактивный codex по умолчанию поднимает общий фоновый сервер, и октябрьские отчёты — в основном про его состояние и версию. Код ошибки один, пути к ней разные, поэтому диагностика начинается с хвоста, а не с кода.

Три проверки до исправления: login status, daemon version, doctor

Эти команды только читают состояние и ничего не меняют:

codex --version
codex login status
codex app-server daemon version
codex doctor --summary --no-color

Что ожидать от каждой.

• codex login status печатает способ входа: Logged in using ChatGPT или Logged in using an API key. По отчётам #47456 и #54184 это сообщение не означает, что сервер ещё принимает токен: в обоих случаях статус был «logged in», а бэкенд отвечал 401. Проверка полезна для другого — убедиться, что вход вообще есть и что он того типа, которого вы ждёте: при входе по API-ключу discovery не запускается (см. раздел про plan type).
• codex app-server daemon version при работающем фоновом сервере выводит JSON вида {"status":"running","backend":"pid","managedCodexVersion":"0.162.1","cliVersion":"0.162.1","appServerVersion":"0.162.1"} (пример из #52928, 15 октября 2026 года). Сравнивайте cliVersion и appServerVersion: расхождение (CLI 0.162.1 при сервере 0.160.0; CLI 0.162.0 при сервере 0.161.0) — отдельная ветка исправления. Если сервера нет, команда завершается ошибкой failed to connect to ~/.codex/app-server-control/app-server-control.sock … No such file or directory (os error 2) — это не ещё одна поломка, а знак, что общий сервер не запущен и Codex работает во встроенном режиме.
• codex doctor --summary --no-color показывает сгруппированные строки: websocket connected (HTTP 101 Switching Protocols) · 15s timeout, auth is configured, а в группе Background Server — app-server not running (ephemeral mode) либо «background server is running» с версией сервера. Полный codex doctor --json даёт обезличенный отчёт, где поле app-server version стоит рядом с codexVersion (в #52775 это 0.161.0 против 0.162.1). Автор принятого ответа на форуме OpenAI 9 октября нашёл расхождение версий именно через подробный отчёт doctor.

Подкоманды codex app-server daemon … и флаги doctor взяты из --help сборки 0.163.0-alpha.10.2. Официальная страница команд Codex CLI описывает codex doctor, codex login status, codex logout, флаг --no-daemon и команду /daemon, но подкоманды app-server daemon на ней отсутствуют — сверяйте их через codex app-server daemon --help своей версии.

Сводная таблица: хвост ошибки, причина и что помогало по отчётам

Ниже — хвосты, которые печатает код и которые встречаются в отчётах. Колонка «что помогало» — сообщения пользователей с датой; ни одно не подтверждено OpenAI.

Порядок действий, который не удаляет историю сессий

Удаление ~/.codex целиком — последний шаг, а не первый: вместе с каталогом уходят журналы и история сессий (об этом напомнили в #17800 ещё в мае). Порядок ниже идёт от действий, которые ничего не меняют, к тем, что меняют.

1. Три проверки выше. Запишите версию CLI, способ входа и версию фонового сервера, если он запущен.
2. Перезапуск или обновление фонового сервера. Если daemon version показал работающий сервер — codex app-server daemon restart. Если версии разошлись — codex app-server daemon update --from-cli --yes: по справке команда копирует и закрепляет пакет текущего CLI и «may interrupt running work». Конфигурация, учётные данные и история при этом не трогаются (автор принятого ответа на форуме OpenAI, 9 октября 2026 года). Другие окна Codex, подключённые к тому же серверу, перезапуск прервёт.
3. codex --no-daemon как проверка. Если так интерфейс открывается, причина в пути через общий сервер, и предыдущий шаг имеет смысл повторить; если падает и так — сервер не виноват, идите к входу и сети. Это обход, а не исправление: во встроенном режиме недоступны codex agents и удалённое управление. Тот же эффект даёт любой -c key=value — CLI печатает Running without the shared background server: command-line configuration overrides (-c, --enable, --disable, or --search) requires embedded mode. Поэтому -c log_dir=… из ранних отчётов «помогал» не из-за log_dir.
4. Повторный вход там, где лежат учётные данные. codex logout, затем codex login (на сервере без браузера — codex login --device-auth). После входа завершите старые процессы codex app-server и открытые окна Codex: по #54184 и #47456 они продолжали использовать отозванный токен, пока их не завершили.
5. Прокси и сеть. Переменные HTTP_PROXY, HTTPS_PROXY и NO_PROXY в той оболочке, из которой стартует codex, затем перезапуск фонового сервера, чтобы он получил новое окружение; проверка на 407 и на блокировку chatgpt.com — в разделе про прокси.
6. Конфигурация провайдера и способа входа. requires_openai_auth только без env_key; один способ входа; удаление ~/.codex/auth.json — теряется только вход.
7. Если хвост — duplicate workspace, шаги 2–6 ничего не изменят: это аккаунт, а не машина. Переходите к соответствующему разделу.

workspace routing discovery failed / timed out: перезапуск daemon

Эти два хвоста в октябрьских отчётах чаще всего связаны с общим фоновым сервером. Что это за процесс: с 0.157.0 (25 сентября 2026 года, запись «Enable automatic daemon startup by default» в заметках к выпуску Codex CLI 0.157.0) интерактивный codex запускает постоянный codex app-server --managed-daemon и рядом с ним процесс обновления codex app-server daemon pid-update-loop. По описанию в issue #48195 о фоновом сервере по умолчанию (25 сентября) пакет копируется в ~/.codex/packages/app-server-daemon/releases/…, и сервер работает из этой копии — поэтому его версия может отстать от версии CLI, которую вы только что обновили через npm; кроме того, сервер сохраняет окружение той сессии, которая его запустила, включая переменные прокси. Флаг daemon_auto_start виден в codex features list, но в официальном справочнике конфигурации не описан. Уведомление о разнице версий интерфейс показывает сам, пока включена настройка tui.show_server_version_notice (по умолчанию включена).

Что сообщали пользователи:

• Linux Mint, 0.162.0, вход через ChatGPT, локальный прокси (тема «Codex CLI 0.162.0 fails during TUI bootstrap» на форуме разработчиков OpenAI, 9 октября 2026 года, принятый ответ): workspace routing discovery failed после разрыва сети и перезагрузки; codex doctor показал CLI 0.162.0 при сервере 0.161.0; codex app-server daemon restart вернул запуск. Автор не смог сказать, что именно помогло — смена версии сервера или сброс устаревших настроек прокси в его процессе.
• Arch Linux, 0.162.1 (issue #52928 о сбое account/read через общий сервер, 15 октября): appServerVersion 0.160.0 при CLI 0.162.1; codex app-server daemon update --from-cli --yes поднял сервер до 0.162.1, после чего codex запустился.
• Linux, 0.162.1, HTTP-прокси (#52928, 15 октября): версии совпадали, curl к chatgpt.com/backend-api/wham/accounts/check отвечал 401 за 0,46 с (то есть сеть была в порядке), codex --no-daemon работал — помог обычный codex app-server daemon restart. Автор предполагает устаревшее состояние, унаследованные переменные прокси или зависшие соединения внутри долгоживущего процесса.
• Ubuntu в Docker, 0.156.1 и 0.162.1 (#52928, 10 октября): обычный codex падал за 1,63 с — то есть не по 15-секундному таймауту, — а codex --no-daemon с тем же прокси и входом запускался.
• #17800, 11 и 15 октября: двум пользователям помог codex app-server daemon restart, причём одному из них удаление auth.json и повторный вход перед этим не помогли.
• issue #48894 про Sign-in failed в расширении VS Code, 29 сентября, с подтверждениями 5 и 6 октября: pkill -f codex, проверка codex login status, снова codex.

Про -c log_dir и touch. В #48600 (27 сентября, 0.157.1, Windows и WSL) и issue #52775 про запуск 0.162.1 только с -c log_dir (10 октября, macOS) codex -c log_dir="$HOME/.codex/log" стартовал там, где обычный codex падал. Объяснение дал автор #52928: любой -c переводит CLI во встроенный режим, поэтому работает и -c model_reasoning_effort="medium", а log_dir на верхнем уровне config.toml не помогает. Одиночный отчёт от 15 октября в #52775 о том, что хватило touch ~/.codex/log/codex-tui.log, объяснения не имеет.

Тот же класс — долгоживущий сервер в плохом состоянии — виден и в issue #37971 об исчерпании файловых дескрипторов (август, 7 комментариев): там падал другой шаг старта, configRequirements/read, с текстом No file descriptors available (os error 24), а у сервера после восьми дней работы было открыто 1022 из 1024 дескрипторов; 0.162.0 подняла лимит управляемого сервера до 4096 (запись #51470). Перезапуск снимает и это.

WSL2 — отдельная история без решения: в issue #51052 о таймауте account/read в WSL2 (5 октября, 0.160.0) один и тот же аккаунт на Windows проходил account/read за 0,422 с, а в WSL2 упирался в 15,016 с и timed out; codex exec работал в обоих. Автор отмечает, что таймаут не говорит, какая стадия discovery зависла. С 0.162.0 для домашних каталогов WSL, смонтированных с Windows, автозапуск фонового сервера отключён, и Codex работает во встроенном режиме с предупреждением (запись #50555).

В 0.163.0 (15 октября 2026 года) появился перезапуск сервера командой /daemon прямо из интерфейса — но ей можно воспользоваться, только когда интерфейс открылся; при падении на старте остаётся codex app-server daemon restart из терминала. Отключить общий сервер совсем можно командой codex features disable daemon_auto_start или строкой daemon_auto_start = false в секции [features] файла config.toml — так пользователь в #48195 снял блокировку запуска на Windows 10; обе формы взяты из справки CLI и из отчёта, не из документации.

Прокси и сеть: переменные окружения, 407 и блокировка chatgpt.com

Если вы работаете через прокси или VPN, проверьте четыре вещи, каждая из которых встречалась в отчётах.

Переменные окружения, а не настройки приложения. На macOS десктопный Codex (issue #49921 о таймауте discovery без HTTP_PROXY, 1 октября 2026 года) при обычном запуске из Dock падал по таймауту discovery, а запросы /wham/usage и /settings/user возвращали HTTP 432 «Workspace routing is unavailable». Флаг Electron --proxy-server=… не помог; запуск того же приложения с HTTP_PROXY, HTTPS_PROXY и NO_PROXY в окружении — помог. Для CLI один пользователь (#52928, 12 октября) добился того же файлом ~/.codex/.env со строками http_proxy, https_proxy и no_proxy; этот файл в документации не описан. Пример для оболочки; вместо $PROXY_URL подставьте адрес, который слушает ваш прокси:

export HTTP_PROXY=$PROXY_URL
export HTTPS_PROXY=$PROXY_URL
codex app-server daemon restart
codex

Перезапуск сервера нужен потому, что по #48195 он сохраняет переменные той сессии, которая его запустила: сменили прокси в оболочке — сервер об этом не узнает, пока вы его не перезапустите.

Порт и тип прокси. В теме на форуме OpenAI от 9 октября прокси отвечал 407 Proxy Authentication Required, потому что в настройках стоял SOCKS-порт вместо HTTP-порта. Исправление порта убрало 407, но Codex заработал только после перезапуска фонового сервера. Проверить сам прокси можно так же, как автор: curl -I --proxy "$PROXY_URL" https://chatgpt.com — 407 означает проблему с прокси, а не с Codex.

Сеть, где закрыт chatgpt.com, но открыт openai.com. В issue #50211 про workspace routing discovery failed на macOS (комментарий от 16 октября) пользователь корпоративной сети вошёл в аккаунт успешно — вход идёт через *.openai.com, — а всё после входа падало, потому что chatgpt.com был заблокирован. Discovery ходит именно на chatgpt.com/backend-api/…, так что успешный codex login ничего не говорит о доступности этого домена.

Корпоративный TLS-перехват. По документации Codex по аутентификации поддерживается переменная CODEX_CA_CERTIFICATE с PEM-набором корневых сертификатов; если она не задана, используется SSL_CERT_FILE. Переменные HTTP_PROXY и HTTPS_PROXY на странице переменных окружения Codex не перечислены — они работают как общесистемная договорённость, а не как задокументированная настройка.

В 0.163.0 запросы discovery (accounts/check, config/bundle) при сетевой ошибке повторяются через системный прокси (запись #52702), но ответы 401, 403, 407, 429 и 503 повтор не запускают — неверный пароль прокси или блокировка домена этой правкой не лечатся.

failed to load workspace requirements: хвост без хорошего ответа

Это единственный хвост, для которого нет ни одного отчёта с воспроизводимым исправлением на текущей версии. Что известно по состоянию на 17 октября 2026 года.

• Под ним может скрываться отозванный токен. В issue #54184 о скрытом 401 token_revoked (15 октября, 0.162.1, macOS, вход через ChatGPT) каждый запрос к бэкенду возвращал 401 token_revoked («Encountered invalidated oauth token for user»), включая загрузку requirements, а интерфейс показывал общий -32603. Открытые TUI и фоновый сервер продолжали работать со старым токеном и после свежего codex login, пока автор не завершил их. Поэтому для этого хвоста порядок такой: codex logout, codex login, затем codex app-server daemon stop или pkill -f 'codex app-server', закрыть другие окна Codex, снова codex.
• Встроенный режим обходит его у части пользователей. В #52775 (issue от 10 октября, комментарий от 14 октября) codex -c log_dir="$HOME/.codex/log" запускался при этом хвосте так же, как при timed out; механизм тот же — -c выключает общий сервер.
• На 0.163.0 он всё ещё воспроизводится. Тема на форуме разработчиков OpenAI от 17 октября 2026 года: codex-cli 0.163.0, macOS, ChatGPT Plus; codex login status отвечает Logged in using ChatGPT; выход и повторный вход не помогли; обновление с 0.162.1 до 0.163.0 не помогло; при этом codex exec "Reply only with READY" возвращает READY. Ответов в теме к 17 октября не было. Тот же хвост на 0.162.1 с вопросом «когда починят» публиковали и в X 13 октября — без ответа.

Если после повторного входа с завершением старых процессов и после --no-daemon ошибка остаётся — это открытое состояние, а не ошибка в ваших действиях. Сборки с уточнением после двоеточия (cloud config: authentication failed (HTTP 401), cloud config: request timed out) пока только в main; когда они выйдут, причина будет написана прямо в хвосте.

workspace routing discovery unauthorized (401): повторный вход

Этот хвост означает, что бэкенд ChatGPT отказал токену при discovery, хотя локально токен ещё выглядит действительным. Пример из issue #47456 об устаревшем входе на удалённом хосте (23 сентября 2026 года): удалённый Linux-хост без браузера, codex login status по-прежнему Logged in using ChatGPT, а app-server возвращает unauthorized (401). Сбой совпал с изменением прав аккаунта — автор называет это вероятным триггером, а не доказанной причиной. Помог немедленно codex login --device-auth именно на удалённом хосте, там, где лежал auth.json. Если Codex Desktop подключён к такому хосту по SSH, окно приложения может показывать не относящееся к делу сообщение про refresh token, хотя устаревшие учётные данные находятся на сервере.

Второй случай в той же теме (1 октября): после изменения плана codex login --device-auth прошёл успешно, а 401 остался — его держал долгоживущий процесс codex app-server, который не перечитал новый auth.json. pkill -f 'codex app-server' и обычный codex решили вопрос без удаления файлов.

Как войти на сервере без браузера — в разборе Вход в Codex на сервере без браузера: код, порт 1455, auth.json. Если падает уже сам codex login с 403, это другая ошибка: Codex token exchange failed 403: как восстановить вход. А 401 с текстом Incorrect API key появляется на запросах к модели уже после открытия интерфейса, и у него свой разбор: Codex: ошибка 401 Incorrect API key — сбой, вход или ключ.

duplicate workspace in routing discovery: решения у пользователя нет

Тупик, и честнее сказать об этом сразу. В issue #47034 о duplicate workspace после успешного входа (открыт 21 сентября 2026 года; Windows и macOS; CLI от 0.155.0-alpha до 0.160.0, десктоп 26.924) вход завершается Successfully logged in, а codex сразу падает с этим хвостом. Ключевое наблюдение двух пользователей (3 и 4 октября): в самом аккаунте ChatGPT отображаются два одинаковых пространства «Personal account / Personal» — в мобильном приложении и при входе на сайте, — хотя второго они не создавали. Судя по тексту ошибки, discovery получает два одинаковых пространства и не может выбрать одно.

Что пробовали без результата: codex logout и codex login, codex login --device-auth, чистый CODEX_HOME, forced_chatgpt_workspace_id с нужным идентификатором, переустановка, codex --no-daemon. codex exec тоже не работает — печатает Reconnecting... 2/5 и ту же фразу. Единственное, что работало у одного из авторов (4 октября), — расширение Codex для VS Code. Откат CLI на 0.154.0 через официальный установщик с параметром --release 0.154.0 помог одному пользователю 23 сентября и не помог другому 4 октября. Несколько человек открыли обращения в поддержку OpenAI; официального ответа в теме к 17 октября нет. Если это ваш хвост, тратить время на шаги с сервером и прокси не стоит — проверьте список пространств при входе на chatgpt.com и напишите в поддержку с выводом codex login status, codex doctor и файлом codex-login.log (их запросила поддержка у одного из авторов).

selected workspace missing from routing discovery: что проверить

Такой хвост есть в коде, но подробного отчёта с ним нет, поэтому дальше — предположение по смыслу строки, а не проверенный путь. Текст говорит, что сохранённый выбор рабочего пространства не нашёлся в списке, который вернул discovery: пространство удалили, вас из него исключили или выбор устарел. Разумные действия — codex logout, codex login и выбор пространства заново. Если в config.toml задан forced_chatgpt_workspace_id (в справочнике конфигурации Codex: «Limit ChatGPT logins to a specific workspace identifier»), проверьте, что идентификатор относится к пространству, которое у аккаунта ещё есть; при несовпадении учётных данных и ограничений Codex по документации выходит из аккаунта и завершается.

plan type is required (-32600): сторонний токен или смешанный вход

Хвост plan type is required for chatgpt authentication (code -32600) отличается кодом: -32600 — «invalid request», недопустимое состояние аккаунта, а не внутренняя ошибка. В исходном коде это ошибка MissingChatgptAccountDetails: учётные данные в режиме ChatGPT, у токена которых нет поля plan_type; email в токене может отсутствовать, plan_type — нет. Официальный вход через ChatGPT такой токен не выдаёт, поэтому на практике хвост появляется у тех, у кого в auth.json или в хранилище ключей лежит токен от стороннего сервиса, отредактированная копия, либо одновременно есть состояние ChatGPT и намерение работать по API-ключу. Это вывод из кода и из заголовков тем на китайских форумах (апрель и октябрь 2026 года), а не заявление OpenAI.

Исправление — оставить один способ входа:

codex logout
# либо официальный вход через ChatGPT:
codex login
# либо вход по API-ключу:
printenv OPENAI_API_KEY | codex login --with-api-key
codex login status

При входе по API-ключу discovery не выполняется вовсе: тест в репозитории Codex ожидает ноль обращений к accounts/check и пустой workspaceRouting, а с 0.163.0 фоновые чтения маршрутизации без входа ChatGPT пропускаются (запись #52635). Но ключ означает оплату по тарифам API вместо лимитов подписки — сравнение в Codex API-ключ или подписка ChatGPT: цена, лимиты и что выбрать.

Сюда же относится апрельская строка без хвоста. В #17800 (комментарий от 27 апреля) у пользователя был собственный провайдер с env_key и одновременно requires_openai_auth = true; при этом флаге TUI вызывает account/read и читает сохранённое состояние ChatGPT, а не ключ провайдера, — и устаревший кеш валил старт. Документация подтверждает: при requires_openai_auth = true Codex игнорирует env_key. Исправление — убрать флаг или поставить false:

[model_providers.my-provider]
base_url = "..."
wire_api = "responses"
env_key = "MY_PROVIDER_API_KEY"
# requires_openai_auth = false

Если нужно именно сбросить кеш входа, rm ~/.codex/auth.json с последующим codex login теряет только вход (#17800, 14 мая); удаление всего ~/.codex теряет и историю сессий. На сборках с фоновым сервером этого может не хватить: пользователь 11 октября после удаления auth.json всё равно получал ошибку, пока не перезапустил сервер. Настройка провайдеров целиком — в Custom provider в Codex: API-ключ, Base URL и config.toml.

Почему codex exec работает, а codex падает на старте

В двух отчётах (#51052, 5 октября; форум OpenAI, 17 октября) codex exec "…" возвращал ответ модели на той же машине и с тем же аккаунтом, где интерактивный codex падал. Это не противоречие. Обёртка … failed during TUI bootstrap живёт в коде интерфейса: TUI делает account/read обязательным шагом старта и завершается при первой ошибке, а неинтерактивный exec этот шаг в таком виде не проходит и доходит до запроса к модели — поэтому он остаётся рабочим обходом, когда нужно срочно что-то сделать. codex login status тоже не спорит с ошибкой: он сообщает способ входа по сохранённым учётным данным, а не ответ сервера на них.

Исключение — причины на стороне аккаунта: при duplicate workspace в #47034 падал и codex exec (Reconnecting... 2/5, затем та же фраза). Если exec у вас тоже не работает, причина не в интерфейсе и не в фоновом сервере.

Исправлено ли в 0.163.0: в релизах записи нет, requirements ещё падает

Нет — по состоянию на 17 октября 2026 года. Хронология выпусков Codex CLI: 0.157.0 (25 сентября) включила фоновый сервер по умолчанию и добавила «explicit recovery for incompatible background servers»; 0.161.0 (7 октября) — диагностику сервера в отчётах; 0.162.0 (8 октября) — отключение автозапуска для WSL с домашним каталогом на Windows и лимит дескрипторов 4096; 0.162.1 (9 октября); 0.163.0 (15 октября, Latest) — перезапуск через /daemon, повтор bootstrap-запросов через системный прокси, пропуск фоновых чтений маршрутизации без входа ChatGPT. Ни одна запись не заявляет исправление workspace routing discovery failed или timed out, а тема от 17 октября показывает хвост requirements на 0.163.0. 0.164.0-alpha.1–3 (16–17 октября) вышли с пустыми заметками. О той же строке на 0.162.1 в октябре писали также в r/codex и в LinkedIn. Обновление до 0.163.0 имеет смысл ради /daemon и прокси-повтора, но не как исправление этой строки; как обновить CLI на каждой платформе — в Как установить и настроить Codex CLI в Windows, macOS и Linux.

Sign-in failed: workspace routing discovery timed out в десктопе Codex

Десктопное приложение Codex и расширение для VS Code используют тот же discovery с тем же 15-секундным таймаутом, поэтому у них та же ошибка под другим названием: «Sign-in failed: workspace routing discovery timed out» или «Login failed: workspace routing discovery timed out». Отчёты: расширение VS Code на Ubuntu (#48894, 28 сентября 2026 года); приложение для macOS 26.924, которое просит войти «почти каждый день» и пишет в журнал account/read failed: workspace routing discovery failed (error code -32603) и Workspace routing is unavailable (issue #49443 о ежедневном повторном входе, 30 сентября); приложение для Windows с ежедневным повторным входом (#53236, 12 октября; #53520, 13 октября). Что помогало по отчётам — то же, что в CLI: переменные прокси в окружении приложения (#49921) и завершение оставшихся процессов — на macOS это был Dock Extra (ChatGPT.app), который не закрылся вместе с приложением (#49921, 15 октября). На Windows пользователь #47145 (22 сентября) связал таймаут со встроенной средой выполнения приложения: внешний CLI через CODEX_CLI_PATH вернул сохранение входа, но сделал недоступной память ChatGPT. Какие фоновые процессы Codex на Windows можно завершать — в Фоновые процессы Codex в Windows: что оставить, а что завершить. Если в VS Code вы видите не сообщение про вход, а 30-секундный экран «Codex could not start», это другая ошибка: Codex could not start в VS Code: причины для WSL, SSH и прокси.

Вопросы про account/read failed during TUI bootstrap

Прервёт ли codex app-server daemon restart другие окна Codex?

Может. Автор принятого ответа на форуме OpenAI (9 октября 2026 года) предупреждает, что перезапуск «может прервать активные сессии Codex»; справка codex app-server daemon update говорит «may interrupt running work»; /daemon в 0.163.0 перед перезапуском предупреждает о работе, которую прервёт. История сессий при этом не удаляется — прерывается текущий ход.

Сломает ли codex logout уже запущенные процессы Codex?

По отчётам — наоборот: они продолжают работать со старым токеном. В #54184 и #47456 фоновый сервер и открытые TUI после codex logout и нового codex login держали отозванный токен, пока их не завершили. Поэтому после повторного входа закройте окна Codex и выполните codex app-server daemon stop или restart.

Нужно ли удалять ~/.codex, как советовали в апреле?

Нет, не первым шагом. rm ~/.codex/auth.json сбрасывает только вход; удаление каталога целиком стирает историю сессий и журналы. В октябрьском отчёте (#17800, 11 октября) удаление auth.json и повторный вход не помогли — помог перезапуск фонового сервера. Апрельский совет относился к сборке 0.120.0, у которой фонового сервера ещё не было.

thread/start failed during TUI bootstrap — это та же ошибка?

Та же обёртка, другой шаг. thread/start, model/list, configRequirements/read и thread goal/set — отдельные запросы при старте, и у каждого свои обсуждения (например, #18064 от апреля 2026 года для thread/start). Разделы выше относятся к account/read; для остальных шагов смотрите хвост своей строки и обсуждение по нему.

Поможет ли вход по API-ключу вместо ChatGPT?

От этого класса ошибок — да: при входе по ключу discovery рабочего пространства не выполняется. Цена — оплата по тарифам API вместо лимитов подписки, а Codex cloud по документации требует входа через ChatGPT. Исключение — конфигурация с requires_openai_auth = true, при которой TUI всё равно читает состояние ChatGPT.