Codex "couldn't load its resources": 5 причин (2026)

Кратко

Текст ошибки:        "Codex could not start. The extension couldn't load its resources."
Что это значит:      webview не отправил рукопожатие ready за 30 секунд
Затронутые версии:   26.803.41515 (08-07), 26.803.61601 (08-10)
Исправлено в:        26.810.41047 stable / 26.5810.41047 pre-release (08-13)
Текущая stable:      26.810.52044 (08-15)
Безопасный откат:    26.727.40816 (07-30)
Различных причин:    5 (таймер, сеть, зависшая аутентификация, кеш браузера, конфликт с Copilot)
Что не работает:     удаление auth.json, погоня за предупреждением data:font CSP
Открыто наверху:     openai/codex#37521 (зависшая идентификация аккаунта)

Если боковая панель Codex в VS Code крутилась полминуты, а затем схлопнулась в серую панель с надписью «The extension couldn’t load its resources», сообщение вас обмануло. Ресурсы загрузились. Провалилось рукопожатие, а на стороне хоста расширения работал секундомер.

Текст ошибки был лучшей маскировкой этого бага. Codex не мог найти свои файлы — он не мог дождаться ответа от окна, которое их уже загрузило.

Этот материал посвящён конкретно августовской регрессии 2026 года: какие сборки её несут, что именно изменила OpenAI и какие ещё четыре пути отказа выводят на экран ту же самую фразу. Если проблема в бинарнике CLI, а не в панели редактора, вам нужна страница про codex: command not found. Если десктопное приложение Codex не может запустить бэкенд в Windows — это другая ошибка с другим решением.

Какая у вас версия Codex? Диагностика за 30 секунд

Одна команда даёт ответ, и от него зависит всё остальное на этой странице. Выполните её прежде, чем менять хоть одну настройку.

code --list-extensions --show-versions | grep openai.chatgpt

Номера версий с 5 во втором сегменте (26.5810.41047) — это предварительные сборки того же кода. Если у вас в Marketplace включены pre-release, 26.5810.41047 несёт то же исправление, что и 26.810.41047.

Сигнатура отказа в Codex.log, подтверждающая, что вы имеете дело именно с этим багом:

Initialize received
Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

Важнее то, чего в неудачном окне нет. Успешный запуск пишет три вехи рендерера, до которых неудачный не доходит:

React root render requested
app routes mounted
ready provider mounted

Если Initialize received есть, а ни одной из трёх вех нет — бэкенд здоров, а приложение на стороне браузера не загрузилось. Это и есть наш баг. Если Initialize received тоже отсутствует, проблема другая, и таблица версий выше не поможет.

Обновляться, откатываться или ждать?

Обновляться. Практически для всех, кто читает это уже постфактум, обновление до 26.810.52044 и есть всё решение, и выбор тут не близкий.

Правило трёх вариантов:

• Обновляйтесь, если вы на любой сборке 26.803.x. Исправление держится стабильно уже три релиза. Это вариант по умолчанию, и он верен примерно в девяти случаях из десяти.
• Откатывайтесь на 26.727.40816 только если вы уже обновились дальше 26.810.41047, панель по-прежнему не запускается, и вы уже исключили причины, связанные с сетью и аутентификацией. Откат — реальный вариант, но это не диагноз, и через неделю придётся повторять.
• Прекратите читать и используйте CLI, если вам нужно что-то сдать в ближайший час. Расширение и CLI — разные бинарники. Поломка одного ничего не говорит о другом.

Правило остановки: если вы обновились до 26.810.52044, а панель всё равно не открывается, прекратите перебирать версии. Сторожевого таймера, порождавшего именно эту ошибку, в той сборке уже нет. То, что вы видите сейчас, — одна из причин со 2-й по 5-ю, и переустановками до неё не добраться.

Почему Codex пишет «The extension couldn’t load its resources»?

Потому что истёк 30-секундный таймер, а сообщение, которое он напечатал, было неверным.

Хост расширения создаёт webview, а затем ждёт от него сообщения ready. Если сообщение не приходит в отведённое окно, хост выбрасывает webview и подставляет статическую страницу ошибки. Страница винила загрузку ресурсов, потому что это самая частая причина молчания webview, а не потому, что кто-то это проверил.

Сообщество разобралось в основном обсуждении на GitHub, которое набрало 53 комментария за шесть дней до закрытия. Появились две конкурирующие версии диагноза, и более популярная оказалась неверной — поучительным образом.

