Codex could not start：VS Codeで起動しない原因を環境別に切り分け

VS CodeでCodexのパネルを開き、ロゴが出たまま約30秒待たされたあと、次の画面に変わることがあります。

Codex could not start
The extension could not start its user interface.

これは一つの不具合の名前ではありません。Codex拡張機能（拡張ID openai.chatgpt）は、パネルの画面が「準備完了」を返すまで30秒待ち、届かなければこのエラー画面に差し替えます。Codexの本体（app-server）は起動しているのに、パネルの画面だけが準備完了を伝えられていない、という状態がほとんどです。

どの原因に当たっているかは、使っている環境と、ログか開発者ツールに出る1行で決まります。2026年10月15日時点の結論は次のとおりです。

• WSLのウィンドウで、10月13日ごろVS Code 1.141.1に更新してから出始めた：VS Code側の不具合です。VS Code 1.141.2（10月14日公開、1.142.0にも同じ修正）に更新します。Codex拡張機能を古い版に戻しても直りません。
• プロキシやVPNを使っている：ネットワーク要求が応答のないまま止まると起きます。OpenAIのissueは未解決で、プロキシ側の挙動を変えるしかありません。
• Remote-SSH、Dev Container、Codexタブを複数開いた場合：それぞれGitHubのissueが開いたままで、公式の修正はありません。ユーザー報告の回避策を試し、だめならCLIで作業を続けます。

「Codex could not start」は30秒で出る共通のエラー画面

Codex拡張機能のログには、この画面が出たときに次のような行が残ります（2026年10月13日、WSL環境の報告より）。

[info] [CodexMcpConnection] Spawning codex app-server
[info] [CodexMcpConnection] Initialize received id=1
[error] [CodexWebviewProvider] Webview renderer did not become ready elapsedMs=30003 extensionVersion=26.1007.21434 reason=renderer_ready_timeout receivedWebviewMessage=false role=sidebar stage=renderer timeoutMs=30000

最初の2行は、裏で動くCodexのプロセスが起動して初期化を受け取ったことを示します。3行目は、パネルの画面（VS Codeの用語ではWebview）から30秒間一度も連絡が来なかった、という意味です。role=sidebarはサイドバーのパネル、role=panelはエディタータブとして開いた会話です。

この仕組みは、OpenAI Codexのissue #40532（Dev Containerでの報告）やissue #53738（WSLでの報告）に貼られたログと、拡張機能に同梱されたコードを報告者が読んだ結果から分かっています。OpenAIのCodexトラブルシューティングのページには、2026年10月15日時点でこのエラーの項目がありません。

同じ画面の古い版では、本文が「The extension couldn't load its resources.」でした。2026年8月の拡張機能26.803.xで多発したもので、OpenAIのCodexチームはissue #37458のコメントで、26.810.41047（プレリリース版は26.5810.41047）で30秒の監視タイマーの誤作動を直したと説明しています。同じコメントで、ネットワークや認証の問題で初期化が終わらない場合は更新後も残る、とも明言しています。いまの文言で出ている場合、拡張機能を最新にするだけでは解決しないことが多いのはこのためです。

最初に見る2か所：Codex.logとWebview開発者ツール

以下の原因と対処は、GitHubに寄せられた報告、OpenAIのCodexチームのコメント、VS Codeの修正コミットに基づいています。Windows/WSL、Dev Container、Remote-SSHのいずれの環境でも、ここに書いた手順を実際に再現して確かめたわけではありません。どの手順も、元の報告へのリンクを添えています。

原因を分ける前に、次の4つを控えておきます。

1. ウィンドウ左下の表示：WSL: Ubuntu-24.04、SSH: ホスト名、Dev Container: …のように、どの環境に接続しているかが出ます。何も出ていなければローカルです。

2. VS Codeのバージョン：「ヘルプ」→「バージョン情報」（macOSは「Code」→「Visual Studio Code について」）。

3. Codex拡張機能のバージョン：拡張機能ビューでCodexの詳細ページを開くか、ターミナルで次を実行します。リモートウィンドウでは、リモート側にインストールされた版が使われます。

   bashコピー

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

4. Codex.logの最後の数行：コマンドパレット（Windows/LinuxはCtrl+Shift+P、macOSはCmd+Shift+P）でDeveloper: Open Extension Logs Folderを実行し、openai.chatgptフォルダのCodex.logを開きます。「表示」→「出力」でCodexのチャネルを選んでも同じ内容が見られます。日本語表示のVS Codeでも、コマンド名は英語で検索できます。

