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

> Смотрите хвост после второго «account/read failed:»: при failed и timed out по отчётам помогал перезапуск фонового сервера Codex, при 401 — повторный вход.

- URL: https://blog.laozhang.ai/ru/posts/codex-account-read-failed-tui-bootstrap
- Published: 2026-10-17
- Updated: 2026-10-17
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ru/about)
- Topic: Инструменты разработчика
- Tags: OpenAI Codex, Codex CLI, account/read failed, workspace routing discovery, app-server daemon, вход через ChatGPT, диагностика

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

```text
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](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs) на ветке `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](https://github.com/openai/codex/issues/17800), 14 апреля 2026 года, 0.120.0) пришёл от пользователя API-ключа: строка была вообще без хвоста, а причиной оказалось сочетание `requires_openai_auth = true` у собственного провайдера с устаревшим кешем входа ChatGPT. С 0.157.0 (25 сентября 2026 года) интерактивный `codex` по умолчанию поднимает общий фоновый сервер, и октябрьские отчёты — в основном про его состояние и версию. Код ошибки один, пути к ней разные, поэтому диагностика начинается с хвоста, а не с кода.

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

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

```bash
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 и сравнение cliVersion с appServerVersion: при совпадении перезапуск фонового сервера, при расхождении update --from-cli, при ошибке сокета встроенный режим](https://blog.laozhang.ai/posts/ru/codex-account-read-failed-tui-bootstrap/img/three-checks-version-compare.webp)

Подкоманды `codex app-server daemon …` и флаги `doctor` взяты из `--help` сборки 0.163.0-alpha.10.2. [Официальная страница команд Codex CLI](https://learn.chatgpt.com/docs/developer-commands?surface=cli) описывает `codex doctor`, `codex login status`, `codex logout`, флаг `--no-daemon` и команду `/daemon`, но подкоманды `app-server daemon` на ней отсутствуют — сверяйте их через `codex app-server daemon --help` своей версии.

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

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

| Хвост после `account/read failed:` | Семейство причины | Что помогало по отчётам | Общий фоновый сервер участвует |
| --- | --- | --- | --- |
| `workspace routing discovery failed` | состояние или версия фонового сервера; прокси | `codex app-server daemon restart` (форум OpenAI, 9 октября; #52928, 15 октября); `codex app-server daemon update --from-cli --yes` при расхождении версий (#52928, 15 октября); переменные прокси (#52928, 12 октября) | да: `codex --no-daemon` запускался, обычный `codex` нет (#52928, 10 октября) |
| `workspace routing discovery timed out` | 15-секундный таймаут discovery: сеть, прокси, WSL2, старое состояние сервера | `pkill -f codex`, затем `codex` (#48894, 29 сентября, два подтверждения); `HTTP_PROXY` и `HTTPS_PROXY` в окружении (#49921, 1 октября); для WSL2 решения в отчёте нет (#51052) | да, либо сеть |
| `failed to load workspace requirements` | не загрузился набор требований пространства; в одном отчёте под ним был отозванный токен (`401 token_revoked`) | повторный вход и завершение TUI и daemon со старым токеном (#54184, 15 октября); `-c log_dir=…`, то есть встроенный режим (#52775, комментарий от 14 октября); на 0.163.0 всё ещё падает, выход и вход не помогли (форум OpenAI, 17 октября) | частично |
| `workspace routing discovery unauthorized (401)` | токен перестал приниматься после изменений в аккаунте | `codex login --device-auth` на хосте с учётными данными (#47456, 23 сентября); если 401 остался — завершить старый `codex app-server` (#47456, 1 октября) | да: старый процесс держит токен |
| `duplicate workspace in routing discovery` | в аккаунте два одинаковых пространства Personal | ничего на стороне пользователя; обращение в поддержку (#47034, сентябрь–октябрь) | нет: с `--no-daemon` то же самое |
| `selected workspace missing from routing discovery` | сохранённый выбор пространства не найден в списке аккаунта (предположение по тексту строки) | войти заново и выбрать пространство; проверить `forced_chatgpt_workspace_id` | — |
| `plan type is required for chatgpt authentication (code -32600)` | токен ChatGPT без поля plan type: сторонний сервис или смешанный вход | `codex logout`, затем официальный `codex login` или `codex login --with-api-key` | нет |
| без хвоста (0.120.0, апрель) | `requires_openai_auth = true` у своего провайдера и устаревший `auth.json` | убрать флаг или удалить `auth.json` и войти заново (#17800, апрель–май) | нет |

![Схема: хвост ошибки после account/read failed и что помогало по отчётам — перезапуск фонового сервера, повторный вход, поддержка при duplicate workspace, codex logout при plan type](https://blog.laozhang.ai/posts/ru/codex-account-read-failed-tui-bootstrap/img/tail-to-action-map.webp)

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

Удаление `~/.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](https://github.com/openai/codex/releases/tag/rust-v0.157.0)) интерактивный `codex` запускает постоянный `codex app-server --managed-daemon` и рядом с ним процесс обновления `codex app-server daemon pid-update-loop`. По описанию в [issue #48195 о фоновом сервере по умолчанию](https://github.com/openai/codex/issues/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](https://community.openai.com/t/1404666), 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 через общий сервер](https://github.com/openai/codex/issues/52928), 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](https://github.com/openai/codex/issues/48894), 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](https://github.com/openai/codex/issues/52775) (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 об исчерпании файловых дескрипторов](https://github.com/openai/codex/issues/37971) (август, 7 комментариев): там падал другой шаг старта, `configRequirements/read`, с текстом `No file descriptors available (os error 24)`, а у сервера после восьми дней работы было открыто 1022 из 1024 дескрипторов; 0.162.0 подняла лимит управляемого сервера до 4096 (запись #51470). Перезапуск снимает и это.

WSL2 — отдельная история без решения: в [issue #51052 о таймауте account/read в WSL2](https://github.com/openai/codex/issues/51052) (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](https://github.com/openai/codex/issues/49921), 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` подставьте адрес, который слушает ваш прокси:

```bash
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](https://github.com/openai/codex/issues/50211) (комментарий от 16 октября) пользователь корпоративной сети вошёл в аккаунт успешно — вход идёт через `*.openai.com`, — а всё после входа падало, потому что `chatgpt.com` был заблокирован. Discovery ходит именно на `chatgpt.com/backend-api/…`, так что успешный `codex login` ничего не говорит о доступности этого домена.

**Корпоративный TLS-перехват.** По [документации Codex по аутентификации](https://learn.chatgpt.com/docs/auth) поддерживается переменная `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](https://github.com/openai/codex/issues/54184) (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 года](https://community.openai.com/t/1407111): 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 об устаревшем входе на удалённом хосте](https://github.com/openai/codex/issues/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](https://blog.laozhang.ai/ru/posts/codex-headless-login). Если падает уже сам `codex login` с 403, это другая ошибка: [Codex token exchange failed 403: как восстановить вход](https://blog.laozhang.ai/ru/posts/codex-token-exchange-failed-403). А 401 с текстом `Incorrect API key` появляется на запросах к модели уже после открытия интерфейса, и у него свой разбор: [Codex: ошибка 401 Incorrect API key — сбой, вход или ключ](https://blog.laozhang.ai/ru/posts/codex-401-incorrect-api-key).

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

Тупик, и честнее сказать об этом сразу. В [issue #47034 о duplicate workspace после успешного входа](https://github.com/openai/codex/issues/47034) (открыт 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](https://learn.chatgpt.com/docs/config-file/config-reference): «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.

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

```bash
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: цена, лимиты и что выбрать](https://blog.laozhang.ai/ru/posts/codex-api-key-vs-subscription).

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

```toml
[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](https://blog.laozhang.ai/ru/posts/codex-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)](https://github.com/openai/codex/releases/tag/rust-v0.163.0) — перезапуск через `/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](https://blog.laozhang.ai/ru/posts/codex-cli-install).

## 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 о ежедневном повторном входе](https://github.com/openai/codex/issues/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: что оставить, а что завершить](https://blog.laozhang.ai/ru/posts/codex-windows-background-processes). Если в VS Code вы видите не сообщение про вход, а 30-секундный экран «Codex could not start», это другая ошибка: [Codex could not start в VS Code: причины для WSL, SSH и прокси](https://blog.laozhang.ai/ru/posts/codex-could-not-start-vscode).

## Вопросы про 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.

## Источники

Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 2026-10-17.

- [исходном коде маршрутизации рабочих пространств в репозитории Codex](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs) (github.com)
- [issue #17800 в репозитории Codex](https://github.com/openai/codex/issues/17800) (github.com)
- [Официальная страница команд Codex CLI](https://learn.chatgpt.com/docs/developer-commands?surface=cli) (learn.chatgpt.com)
- [заметках к выпуску Codex CLI 0.157.0](https://github.com/openai/codex/releases/tag/rust-v0.157.0) (github.com)
- [issue #48195 о фоновом сервере по умолчанию](https://github.com/openai/codex/issues/48195) (github.com)
- [тема «Codex CLI 0.162.0 fails during TUI bootstrap» на форуме разработчиков OpenAI](https://community.openai.com/t/1404666) (community.openai.com)
- [issue #52928 о сбое account/read через общий сервер](https://github.com/openai/codex/issues/52928) (github.com)
- [issue #48894 про Sign-in failed в расширении VS Code](https://github.com/openai/codex/issues/48894) (github.com)
- [issue #52775 про запуск 0.162.1 только с -c log_dir](https://github.com/openai/codex/issues/52775) (github.com)
- [issue #37971 об исчерпании файловых дескрипторов](https://github.com/openai/codex/issues/37971) (github.com)
- [issue #51052 о таймауте account/read в WSL2](https://github.com/openai/codex/issues/51052) (github.com)
- [issue #49921 о таймауте discovery без HTTP_PROXY](https://github.com/openai/codex/issues/49921) (github.com)
- [issue #50211 про workspace routing discovery failed на macOS](https://github.com/openai/codex/issues/50211) (github.com)
- [документации Codex по аутентификации](https://learn.chatgpt.com/docs/auth) (learn.chatgpt.com)
- [issue #54184 о скрытом 401 token_revoked](https://github.com/openai/codex/issues/54184) (github.com)
- [Тема на форуме разработчиков OpenAI от 17 октября 2026 года](https://community.openai.com/t/1407111) (community.openai.com)
- [issue #47456 об устаревшем входе на удалённом хосте](https://github.com/openai/codex/issues/47456) (github.com)
- [issue #47034 о duplicate workspace после успешного входа](https://github.com/openai/codex/issues/47034) (github.com)
- [справочнике конфигурации Codex](https://learn.chatgpt.com/docs/config-file/config-reference) (learn.chatgpt.com)
- [0.163.0 (15 октября, Latest)](https://github.com/openai/codex/releases/tag/rust-v0.163.0) (github.com)
- [issue #49443 о ежедневном повторном входе](https://github.com/openai/codex/issues/49443) (github.com)