Первая версия указывала на строку в бандле webview, которая ставит рендеринг за startup.whenReady(), и патч, убиравший её, вроде бы помогал. Но более поздний анализ показал, что в сборках VS Code это выражение вычисляется по короткой схеме. Вот реальная строка из app-main-BpHShvzH.js в затронутой сборке:

let e = G || K || N.startup == null ? void 0 : Promise.resolve(N.startup.whenReady());

В сборке VS Code объект сервиса никогда не регистрирует startup, поэтому N.startup == null истинно, всё выражение вычисляется в void 0, и whenReady() не вызывается ни разу. Патчить вызов, который никогда не выполняется, ничего исправить не может. Он срабатывал как побочный эффект того, что процесс патчинга переписывал и заново генерировал граф ассетов.

Вторая версия устояла: репортер готовности, отправляющий {type: "ready"}, был вложен в дереве компонентов под бизнес-инициализацией. Всё, что тормозило запуск приложения — медленный сетевой вызов, зависший запрос аутентификации, — тормозило и рукопожатие, а таймер не мог отличить «это окно мертво» от «это окно ещё работает».

Третья версия, предупреждение Content Security Policy про data:font/woff2 в консоли разработчика, оказалась ложным следом. Оно появляется и в здоровых окнах. Как выразился один из участников, собрав логи обоих состояний: предупреждение про шрифт и ошибки посторонних расширений здесь не являются блокировщиком запуска.

Что изменилось в 26.810.41047? Мы сравнили VSIX

Закрывающий комментарий OpenAI говорит, что релиз «fixes the startup watchdog issue» и что вы больше не должны видеть ошибку «simply because application initialization takes longer than 30 seconds». Формулировка точная, и её стоит прочитать внимательно.

Мы скачали два пакета VSIX из Marketplace (darwin-arm64, 167 МБ и 207 МБ соответственно), плюс сборку до регрессии для сравнения, и подсчитали строки в бандле хоста расширения extension/out/extension.js:

Интересен именно первый столбец, и он меняет всю картину. Ни одной из этих строк в июльской сборке нет. Весь экран ошибки — и таймер, и формулировка — приехал вместе с регрессией.

То есть сторожевой таймер не был давно существовавшим механизмом, который вдруг начал ложно срабатывать. 2026-07-30 его не существовало. Он вышел 2026-08-07, шесть дней помечал целый класс медленных запусков как сбой загрузки ресурсов, и был удалён 2026-08-13. И таймер, и напечатанная им фраза родились и были похоронены на протяжении одной недели.

Это объясняет и то, почему откат на 26.727.40816 так надёжно срабатывал у всех, кто его пробовал. Они откатывались не на версию, где не было бага. Они откатывались на версию, где не было секундомера, так что медленный запуск оставался просто медленным, а не убивался и переименовывался.

Перечитайте формулировку OpenAI с учётом этого. Недавнее изменение обнажило существовавший баг, который прежде был замаскирован. Недавнее изменение — это новый таймер. Обнажённое им зависание — это существовавший баг, и он никуда не делся, чему и посвящён следующий раздел.

Сама страница ошибки в исправлении не исчезла. Изменилась её формулировка:

Так что у исправления две половины, и только одна из них — собственно исправление. Таймер, сдававшийся через 30 секунд и винивший ассеты, исчез. Честная замена текста осталась — для случаев, когда интерфейс действительно не поднимается.

У этого есть практическое следствие, более важное, чем кажется: фразы, которую вы искали, чтобы найти эту страницу, в текущих сборках больше не существует. Если вы на 26.810.x и видите «could not start its user interface», перед вами не баг с таймером. Перед вами настоящее зависание, и разбираться нужно в разделах ниже.

Ещё одно, что показывает сравнение. Точка входа webview app-main весит 2 679 байт в обеих сборках, с разными хешами SHA-256, и короткое замыкание startup == null присутствует в обеих. Логику рукопожатия webview не переписывали. Хост расширения просто перестал наказывать её за медлительность.

Какие 5 причин стоят за одной и той же ошибкой?

Августовское обновление исправило только первую. Остальные четыре живы, и они были там всегда.

Причина 1 — это августовская регрессия, она закрыта. Причины со 2-й по 5-ю были всегда. До исправления все пять выводили одну и ту же вводящую в заблуждение фразу — именно поэтому обсуждению на GitHub понадобилось шесть дней, чтобы сойтись: люди сверяли заметки о пяти разных багах, надевших одну маску.

Причина 2: доступность сети

Это самый частый выживший после обновления, и OpenAI назвала её прямо при закрытии issue: проверьте настройки прокси и VPN.

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

Поддержка прокси в VS Code отключена. Проверьте settings.json:

