Сообщение error loading configuration: timed out waiting for cloud config bundle after 15s относится к запуску Codex. Клиент ещё не дошёл до обычного запроса модели: он пытался применить управляемые требования рабочего пространства и не смог закончить этот этап за отведённое время.
Это важное уточнение, но не готовый диагноз. Одна строка не доказывает ни общий сбой OpenAI, ни блокировку proxy, VPN или firewall, ни истёкший вход, ни неверное рабочее пространство, ни повреждение кэша. Поэтому первый полезный шаг — не удалить данные, а сохранить исходное состояние и выполнить один сопоставимый контрольный запуск.
Что именно не успел сделать Codex
В описании managed configuration OpenAI объясняет, что поддерживаемые локальные клиенты могут получать требования организации в составе cloud config bundle. Это касается ChatGPT desktop, Codex CLI и расширения IDE, однако доступность отдельных возможностей зависит от клиента и версии.
При запуске клиент сначала ищет действительный подписанный кэш, соответствующий текущей identity. Если подходящего кэша нет, он запрашивает пакет с повторами и сохраняет результат после успешной проверки. Когда запрос заканчивается ошибкой или тайм-аутом и действительного кэша нет, клиент останавливает загрузку вместо запуска без требований организации. Это защитная граница: локальный клиент не должен молча обойти политику workspace.
Отсюда следуют три практических вывода:
- 15 секунд относятся к загрузке управляемой конфигурации при старте, а не к медленному ответу модели;
- кэш привязан к учётной записи и должен быть действительным, поэтому кэш от другой identity не является запасным пропуском;
- удаление кэша «на всякий случай» может убрать единственную рабочую копию политики и сделать следующий запуск ещё более зависимым от сети.
Обычный config.toml — другая часть системы. Локальные слои конфигурации задают значения из CLI, проекта, профиля, пользовательского и системного файлов. Управляемые требования ограничивают разрешённое поведение, а не работают как ещё один удобный локальный override. Переписывание TOML не проверяет, может ли клиент получить cloud bundle.
Сохраните минимальный набор фактов
До перезапуска запишите:
- точный текст ошибки и время с часовым поясом;
- где она появилась: desktop app, CLI или IDE extension;
- версию клиента и ОС;
- тип входа и выбранные account/workspace без токенов и адреса почты;
- фактический хост: локальный Mac/PC, контейнер, WSL, Remote SSH или корпоративная VM;
- используемый маршрут: офисная сеть, домашняя сеть, VPN, proxy, security agent;
- произошла ли ошибка при первом запуске, после обновления, смены workspace или повторного входа.
Если интерфейс закрывается слишком быстро, сфотографируйте сообщение или скопируйте stderr. Перед передачей лога удалите секреты, приватные пути, имена репозиториев и содержимое запросов. Не публикуйте весь каталог Codex.
Если установленная версия CLI поддерживает диагностику, начните с команд, которые ничего не удаляют:
bashcodex --version codex --help codex doctor --summary codex login status
В актуальном справочнике команд codex doctor собирает сведения об установке, конфигурации, аутентификации и среде выполнения; вариант --json документирован как редактированный для безопасной передачи. Но успешный отчёт не доказывает доступность удалённого bundle. Аналогично, codex login status показывает активный режим входа, а не проверяет сетевой маршрут.
Сверяйтесь с локальным codex --help: старые и новые сборки могут отличаться. Не запускайте codex logout только из-за общего тайм-аута — эта команда удаляет сохранённые credentials.
Один контрольный запуск вместо серии случайных правок
Выберите одну переменную, которую можно безопасно проверить, и оставьте остальные неизменными. Повтор должен использовать тот же account, workspace, проект и версию клиента. Зафиксируйте, исчезла ли ошибка, изменилась ли её стадия и сколько заняло ожидание.
| Наблюдение | Контрольный тест | Куда направляет результат |
|---|---|---|
| На странице статуса OpenAI есть подходящий активный инцидент | Не менять локальные данные; повторить после восстановления сервиса | Вероятна сервисная граница, но статус остаётся агрегированным |
| Ошибка только в офисной сети или с VPN | Один запуск по разрешённому альтернативному маршруту | Proxy, firewall, TLS inspection, DNS или правила egress |
| Ошибка появилась сразу после обновления | Сохранить обе версии и проверить поддерживаемое обновление | Версия клиента или её упаковка |
| Ошибка связана со сменой account/workspace | Сначала подтвердить выбранную identity; не стирать кэш | Аутентификация, назначение workspace или политика организации |
| Ошибка повторяется на разных разрешённых сетях у одного пользователя | Передать диагностический отчёт и время | Account/workspace, клиент или индивидуальный маршрут |
| Ошибка одновременно у нескольких участников одного workspace | Собрать версии, регионы и время без секретов | Администратор workspace или поддержка OpenAI |
Открывающийся сайт в браузере — слабый тест. Codex может выполняться в другом process environment, использовать системный proxy иначе или находиться на удалённом хосте. Сравнивать нужно маршруты именно того процесса, который показывает ошибку.
Не выключайте корпоративную защиту и не обходите требования организации. Если альтернативная сеть запрещена, передайте проверку сетевой команде: ей полезны время, клиент, версия, хост, тип маршрута и точная стадия, но не ваши credentials.
Что не следует делать первым
Не начинайте с удаления .codex, неизвестного cache directory или всех сохранённых данных приложения. Публичная документация описывает проверяемый identity-matched cache, но не предлагает ручное удаление как обычное восстановление. Такая очистка меняет сразу несколько условий и уничтожает диагностическую ценность состояния.
Не увеличивайте тайм-ауты MCP. Сообщение о cloud config bundle возникает раньше загрузки обычной сессии и не относится к startup_timeout_sec конкретного MCP-сервера. Если после успешного старта позже зависает MCP, это уже другая граница и отдельное наблюдение.
Не редактируйте много параметров config.toml одновременно. Если доказательства действительно указывают на precedence локальной конфигурации, используйте отдельное руководство по config.toml. Для явной ошибки обновления токена есть диагностика refresh token, а HTTP 429 относится к лимитам Codex. Совпадение по времени не делает эти ошибки одной причиной.
Когда повторный вход оправдан
Повторный вход уместен, когда есть отдельный признак проблемы аутентификации: команда показывает неожиданный режим, workspace не тот, появились явные сообщения о refresh token или администратор подтвердил изменение назначения. Сначала сохраните codex login status и диагностический отчёт. Затем подготовьте способ входа и только после этого используйте logout/login, понимая, что logout удалит сохранённые учётные данные.
Если единственный симптом — 15-секундный тайм-аут bundle, выход из аккаунта остаётся догадкой, а не следствием доказательств.
Что передать администратору или поддержке
Хороший пакет эскалации короткий и сопоставимый:
- точная ошибка и два-три времени повторения с часовым поясом;
- клиент, версия, ОС и фактический хост;
- account/workspace в безопасной форме и тип аутентификации;
- результаты страницы статуса и одного разрешённого сетевого сравнения;
codex doctor --summaryили редактированный JSON, если команда доступна;- что именно изменилось перед первым случаем и какие действия уже выполнялись.
Укажите отрицательные результаты: «та же версия и workspace; дома работает, в офисе нет» гораздо полезнее, чем «переустанавливал несколько раз». Не прикладывайте токены, cookies, полный environment или необработанный архив домашнего каталога.
Безопасная последовательность проста: определить startup-границу, сохранить действительный кэш и доказательства, проверить одну переменную, затем передать проблему владельцу подтверждённой границы. Если следующий запуск проходит cloud config bundle и останавливается позже, диагностируйте уже новую стадию — не переносите на неё выводы из этих 15 секунд.