ログにrenderer_ready_timeoutしか出ない場合は、もう1か所見ます。コマンドパレットでDeveloper: Open Webview Developer Toolsを実行し、ConsoleタブとNetworkタブを確認します。パネルの画面がCodex.logに書き込めるようになる前のエラーは、Codex.logには転送されません。ここで拡張機能のwebview/assets/にあるJSやCSSが401で失敗していれば、次の表の1行目に当たります。

ターミナルでcodex login statusを実行して「Logged in using ChatGPT」と出るなら、ログイン自体は生きています。パネルだけが起動しない、という切り分けの材料になります。

Codex VSCodeが起動しない原因は？環境ごとの状態と対処

2026年10月15日時点で、同じ画面が出る原因として報告されているものを、手がかりと状態ごとにまとめます。

Cursor・WindsurfでもCodex拡張機能は同じものですが、1行目はMicrosoftのVS Code本体の不具合です。CursorやWindsurfを使っている場合は、開発者ツールに401が出ているかどうかで判断してください。

WSLでVS Code 1.141.1に更新後に起動しない：1.141.2で修正済み

10月13日ごろから、WindowsのVS CodeでWSLのフォルダーを開いているとCodexが起動しない、という報告が続きました（issue #53738、issue #53840）。共通点は次のとおりです。

• VS Codeが1.141.1に自動更新された直後から出始めた。
• 開発者ツールで、~/.vscode-server/extensions/openai.chatgpt-26.1007.21434-linux-x64/webview/assets/以下のJS・CSSが401で拒否されている。
• Codex.logではapp-serverが起動し、codex login statusも正常。
• Windows上で普通に（WSLに接続せず）VS Codeを開くとCodexは動く。

原因はCodexではなくVS Codeにあります。1.141.1で入ったコミットが、ウィンドウ左下に出るWSL: Ubuntu-24.04のディストリビューション名に大文字が含まれると、パネルの画面が読み込むファイルを401で拒否するようになっていました。影響はCodexだけでなく、Markdownプレビューや他の拡張機能のパネルにも及んでいます（VS Codeのissue #341475）。

MicrosoftはVS CodeのPR #341508「webview: fix mixed-case remote resource authorities」でこれを修正し、1.141.2（2026年10月14日公開）に入れました。1.141.1と1.141.2の差は、この修正とバージョン番号の変更だけです。同じ修正は1.142.0（同日公開）にも入っています。VS Codeのissue #341396には検証済み（verified）のラベルが付いています。一方、Codexのissueには、2026年10月15日時点で「1.141.2で直った」というCodexユーザーの書き込みはまだありません。

対処は次の順です。

1. Windows側のVS Codeで「ヘルプ」→「更新の確認」を実行し、1.141.2以降にして再起動します。WSL側のVS Code Serverは、接続し直すと同じバージョンに合わせて入れ替わります。
2. 更新後もパネルが開かない場合は、開発者ツールを開き直して401が消えているかを確認します。401が消えてもタイムアウトする場合は、別の原因（表の2行目以降）を疑います。

ある報告者の試行結果は、この分岐でやっても無駄な作業を示しています。VS Code 1.141.1のままCodex拡張機能を26.1002.51308に戻しても同じエラーが出続け、VS Code本体を1.141.0に戻したときだけ直りました。別の報告者は、拡張機能とVS Code Serverの再インストール、キャッシュ削除、新しいプロファイルまで試して直っていません。

更新できないときの回避策：小文字の名前でWSLを開く

1.141.1のまま使い続ける必要がある場合は、ユーザーが報告した回避策があります。WSLのUbuntu内でcode .を実行するとwsl+Ubuntu-24.04という大文字入りの名前で開かれて失敗しますが、PowerShellから小文字の名前を指定して開くと読み込めた、というものです。

wsl -l -v
code --new-window --remote wsl+ubuntu-24.04 /home/YOUR_USER/project

wsl -l -vで自分のディストリビューション名を確かめ、それを小文字にして指定します（Ubuntuならwsl+ubuntu）。名前の部分は環境ごとに違い、報告者以外の名前での動作は報告されていません。WSLのターミナルから同じことをするなら、PowerShell経由で呼び出します。

powershell.exe -NoProfile -Command "code --new-window --remote wsl+ubuntu-24.04 '$PWD'"

もう一つの選択肢は、WSLのウィンドウを使わない方法です。Codex拡張機能にはchatgpt.runCodexInWindowsSubsystemForLinuxという設定があり、OpenAIのCodex IDE拡張機能の設定一覧では「WSLがあればCodexをWSLで実行する（Windowsのみ）」と説明されています。VS Code自体はWindowsで動かし、Codexの実行だけをWSLに任せる形です。issue #53840の報告者は、この設定でWSL内のコマンド実行ができたと書いています。設定を変えるとVS Codeが再読み込みされます。