{
  "http.proxySupport": "on"
}

Если здесь стоит "off", расширение не может использовать системный прокси. Один пользователь обнаружил, что менял это при отладке посторонних сетевых проблем и забыл вернуть. Возврат к "on" устранил зависание.

В окружении хоста расширения нет прокси. Запуск VS Code из оболочки, экспортирующей прокси, помогает в части конфигураций:

export https_proxy=http://127.0.0.1:9001
code

В macOS и Linux запуск VS Code с иконки на рабочем столе не наследует переменные окружения оболочки. Если прокси прописан в .zshrc, а VS Code вы запускаете из Spotlight, хост расширения его никогда не увидит.

Зачем панели редактора кода вообще нужна сеть до отрисовки? Потому что при запуске подтягивается состояние аккаунта. Фрагмент лога из обсуждения показывает, что расширение вызывает даже тогда, когда пользователь настроил ключ API, а не вход через ChatGPT:

WARN codex_core_plugins::manager: failed to warm featured plugin ids cache
error=remote featured plugin request to
https://chatgpt.com/backend-api/plugins/featured?platform=codex
failed with status 401 Unauthorized

Этот запрос уходит на chatgpt.com независимо от того, какого провайдера вы настроили. Если ваша сеть до него не достаёт, инициализация останавливается в точке, которую старый таймер в итоге убивал. Если вы ловите 401 в CLI, а не в панели, разбор 401 в Codex CLI разделяет три разные причины этого статуса.

Этот путь проверяется одной строкой. Выполните её с той же машины и из той же сети, где падает редактор:

curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" \
  "https://chatgpt.com/backend-api/plugins/featured?platform=codex"

Читайте результат так:

При замере без аутентификации с обычного соединения конечная точка отвечает 401 примерно за 100 мс телом в 25 байт {"detail":"Unauthorized"}, что дословно совпадает с ответом, процитированным в логах расширения выше. 401 в вашем логе — не свидетельство бага аутентификации. Это свидетельство того, что запрос завершился. Искать нужно молчание, а не отказ.

Причина 3: зависшие запросы идентификации аккаунта

Эта переживает любое исправление, и у неё собственный issue: openai/codex#37521, на момент написания открытый, с метками auth и connectivity.

Форма отказа: запрос идентификации аккаунта уходит и попросту никогда не завершается. Ни ошибки, ни тайм-аута, ни отката в офлайн-режим. Запуск ждёт вечно. До 26.810.41047 таймер в итоге заменял панель на ошибку про ресурсы, что хотя бы сообщало о неполадке. Теперь панель просто сидит на месте.

Чистого решения на стороне пользователя нет. Что срабатывало у части людей:

1. Открыть десктопное приложение ChatGPT, войти заново, полностью перезапустить VS Code
2. Перезагрузить окно два-три раза (Cmd/Ctrl+Shift+P → Developer: Reload Window)

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

Причина 4: кеш service worker в браузере

Специфична для VS Code Web и сессий code serve-web, открытых через браузер. Ассеты webview кешируются service worker’ом браузера, и после обновления расширения закешированный граф ассетов может ссылаться на файлы, которых под теми же именами уже нет.

Симптомы, указывающие именно сюда:

• Воспроизводится только во вкладке браузера, никогда — в десктопном VS Code на той же машине
• Переживает Developer: Reload Window
• Несколько окон VS Code Web, подключённых к одному серверу, ведут себя по-разному

Решение — жёсткий сброс кеша на стороне браузера: очистить данные сайта для источника VS Code Web и перезагрузить. Обычное обновление не поможет, потому что service worker отдаёт устаревший граф раньше, чем дело дойдёт до сети.

Причина 5: Positron и GitHub Copilot

Узкий, но чисто воспроизводимый случай, о котором сообщали на Positron 2026.08.0 (Code OSS 1.124.0) в Ubuntu 24.04. Codex работает нормально ровно до того момента, когда GitHub Copilot аутентифицируется как провайдер языковой модели. После включения Copilot и перезапуска Positron Codex падает. Выход из Copilot и перезапуск возвращают его к жизни.

Это воспроизводится с чистого профиля пользователя, так что дело не в накопившихся поломках конфигурации. Если вы используете оба в Positron, вот ваш ответ, и переустановка Codex тут не поможет.

Какие из гуляющих по сети решений не работают?

Три, и самое популярное меняет ваш вход в аккаунт на ничто.

Три совета широко разошлись в обсуждении на GitHub и в поисковой выдаче вокруг него. Все три стоит знать именно для того, чтобы их пропустить.

