Codex「couldn't load its resources」5つの原因と修正 (2026)

概要

エラー文言：       "Codex could not start. The extension couldn't load its resources."
実際の意味：       webviewが30秒以内にreadyハンドシェイクを返さなかった
影響を受ける版：   26.803.41515（08-07）、26.803.61601（08-10）
修正版：           26.810.41047安定版 / 26.5810.41047プレリリース（08-13）
最新安定版：       26.810.52044（08-15）
安全なロールバック先：26.727.40816（07-30）
異なる根本原因：   5つ（ウォッチドッグ、ネットワーク到達性、認証保留、ブラウザキャッシュ、Copilot競合）
効果のない対処：   auth.json削除、data:font CSP警告の追跡
上流で未解決：     openai/codex#37521（アカウントID保留）

VS CodeのCodexサイドバーが30秒ほど回り続けたあと、灰色のパネルに 「The extension couldn’t load its resources」 と表示されて潰れたなら、そのメッセージはあなたを誤解させています。リソースは読み込まれています。失敗したのはハンドシェイクであり、拡張機能ホスト側ではストップウォッチが動いていました。

このエラーメッセージこそ、このバグの最良の変装だった。Codexはファイルを見つけられなかったのではない。すでにファイルを読み終えたウィンドウからの返事を聞けなかったのだ。

本稿が扱うのは2026年8月のこの回帰に限定した話です。どのビルドが該当するのか、OpenAIが実際に何を変更したのか、そして同じ一文を画面に出す他の4つの故障経路について扱います。問題がエディタのパネルではなくCLIバイナリ側にある場合は、codex: command not found のほうが目的のページです。WindowsでCodexデスクトップアプリがバックエンドを起動できない場合は、別のエラーで別の対処法になります。

まず自分のCodexバージョンを確認する

コマンド1つで判定でき、このページの以降の分岐はすべてその答え次第です。 設定を1つでも変える前に実行してください。

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

バージョン番号の2番目のセグメントに 5 が付くもの（26.5810.41047 など）は、同じコードのプレリリースビルドです。Marketplaceでプレリリースを有効にしている場合、26.5810.41047 は 26.810.41047 と同じ修正を含みます。

自分が本当にこのバグを踏んでいるかを確認する、Codex.log 内の失敗シグネチャ：

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

より重要なのは、失敗したウィンドウで何が欠けているかです。正常な起動では3つのレンダラーマイルストーンが記録されますが、失敗時はどれにも到達しません：

React root render requested
app routes mounted
ready provider mounted

Initialize received は出ているのに3つのマイルストーンが1つも出ていないなら、バックエンドは健全でブラウザ側のアプリが起動しなかったということです。それが本稿のバグです。Initialize received も出ていないなら別の問題であり、上の表は役に立ちません。

更新すべきか、ロールバックすべきか、待つべきか

更新してください。 事後にこれを読んでいるほとんどの人にとって、26.810.52044 への更新が答えのすべてであり、判断は微妙ですらありません。

3択のルール：

• 更新する：26.803.x のいずれかにいるなら。修正は3リリースにわたって安定しています。これが既定で、10回中9回はこれで正解です。
• 26.727.40816 へロールバックする：26.810.41047 より先へ更新済みで、それでもパネルが起動せず、かつ以下のネットワークと認証の原因をすでに排除した場合に限ります。ロールバックは実在する選択肢ですが診断ではなく、1週間後にまた同じことをする羽目になります。
• 読むのをやめてCLIを使う：1時間以内に何か出す必要があるなら。拡張機能とCLIは別のバイナリです。片方が壊れていても、もう片方については何も分かりません。

停止ルール：26.810.52044 に更新してもパネルが開かないなら、バージョンの組み合わせ探しはやめてください。この特定のエラーを生んだウォッチドッグは、そのビルドにはもう存在しません。いま見ているのは原因2から5のいずれかであり、再インストールを重ねても触れられません。

なぜCodexは「The extension couldn’t load its resources」と言うのか