プロキシ・VPN環境で30秒止まる：アカウント確認の待ちは未解決

プロキシやVPNを通していると、Codexの起動時に行うアカウント確認の通信が終わらず、30秒でエラー画面になることがあります。issue #37521の報告者は、通信の失敗の仕方で結果が3通りに分かれることを示しました。

つまり、通信が「失敗する」なら起動し、「止まったまま返らない」と起動しません。別の報告（issue #38088、Windows、VPNが127.0.0.1:8080にプロキシを登録する環境）では、プロキシなしで約9秒の起動が、プロキシありでは約27〜30秒、一度は約3分半かかっていました。

OpenAIのCodexチームは2026年8月13日、監視タイマーの修正はアカウント確認に期限を付けるものではないとして、issue #37521を開いたままにしています。拡張機能専用のプロキシ設定も、OpenAIのドキュメントにはありません。報告では、拡張機能のプロセスの通信がCodexのnetwork_proxy設定を使っておらず、Node.jsのfetchは既定でHTTP_PROXY・HTTPS_PROXYを読まないことも指摘されています。環境変数を設定しても効かない可能性があるのはこのためです。

できることは、プロキシ側の挙動を変えることです。

1. VPN・プロキシを一時的に切ってVS Codeを再起動し、パネルが開くか確かめます。開けばこの分岐です。
2. プロキシがchatgpt.com、api.openai.com、ab.chatgpt.comへの接続を保留したままにしていないか、プロキシのログで確認します。正常に中継させるか、すぐに失敗を返すように設定できれば、少なくとも起動はします。
3. 社内プロキシなど自分で変えられない場合は、issue #37521を追いながら、後述のCLIで作業を続けます。

Remote-SSHで読み込みが終わらない：効果がまちまちな回避策

Remote-SSHでサーバーに接続したウィンドウでは、ターミナルのcodexは動くのにパネルだけが読み込み中のまま、または30秒後にこのエラー画面になる、という報告が2026年6月から続いています（issue #26951）。2026年10月15日時点で開いたままで、OpenAIの回答はありません。

コメント欄に出ている回避策は、どれも一人か数人が試したもので、効かなかった人もいます。手間の少ない順に並べます。

1. ローカルのユーザー設定に2項目を追加する：Windows→Ubuntuの環境で、VS Code 1.141.2への更新では直らず、ローカル（Windows側）のsettings.jsonに次を加えてVS Codeを完全に閉じ、開き直したら起動した、という報告があります（2026年10月14日）。報告者は2つを同時に入れたため、どちらが効いたかは分かっていません。

   jsonコピー

   {
     "extensions.supportNodeGlobalNavigator": true,
     "http.electronFetch": true
   }

   リモート側の設定にextensions.supportNodeGlobalNavigatorを入れるだけでは直らなかった報告もあります。

2. Codexのremote_plugin機能を切る：リモート側でcodex features disable remote_pluginを実行したらすぐ直った、という報告があります。ただし別のユーザーは、ウィンドウを再読み込みしたら再発したと書いています。

3. 一つ前の拡張機能に戻し、自動更新を止める：手順は後述のロールバックの節にあります。戻したあと最新版に上げ直しても動いた、という報告もあり、効く理由ははっきりしていません。

4. ローカルのVS Codeのキャッシュを退避する：同じissueには、ローカル環境で同じ症状になったユーザーの報告もあります。一時的なプロファイル（--user-data-dirで別フォルダーを指定）ではCodexが動いたため、VS Codeを閉じてService Workerなどのフォルダーを退避したら直った、という内容です。消す前に必ず別名で残してください。

ARM64のサーバーへの接続では、Codex.logにCodex's Linux sandbox uses bubblewrap and needs access to create user namespaces.という行が出たうえでタイムアウトした報告もありますが、この行が原因かどうかは分かっていません。

VS Code 1.141.1を使っていて、SSHのホスト名に大文字が含まれる場合は、前節のVS Codeの不具合にも当たる可能性があります。MicrosoftのPRは対象をWSLに限らず「大文字を含むリモートウィンドウ」と説明しているためです。この場合は先に1.141.2以降へ更新します。

ブラウザのないサーバーでCodexにログインする方法は、Codex CLIをSSH先・ヘッドレス環境でログイン：ブラウザなしの3経路で扱っています。

Dev Containerで起動しない：issue #40532は未解決