Удалить ~/.codex/auth.json. Самый часто повторяемый совет. Он выглядел логично, потому что расширение действительно застревает на работе, смежной с аутентификацией, и первый опубликовавший его человек отчитался об успехе. Но другие попробовали и не получили ничего, а один сообщил, что ошибка вернулась сразу после смены рабочей области. Вы отдаёте свою сессию в обмен на подбрасывание монетки. Таймер срабатывал по тайм-ауту рукопожатия, а удаление файла с учётными данными не заставит webview отрисоваться быстрее.

Гоняться за предупреждением CSP про data:font/woff2. В исходном отчёте была строка консоли, показывающая, как CSP Chrome блокирует встроенный base64-шрифт, и читается это как неопровержимая улика. Это не она. Предупреждение появляется и в окнах, которые запускаются прекрасно. Более поздняя диагностика в обсуждении подтвердила, что это не блокировщик.

Вырезать startup.whenReady() из бандла webview патчем. Этот заслуживает большего уважения, чем два предыдущих, потому что автор проделал реальную работу и людям это действительно помогало. Но механизм был понят неверно, что видно по процитированной выше реальной строке: N.startup == null в сборках VS Code истинно, так что whenReady() там — мёртвый код. Патч помогал как побочный эффект перегенерации графа ассетов. Если вы его применяли, откатите после обновления. Отредактированные вручную бандлы внутри каталога расширения всё равно молча заменяются при следующем автообновлении, а если правка попортит не-ASCII символы — что случилось с одной реализацией на PowerShell из-за кодовой страницы ANSI в Windows, — вы получите синтаксическую ошибку вместо рабочей панели.

Хронология сбоя расширения Codex: регрессия 26.803

Шесть дней от первого отчёта до выпуска исправления, через шесть сборок.

Одна деталь в этой хронологии заслуживает отдельного упоминания. У issue стоит метка windows-os, и исходный отчёт действительно был с Windows. Но обсуждение собрало подтверждения с macOS, Debian 13, Ubuntu через Remote-SSH, WSL2 и VS Code Web в Firefox. Если вы отмахнулись от этого бага, потому что вы не на Windows, вас ввела в заблуждение эта метка.

Как откатиться на конкретную версию

Если 26.727.40816 нужна прямо сейчас, не используйте панель расширений. Путь через шестерёнку и «Install Another Version» — это ровно то, что не сработало у автора исходного issue с ошибкой Error while downloading VSIX: Canceled. CLI надёжнее и укладывается в одну строку:

code --install-extension openai.chatgpt@26.727.40816 --force

Проверено на macOS с VS Code 1.132.0. Команда сама подбирает пакет под платформу и в случае успеха сообщает установленную версию:

Installing extension 'openai.chatgpt' v26.727.40816...
Extension 'openai.chatgpt' v26.727.40816 was successfully installed.

После этого отключите автообновление именно для этого расширения, иначе следующее фоновое обновление отменит ваш откат в течение дня. В панели расширений щёлкните по Codex правой кнопкой и снимите галочку Auto Update.

Чтобы вернуться вперёд, устанавливайте без суффикса версии:

code --install-extension openai.chatgpt --force

Где на самом деле лежат логи

Файл Codex.log, на который ссылаются по всему обсуждению, создаётся отдельно для каждого окна и закопан в каталог с меткой времени — поэтому так много людей публиковали скриншоты панели вместо логов:

Для каждой сессии VS Code создаётся новый каталог с меткой времени, так что сортируйте по времени изменения и берите самый свежий. Более быстрый путь к тому же содержимому — панель Output: Cmd/Ctrl+Shift+U, затем выбрать Codex в выпадающем списке.

Для сбоев, которые вообще не доходят до хоста расширения — особенно причина 4, — в логе расширения не будет полезных деталей. Откройте Developer: Open Webview Developer Tools из палитры команд, включите Preserve log во вкладке Console и перезагрузите окно. Первая красная ошибка там и есть та, которую стоит читать. Именно так в обсуждении в итоге локализовали синтаксическую ошибку на стороне рендерера, которую чтение Codex.log никогда бы не выявило.

Как продолжать работать, пока панель редактора не запускается?

Используйте CLI. Это отдельный бинарник, и ни одна из пяти причин выше его не касается.

Все причины выше живут на уровне webview в VS Code. Ни одна не трогает самого агента, и именно это упускает большинство людей, пока занято переустановкой расширения: панель — это клиент, и он не единственный.

Codex CLI — отдельный бинарник с отдельной моделью процессов:

codex --version
# codex-cli 0.147.0

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