30秒のタイマーが切れたからであり、そのとき出力された文言が間違っていたからです。

拡張機能ホストはwebviewを作成し、そのwebviewが ready メッセージを返してくるのを待ちます。メッセージが時間内に届かないと、ホストはwebviewを破棄して静的なエラーページに差し替えます。このページがリソース読み込みのせいにしたのは、それがwebviewが沈黙する最も一般的な理由だからであって、誰かが確認したからではありません。

コミュニティはGitHubのメインスレッドでこれを追跡しました。OpenAIがクローズするまでの6日間で53件のコメントが付いています。競合する2つの診断が現れ、より広まったほうが間違っていました。その間違い方が示唆に富んでいます。

第1の説は、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() は一度も呼ばれません。決して実行されない呼び出しにパッチを当てても何も直りません。効いたのは、パッチ処理がアセットグラフを書き換えて再生成した副作用によるものです。

持ちこたえた第2の説はこうです。{type: "ready"} をディスパッチする準備完了レポーターが、コンポーネントツリー上でビジネス初期化の下に入れ子になっていた。アプリ起動を遅らせるもの（遅いネットワーク呼び出し、ハングした認証要求）は何であれこのハンドシェイクも道連れに遅らせ、ウォッチドッグは「このウィンドウは死んだ」と「このウィンドウはまだ作業中」を区別できませんでした。

第3の説、開発者コンソールに出る data:font/woff2 のCSP警告は、赤いニシンでした。正常なウィンドウでも出ます。両方の状態のログを収集した貢献者の言葉を借りれば、フォントのCSP警告も無関係な拡張機能のエラーも、ここでの起動ブロッカーではありません。

26.810.41047で何が変わったのか。VSIXを差分比較した

OpenAIのクローズ時のコメントは、このリリースが “fixes the startup watchdog issue” であり、“simply because application initialization takes longer than 30 seconds” という理由でエラーが出ることはもうないと述べています。この言い回しは正確で、注意深く読む価値があります。

Marketplaceから2つのVSIXパッケージ（darwin-arm64、それぞれ167 MBと207 MB）に加え、回帰前のビルドも比較用にダウンロードし、拡張機能ホストのバンドル extension/out/extension.js 内の文字列を数えました：

最初の列こそが興味深く、話を書き換えます。7月のビルドにはこれらの文字列が1つも存在しません。エラー画面全体が、ウォッチドッグと文言もろとも、この回帰と一緒に到着したのです。

つまりこのウォッチドッグは、長く存在していて誤発火し始めた仕組みではありません。2026-07-30には存在せず、2026-08-07に出荷され、6日間かけて一群の遅い起動をリソース読み込み失敗と誤ってラベル付けし、2026-08-13に削除されました。タイマーもそれが出力した一文も、1週間のうちに生まれて葬られています。

これは、26.727.40816 へのロールバックが多くの人にあれほど確実に効いた理由も説明します。彼らがロールバックした先は「このバグがない」バージョンではなく、ストップウォッチがないバージョンでした。遅い起動は遅いままで済み、殺されてラベルを貼り替えられることがなかったのです。

これを踏まえてOpenAIの言い回しをもう一度読んでください。最近の変更が、以前は隠れていた既存のバグを露呈させた。新しいウォッチドッグがその最近の変更です。それが捕まえたストールが既存のバグであり、そちらはいまも残っています。それこそが次節の存在理由です。

修正でエラーページ自体が消えたわけではありません。文言が変わりました：

したがって修正には2つの側面があり、「修正」と呼べるのはそのうち片方だけです。30秒で諦めてアセットのせいにしていたウォッチドッグは消えました。正直な置き換え文言のほうは、UIが本当に起動しない場合のために残っています。

これには聞こえ以上に重要な実務上の帰結があります。あなたがこのページに辿り着くために検索したその一文は、現行ビルドにはもう存在しません。 26.810.x にいて「could not start its user interface」が出ているなら、それはウォッチドッグのバグではありません。実際のストールであり、以下の原因群こそが向かうべき場所です。