Dev Containerの中でCodexを使うと、拡張機能26.818.61809以降でこのエラーになるという報告があります（issue #40532、2026年8月25日、VS Code 1.134.0）。app-serverは起動し、30秒後にrenderer_ready_timeoutが記録されるという、ここまでと同じ形です。再インストールや古いVS Code Serverの削除では直らず、2026年10月15日時点でOpenAIの回答はありません。報告者は拡張機能の同梱ファイルを書き換えて回避していますが、更新のたびに元に戻るため、通常の対処には向きません。

試す価値があるのは、issue #26951に寄せられたDev Containerの報告です。同じVS Codeと拡張機能のバージョンで2つのコンテナを比べたところ、extensions.supportNodeGlobalNavigatorを設定したコンテナではCodexが起動し、設定していないコンテナではタイムアウトしました。リモート側の設定はコンテナごとに保存されるため、devcontainer.jsonに書いておくとコンテナを作り直しても残ります。

"customizations": {
  "vscode": {
    "settings": {
      "extensions.supportNodeGlobalNavigator": true
    }
  }
}

これは一人の報告者の比較で、#40532の報告者の環境で効くかどうかは分かっていません。設定後はコンテナを開き直し、出力パネルの「Log (Remote Extension Host)」からPendingMigrationError: navigator is now a global in nodejsという行が消えたかを見ると、設定が効いているかを判断できます。

Codexタブを複数開くと一部だけエラーになる

ローカルのWindowsでも、Codexの会話をエディタータブとして複数開いていると、一部のタブだけがこの画面になるという報告があります（issue #43080、2026年9月5日、拡張機能26.901.22334）。3つのタブのうち1つは表示され、2つがrole=panelでほぼ同時にタイムアウトしていました。何枚から起きるかは報告者にも分かっておらず、OpenAIの回答もありません。

ログにrole=panelのタイムアウトが並んでいるならこの形です。公式の回避策はありませんが、余分なCodexタブを閉じてから、コマンドパレットのDeveloper: Reload Windowでウィンドウを再読み込みし、会話は一つずつ開き直すのが手堅い方法です。これは報告内容からの推測で、効果が確認された手順ではありません。

Codex拡張機能のロールバックが効く場合・効かない場合

拡張機能を古い版に戻すのは、その版の拡張機能自体が原因のときだけ効きます。2026年8月の「couldn't load its resources」はそれに当たりましたが、VS Code 1.141.1のWSLの不具合では効きませんでした。

2026年10月15日時点で、VS Code Marketplaceの安定版は次のとおりです。版は週に何度も変わります。

26.51007.21434のように2つ目の数字が5で始まる版はプレリリース版です。プレリリース版を使っているかどうかも、拡張機能の詳細ページで確かめておきます。

戻す方法は2つあります。

• 画面から：拡張機能ビューでCodexを開き、「アンインストール」の横の▼から「別のバージョンをインストール...」を選びます。

• コマンドで：

  bashコピー

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

どちらの場合も、同じ詳細ページの歯車アイコンから自動更新を切っておかないと、VS Codeを再起動したときに最新版へ戻ります。WSLやRemote-SSHのウィンドウでは、拡張機能はリモート側に入っている版（linux-x64など）が使われるので、そのウィンドウの中で操作します。

「拡張機能を最新にしても直らない」場合は、原因が拡張機能の版ではない可能性が高いと考えてください。VS Code本体のバージョン、プロキシ、接続先の環境のほうを先に疑います。拡張機能の導入や設定そのものを見直したいときは、VS CodeでCodexを使う：APIキーと外部モデルの安全な設定を、Cursorで使っている場合はCursorでCodex IDE拡張機能を使う：初回タスクと差分確認までを参照してください。

ターミナルのcodexは動くのにパネルだけ起動しない：CLIで続ける

WSL、Remote-SSH、Dev Containerのどの報告でも、パネルが起動しない間、ターミナルのcodexコマンドは動き続けていました。同じウィンドウの統合ターミナルでcodexを起動すれば、同じフォルダーで作業を続けられます。CLIはパネルと認証やネットワークを共有しているので、必ず動くとは限りませんが、修正を待つ間の手段としては最も手軽です。CLIがまだ入っていない場合は、Codex CLIのインストールと設定：Windows・macOS・Linux対応の手順で入れられます。

パネルが開いたあとに401や429、「stream disconnected」が出る場合は、起動の問題ではなく、リクエストのどこで失敗したかの問題です。Codexの401・429・Stream Disconnected：失敗した層を見つけるで切り分けられます。

どの分岐にも当てはまらない場合は、Codex.logの最後の数行、開発者ツールのConsoleのエラー、VS Codeと拡張機能のバージョン、ウィンドウ左下の接続先を添えて、最も近いissueにコメントするか新しいissueを立てます。パスやアカウント名は伏せてから貼ってください。