Хронология обнажает и второй разрыв. Исправление добралось до VS Code Marketplace 2026-08-13, но OpenAI отметила, что пакеты для Windows сейчас не публикуются в Open VSX из-за нерешённого ограничения на размер пакета в реестре, открытого с марта 2026 года. Редакторы, которые тянут расширения из Open VSX, а не из Marketplace, — а это несколько форков VS Code — могут по-прежнему отдавать пользователям Windows сборку до исправления. Если вы на таком редакторе и таблица версий показывает 26.803.x, а обновления нет, причина в этом.

У обоих разрывов одна форма: ваш доступ к модели опосредован клиентом одного вендора, графиком релизов одного вендора и реестром одного вендора. Поскольку Codex CLI говорит по OpenAI-совместимому HTTP, направить его на другую конечную точку — это две переменные окружения:

export OPENAI_BASE_URL=https://api.ofox.io/v1
export OPENAI_API_KEY=your_key
codex

Так терминальный путь продолжает работать, пока расширение лежит, и конфигурация одна и та же, что бы ни сломалось: расширение, реестр или региональная выкатка. Вариант с файлом конфигурации, если не хочется возиться с переменными окружения, разобран в настройке кастомных провайдеров моделей; а если нужен запасной путь, не зависящий от того, какая сборка плагина вышла на этой неделе, ofox отдаёт актуальные Codex-совместимые модели по одному ключу.

Как убедиться, что исправление действительно приехало?

Сначала посмотрите номер версии, а если нужны доказательства, а не номер, — сделайте grep по бандлу. Три проверки в порядке возрастания информативности.

Проверьте версию. Таблица в начале страницы. Всё, начиная с 26.810.x, несёт исправление.

Проверьте строку. Если хочется убедиться, что таймера действительно нет именно в вашей сборке, а не поверить номеру версии, текст ошибки лежит в бандле хоста расширения:

grep -c "couldn't load its resources" \
  ~/.vscode/extensions/openai.chatgpt-*/out/extension.js

Ожидайте по строке на каждую установленную копию в формате <путь>:<количество>. Количество 0 означает, что эта копия чистая. Любое ненулевое — затронутая сборка.

Вот на чём здесь спотыкаются: VS Code не всегда удаляет старый каталог при обновлении или удалении расширения, поэтому эта маска может совпасть сразу с несколькими версиями и отчитаться о сборках, которыми вы уже не пользуетесь. Читайте версию из пути, а не доверяйте голому числу. На машине, где тестировали и откат, и обновление, команда вернёт две строки:

/Users/you/.vscode/extensions/openai.chatgpt-26.810.41047/out/extension.js:0
/Users/you/.vscode/extensions/openai.chatgpt-26.727.40816-darwin-arm64/out/extension.js:0

Обе чистые, но по разным причинам: одна вышла после исправления, другая старше самого таймера. Учтите также, что у пакетов, установленных из Marketplace, в имени каталога есть суффикс платформы, а у вручную установленных VSIX — нет, так что две формы рядом это норма, а не признак поломанной установки.

Проверьте лог. После холодного старта откройте канал вывода Codex и поищите три вехи рендерера из раздела диагностики: React root render requested, app routes mounted, ready provider mounted. Все три на месте — значит webview загрузился до конца, что бы там ни тормозило дальше.

Что касается самого расширения, страница в VS Code Marketplace показывает текущую версию и дату выпуска, а история версий там — самый быстрый способ проверить, существует ли для вашей платформы сборка новее вашей. Учтите, что Marketplace отдаёт пакеты под конкретные платформы, поэтому свежайшая версия для win32-x64 и для darwin-arm64 может различаться на часы.

А если дело вообще не в расширении?

Есть два соседних сбоя, которые выглядят почти так же и этим багом не являются.

Если Codex не виден в редакторе, потому что он не установился, или потому что оболочка не находит бинарник, — это проблема PATH и установки, разобранная в codex: command not found. Если десктопное приложение Codex в Windows падает с ошибкой app-server manifest, упоминающей resourcesPath, — это проблема регистрации нативного хоста и действительно другой баг, разобранный в Codex не может запустить app server. То, что слово «resources» встречается в обоих сообщениях, — совпадение, стоившее людям многих часов.

А если панель запускается нормально, но в списке пропали ваши кастомные модели, то на пути запуска ничего не сломано. Это проблема конфигурации в десктопном приложении.

Источники

• https://github.com/openai/codex/issues/37458
• https://github.com/openai/codex/issues/37521
• https://github.com/EclipseFdn/open-vsx.org/issues/8724
• https://marketplace.visualstudio.com/items?itemName=openai.chatgpt