もう1つ、差分が示すこと。webviewのエントリポイント app-main は両ビルドとも2,679バイトで、SHA-256は異なり、startup == null の短絡は両方に存在します。webviewのハンドシェイクロジックは書き直されていません。拡張機能ホストが、遅いことを理由に罰するのをやめただけです。

同じエラーの背後にある5つの原因

8月の更新で修正されたのは1つ目だけです。残る4つはいまも生きており、そしてずっとそこにありました。

原因1が8月の回帰で、すでにクローズ済みです。原因2から5は元からありました。修正前は、この5つすべてが同じ誤解を招く一文を出していました。GitHubスレッドが収束するのに6日かかったのは、まさにこれが理由です。人々は5つの異なるバグについて情報交換していたのに、それらは1つのエラーメッセージを被っていたのです。

原因2：ネットワーク到達性

更新後に最も多く生き残るのがこれで、OpenAIもissueをクローズする際に名指ししています。プロキシとVPNの設定を確認してください、と。

スレッドには2つの異なる失敗形態が現れました。

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 に書いていてSpotlightからVS Codeを起動しているなら、拡張機能ホストはそれを一度も見ていません。

なぜコードエディタのパネルが描画前にネットワークを必要とするのか。起動時にアカウント状態を取得するからです。スレッド内のあるログ抜粋は、ユーザーがChatGPTログインではなくAPIキーを設定していても拡張機能が何を呼んでいるかを示しています：

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 に飛びます。ネットワークがそこに到達できなければ、初期化は旧ウォッチドッグがいずれ殺す地点で止まります。パネルではなくCLIで401に当たっている場合は、Codex CLIの401の3つの根本原因がそれらを切り分けています。

この経路は1行でテストできます。故障しているエディタと同じマシン、同じネットワークから実行してください：

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

結果はこう読みます：

通常の接続から未認証で実測すると、このエンドポイントは約100ミリ秒で 401 を返し、本文は25バイトの {"detail":"Unauthorized"} です。これは上の拡張機能ログで引用された応答と一字一句一致します。ログ内の401は認証バグの証拠ではなく、要求が完了した証拠です。探すべき失敗形態は沈黙であって、拒否ではありません。

原因3：アカウントID要求の保留

これはあらゆる修正を生き延びるもので、専用の追跡issueがあります。openai/codex#37521 は執筆時点でオープンで、auth と connectivity のラベルが付いています。

失敗の形はこうです。アカウントID要求が飛び、そのまま二度と解決しない。エラーもタイムアウトもオフラインモードへのフォールバックもなく、起動は永遠に待ち続けます。26.810.41047 より前ならウォッチドッグが最終的にパネルをリソースエラーに差し替え、少なくとも何かが起きたことは伝えてくれました。いまはパネルがただ座っているだけです。

きれいなユーザー側の修正はありません。一部の人に効いた方法：

1. ChatGPTデスクトップアプリを開いて再度サインインし、VS Codeを完全に再起動する
2. ウィンドウを2〜3回リロードする（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

範囲は狭いものの、きれいに再現します。報告環境はUbuntu 24.04上のPositron 2026.08.0（Code OSS 1.124.0）。GitHub Copilotが言語モデルプロバイダとして認証されるまでCodexは正常に動きます。Copilotを有効にしてPositronを再起動するとCodexが失敗します。Copilotからログアウトして再起動すると回復します。

これはクリーンなユーザープロファイルからも再現するため、設定の蓄積による破損ではありません。Positronで両方を使っているなら答えはこれで、Codexを何度再インストールしても解決しません。

ネット上で出回っている対処法のうち、効かないのはどれか

3つあり、最も人気のあるものはログイン状態と引き換えに何も得られません。

GitHubスレッドとその周辺の検索結果で3つの提案が広く出回りました。3つとも、飛ばしてよいと知るためにこそ知っておく価値があります。

~/.codex/auth.json を削除する。 最も多く繰り返された提案です。拡張機能が実際に認証まわりの処理で止まるため直感的に筋が通り、最初に投稿した人は成功を報告しました。しかし試した他の人は何も得られず、ワークスペースを変えた途端にエラーが戻ったという報告もありました。コイントスと引き換えにセッションを失います。ウォッチドッグはハンドシェイクのタイムアウトで発火したのであり、認証ファイルを消してもwebviewの描画は速くなりません。

data:font/woff2 のCSP警告を追う。 最初のissue報告には、ChromeのCSPがインラインのbase64フォントをブロックしているコンソール行が含まれており、決定的証拠のように読めます。違います。この警告は問題なく起動するウィンドウでも出ます。スレッド後半の診断作業が、これがブロッカーではないと確認しています。

startup.whenReady() をwebviewバンドルからパッチで取り除く。 これは他の2つより敬意に値します。提案者は実際の作業をしましたし、実際に助かった人もいました。しかし機構の理解は誤りで、先に引用した実際の行がそれを示しています。N.startup == null はVS Codeビルドでは真であり、whenReady() はそこではデッドコードです。パッチはアセットグラフを再生成した副作用として効きました。これを適用したなら、更新後は元に戻してください。拡張機能ディレクトリ内の手編集されたバンドルは、次の自動更新で黙って置き換えられます。加えて、書き換えの過程で非ASCII文字が壊れると（あるPowerShell実装がWindowsのANSIコードページ経由でこれを踏みました）、動くパネルではなく構文エラーが手に入ります。

Codex拡張機能の障害タイムライン：26.803の回帰

最初の報告から修正出荷まで6日間、6つのビルドにまたがりました。

このタイムラインで特筆すべき点が1つあります。このissueには windows-os のラベルが付いており、最初の報告も確かにWindowsでした。しかしスレッドが集めた確認報告は、macOS、Debian 13、Remote-SSH経由のUbuntu、WSL2、そしてFirefox上のVS Code Webに及びます。Windowsではないからとこのバグを切り捨てたなら、そのラベルに誤導されたことになります。

特定のバージョンへロールバックする方法

いますぐ 26.727.40816 が必要なら、拡張機能パネルは使わないでください。歯車メニューの「Install Another Version」は、元のissueを起票した人が失敗した経路で、エラーは Error while downloading VSIX: Canceled でした。CLIのほうが確実で、1行で済みます：

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.

そのうえで、この拡張機能だけ自動更新を切ってください。さもないと次のバックグラウンド更新が1日以内にロールバックを取り消します。拡張機能パネルでCodexを右クリックし、Auto Update のチェックを外します。

再び前へ進むには、バージョン指定なしでインストールします：

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

ログの実際の置き場所

GitHubスレッド全体で参照されている Codex.log はウィンドウ単位で、タイムスタンプ付きディレクトリの下に埋まっています。多くの報告者がログではなくパネルのスクリーンショットを貼った理由もこれです：

VS Codeのセッションごとに新しいタイムスタンプ付きディレクトリが作られるので、更新時刻でソートして最新を取ってください。同じ内容へのより速い経路は出力パネルです。Cmd/Ctrl+Shift+U を押し、ドロップダウンから Codex を選びます。

拡張機能ホストにまったく到達しない故障、特に原因4では、拡張機能のログに有用な詳細は残りません。コマンドパレットから Developer: Open Webview Developer Tools を開き、Consoleタブで Preserve log を有効にしてウィンドウをリロードしてください。そこに出る最初の赤いエラーが読む価値のあるものです。スレッドが最終的にレンダラー側の構文エラーを特定できたのはこの手順によるもので、Codex.log をいくら読んでも表には出てきませんでした。

エディタのパネルが起動しない間、どうやって作業を続けるか

CLIを使ってください。独立したバイナリであり、上記5つの原因のどれも触れません。

上記の原因はすべてVS Codeのwebview層にあり、エージェント本体には触れていません。拡張機能の再インストールに追われている間に多くの人が見落とすのはここです。パネルはクライアントの1つに過ぎず、唯一のクライアントではありません。

Codex CLIは別のプロセスモデルを持つ独立したバイナリです：

codex --version
# codex-cli 0.147.0

これが応答するなら、サイドバーが何をしていようと動作するCodexが手元にあります。逆も同様で、だからこそ何かをデバッグし始める前に上の表を実行する価値があります。壊れたパネルと壊れたCLIは、ほぼ決して同じ事故ではありません。

タイムラインが露呈させた2つ目のギャップもあります。修正は2026-08-13にVS Code Marketplaceへ届きましたが、OpenAIは、レジストリ側のパッケージサイズ上限（2026年3月からオープン）が未解決のため、Windows版パッケージが現在Open VSXに公開されていないと述べています。MarketplaceではなくOpen VSXから取得するエディタ（複数のVS Codeフォークを含みます）は、Windowsユーザーに修正前のビルドを提供し続けている可能性があります。そうしたエディタを使っていてバージョン表が 26.803.x を示し、更新も出てこないなら、理由はこれです。

2つのギャップは同じ形をしています。モデルへのアクセスが、1社のクライアント、1社のリリーススケジュール、1社のレジストリを経由して仲介されているということです。Codex CLIはOpenAI互換のHTTPを話すので、別のエンドポイントに向けるのは環境変数2つで済みます：

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

これで拡張機能がダウンしている間もターミナル側の経路は動き続けます。壊れたのが拡張機能でも、レジストリでも、地域別ロールアウトでも、設定は同じです。環境変数を使いたくない場合の設定ファイル版はカスタムモデルプロバイダの設定が扱っており、今週出荷されたのがどのビルドのプラグインかに依存しないフォールバックが欲しいなら、ofox が現行のCodex互換モデルを1つのキーで提供しています。

修正が本当に適用されたかをどう確認するか

まずバージョン番号を見て、バージョン番号ではなく証拠が欲しければバンドルをgrepしてください。 情報量の少ない順に3つの確認方法です。

バージョンを確認する。 このページ冒頭の表です。26.810.x 以降は修正を含みます。

文字列を確認する。 バージョン番号を信じるのではなく、手元のビルドでウォッチドッグが実際に消えていることを確認したいなら、エラー文言は拡張機能ホストのバンドルにあります：

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

インストール済みのコピーごとに <パス>:<件数> の形式で1行ずつ出力されます。件数が 0 ならそのコピーはクリーン、0以外なら影響を受けたビルドです。

ここで引っかかりやすい点が1つ。VS Codeは更新やアンインストールの際に古いディレクトリを必ずしも削除しないため、このグロブが複数のバージョンに一致し、もう使っていないビルドについても報告することがあります。裸の数字を信じるのではなく、パスからバージョンを読んでください。ロールバックと更新の両方をテストしたマシンでは、このコマンドは2行返します：

/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の出力チャネルを開き、診断の節で挙げた3つのレンダラーマイルストーン、React root render requested、app routes mounted、ready provider mounted を探します。3つとも揃っていればwebviewは最後まで起動しており、他に何が遅くともそれは別の話です。

拡張機能そのものについては、VS Code Marketplaceのページが現在のバージョンとリリース日を表示します。そこのバージョン履歴が、自分のプラットフォーム向けに手元より新しいビルドが存在するかを確認する最速の手段です。Marketplaceはプラットフォーム別パッケージを配信するため、win32-x64 と darwin-arm64 の最新バージョンが数時間ずれることがある点に注意してください。

そもそも拡張機能の問題ではない場合は？

画面上ほぼ同じに見えて、このバグではない隣接故障が2つあります。

Codexがエディタに見えない、あるいはシェルがバイナリを見つけられないなら、それはPATHとインストールの問題で、codex: command not found が扱っています。WindowsのCodexデスクトップアプリが resourcesPath に言及するapp-server manifestエラーで失敗するなら、それはネイティブホスト登録の問題で、本当に別のバグです。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