Codexエラーの切り分け｜0.150.0更新後の復旧手順と確認点

Codexエラーを設定ミスと決める前に

Codexで表示されるエラーは、利用者の設定、アプリやCLIの版、WindowsとWSLの接続経路、会話を保存している場所のどこかで起きた結果です。画面に「設定を確認してください」と出ても、設定ファイルの記述が直接の原因とは限りません。アプリが起動時に読み込んだ情報、同梱された実行部分、WSL側へ渡した作業の場所が組み合わさり、エラーとして表面化することがあります。まずは直す場所を決める前に、どの操作で、どの入口から、どの版を使い、どの会話で起きたかを一行にまとめます。

同じ端末にCodex Desktopと単体CLIが入っている場合、両者は同じ名前のCodexでも別の版や設定を読むことがあります。新しい会話は開けるのに、過去の会話だけ再開できないなら、認証やモデルの問題よりも、保存された会話と現在の経路の組み合わせを優先して調べます。逆に、最初の入力から失敗するなら、入口、版、ログイン状態、接続を先に分けるほうが近道です。

エラー文は原因ではなく観察結果

「invalid transport」「Failed to resume chat」「Model not found」のような文は、処理がどこまで進んだかを示す手がかりです。文面だけで原因を一つに確定するものではありません。たとえば設定ファイルを直すよう求められても、アプリが別の設定を一時的に組み立てていたなら、ファイルを編集しても結果は変わらない可能性があります。エラー全文、発生した操作、直前に変えたものを同じ記録へ残し、表示の指示と原因の仮説を分けて扱います。

2026年8月26日の報告が示すこと

今回の時事フックは、OpenAI公式リポジトリに2026年8月26日付で登録されたWindows・WSLの報告です。報告の環境には、Microsoft Store版のCodex Desktop、Windows 11、WSL2、同梱された0.150.0-alpha.8、以前に作られたスレッドが含まれています。症状は、WSL上のスレッドを再開したときに設定を読み込めないという表示が出ることです。これは同じ条件の利用者が照合できる具体例であり、全環境の仕様変更や修正完了を意味するものではありません。

直近の更新とエラーを混ぜない

新しい版が公開された日にエラーが出ると、更新が必ず原因だと考えたくなります。しかし、版の公開、アプリへの同梱、既存スレッドの保存形式、WSLへの接続経路は別の出来事です。更新前から作られた会話を更新後に再開したのか、更新後に作った新しい会話でも失敗するのかを分けてください。この差を記録しておけば、版を戻すべきか、経路を一時的に変えるべきか、公式の修正を待つべきかの判断が安定します。

2026年8月26日のWindows・WSL報告を読む

Issue #40819は、WindowsでCodexを使う人が今回のエラーを照合するための重要な資料です。本文によれば、WSL上で作成したスレッドをCodex Desktopから再開しようとしたとき、ChatGPT can't load config.tomlと表示され、その後にinvalid transport in mcp_servers.codex_appが示されました。報告者が確認した範囲では、アプリがスレッド再開時に渡す設定に、接続方法を示す情報がない状態が生じ、Codex側が受け付けなかったと説明されています。

この情報から利用者が安全に言えるのは、少なくとも「Windows・WSL・Codex Desktop・特定の同梱版・既存スレッド再開」という条件がそろうと、設定ファイルを編集する前に確認すべき経路がある、ということです。報告本文にある回避方法も、すべてのWindows環境へ適用できる修正版ではなく、WSL経路を一時的に外して症状を比べるための判断材料として読みます。

invalid transport が示す場所

invalid transportは、Codexが補助的な接続先を読み取ったものの、どの方法で接続するかを判断できないときの表現です。今回の報告では対象名がmcp_servers.codex_appまで示されているため、モデル名や通常の入力内容より、アプリとWSLの間で渡されたCodexアプリ用の設定を優先して確認します。エラーの対象名を省略して「WSLが壊れた」「config.tomlが壊れた」と一般化しないことが大切です。

config.tomlを先に壊さない

Issue #40819では、利用者のconfig.tomlが問題の本体ではなく、アプリがメモリ上で組み立てた情報がWSL経路で変わった可能性が説明されています。したがって、最初に設定ファイルを削除したり、項目を推測で書き換えたりするのは避けます。編集前に現在の内容を別の場所へ控え、変更を加えずに同じスレッドをWindows側で開けるか、新しいスレッドだけは使えるかを確認すると、戻すべき情報を残せます。

公開報告から断定できないこと

公開Issueは、版、OS、再現条件、ログを共有する場所です。Issueが公開されていることは、自分の症状と比較できるという意味であり、すべての環境で同じ不具合が起きるという意味ではありません。また、報告本文に回避方法があっても、それが正式な修正や恒久的な推奨設定とは限りません。自分の版と経路が報告と一致するかを先に比べ、一致しない部分も記録してから回避策を試します。

Codexエラーを4つの軸で記録する

復旧を急ぐほど、情報を一つの「動かない」にまとめてしまいがちです。今回のようなCodexエラーでは、入口、版、会話、経路の四つを別々に書くと原因候補を広げずに済みます。記録は長い日誌にする必要はなく、同じ操作をもう一度したときに比較できる程度で十分です。変更を加える前の状態を残しておけば、回避策を試した後に元の条件へ戻せます。

入口を固定する

Codex Desktop、単体CLI、IDE拡張、ブラウザーのCodexでは、表示される画面が似ていても、利用する版や接続先が異なる場合があります。エラーが出た入口を「Codex」とだけ書かず、Desktopなのか、WSLの端末から起動したCLIなのか、IDE内の拡張なのかを記録します。Windows側のアプリからWSLのスレッドを開いた場合は、操作した画面と、実際に作業した場所の両方を書いてください。

版番号を固定する

CLIではcodex --versionを使い、アプリではAbout画面などに表示される番号を控えます。同じ端末に複数のCodexがある場合は、単体CLIの番号だけでアプリの同梱版を判断しません。今回のIssueにはDesktop 26.820.7780.0と同梱ランタイム0.150.0-alpha.8が記録されています。アプリ版、同梱版、以前のスレッドを作った版が分かるなら、三つを混ぜずに別欄へ残します。

会話の状態を分ける

新しい会話、現在進行中の会話、以前に作ったスレッドの再開は、同じ入力を送っているようでも処理が違います。新しい会話は成功し、過去のスレッドだけ失敗するなら、保存済みの履歴や作業場所の参照が関係している可能性があります。逆に新しい会話の最初から失敗するなら、会話固有の問題と決めず、入口と版、ログイン状態、接続を確認します。

経路を一つずつ書く

Windowsのファイルを使ったのか、WSL2のファイルを使ったのか、DesktopがWSLへ処理を渡したのかを記録します。Windows側のプロジェクトを開いているつもりでも、設定によってWSL側のCodexが動くことがあります。config.tomlの場所も、Windows側とWSL側で別に見える場合があるため、ファイルを直す前に、どの環境から読み込まれた設定なのかを確認してください。

Windows・WSLでの確認手順

ここからは、今回の症状を安全に切り分ける順番です。目的は、すぐに設定を変えて直すことではなく、問題がアプリ版、WSL経路、既存スレッド、設定ファイルのどこにあるかを狭めることです。各段階で結果を記録し、成功した場合も「何を変えたから成功したのか」を残します。複数の項目を同時に変更すると、次に同じエラーが出たときの比較材料がなくなります。

Step 1: 入口と版を記録する

最初にCodex Desktopか単体CLIかを決め、アプリ版とCLI版をそれぞれ控えます。Windows側の画面でWSLのプロジェクトを開いているなら、WSL2のディストリビューション名と、作業対象の場所も記録します。CLIの場合は次の確認を読み取りだけで行い、結果を保存します。

codex --version

ここで更新を始める必要はありません。現在の番号が公式のリリース一覧にある安定版か先行版かを後から照合できるようにし、アプリに同梱された番号と別のCLIの番号を一つの値として扱わないことが重要です。

Step 2: エラー全文を保存する

画面の「エラー」だけを写さず、前後の文を含めて保存します。今回なら、ChatGPT can't load config.toml、invalid transport in mcp_servers.codex_app、スレッドを再開した操作、発生時刻を同じ記録に置きます。個人の会話内容や認証情報は共有せず、問題の対象名、版、OS、経路だけを残します。再現しなかった場合も「同じ操作で成功」と書くと、条件の差を比べやすくなります。

Step 3: WSL経路の有無を確認する

同じプロジェクトで、Windows側のCodex経路とWSL側のCodex経路が別れていないかを調べます。Issue #40819のようにWSL上のスレッド再開だけで出る場合、通常のWindows側の新しい会話で同じエラーが出るかを分けて試します。ここではファイルを編集せず、読み取り中心の短い確認を行います。Windows側では開けて、WSL側だけ失敗するなら、モデルや入力よりも経路の差を優先して扱います。

Step 4: 新しい会話と既存スレッドを分ける

新しい会話を一つ開き、短い読み取り依頼が通るかを確かめます。成功したら、次に既存スレッドの再開を一度だけ試します。新しい会話まで失敗する場合は、既存スレッド固有の問題と決めつけず、版、ログイン、接続、利用状態へ戻ります。既存スレッドだけが失敗する場合は、元の会話を何度も開き直すより、タイトルや識別子を控えてから、公式Issueと条件を比較してください。

Step 5: 変更は一項目に絞る

版を変える、WSL経路を外す、設定ファイルを変える、別の会話を使うという四つを同時に行わないでください。まずは版とエラーを記録し、次に経路だけを変え、結果を見ます。改善しなければ元の経路へ戻してから、別の一項目を確認します。復旧したように見えても、元のスレッド、別の新規スレッド、Windows側とWSL側の三つを分けて再確認すると、偶然の成功を修正済みと誤認しにくくなります。

invalid transport 発生時の復旧手順

WSL上の既存スレッドを再開したときにinvalid transport in mcp_servers.codex_appが出るなら、まず今回のIssueと自分の条件を比べます。Windows 11、WSL2、Codex Desktop、アプリの更新後、過去に作ったスレッドという条件が重なるほど、設定ファイルを削除する前に経路を一時的に変える価値があります。ただし、以下はIssueに記載された回避の考え方であり、すべての版や構成で成功する保証ではありません。

Step 1: 変更前の状態を残す

Codex Desktopを閉じる前に、アプリ版、同梱版、WSL2の利用有無、エラー全文、対象スレッドの名前を控えます。config.tomlを編集する可能性がある場合は、現在のファイルをそのまま別名で保存し、変更前の内容を戻せるようにします。会話の履歴を削除したり、設定を初期化したりする操作は、原因が分からない段階では行いません。戻せない操作を避けることが復旧手順の第一歩です。

Step 2: 設定ファイルを推測で書き換えない

今回の公開報告では、アプリがWSL経路で渡す情報が問題となり、利用者の設定ファイルそのものが壊れているとは説明されていません。mcp_servers.codex_appを手入力で追加したり、接続先の項目を推測で補ったりすると、別のエラーを重ねるおそれがあります。まずはファイルを読み、現在の記述を保全します。設定を変える必要があると判断した場合も、追加する項目、理由、戻し方を記録してから一つだけ変更します。

Step 3: WSLを使わない経路で比べる

Issue #40819には、Windows側の経路を使うために、デスクトップ設定のWSL利用を一時的に無効にして比べる回避方法が記載されています。設定の書き方は利用している版や画面で異なるため、現在の公式案内と自分の設定画面を確認してください。設定ファイルで管理している場合の概念は次のとおりです。

[desktop]
runCodexInWindowsSubsystemForLinux = false

この変更はWSL側のスレッドを修正するものではなく、処理する経路をWindows側へ切り替えて結果を比較するためのものです。作業場所や読み込まれるファイルが変わる可能性があるため、重要な変更を続けず、まず短い確認で差を見ます。

Step 4: 新規会話で復旧を確認する

設定を保存してCodex Desktopを再起動したら、いきなり元の重要なスレッドを続けません。まず新しい会話を開き、対象ファイルを変更しない短い依頼が通るかを確認します。その後、元のスレッドを一度だけ再開します。新規会話は成功して既存スレッドだけ失敗するなら、処理経路は改善したものの、履歴側に条件が残っている可能性があります。結果を分けて記録し、成功したからすべて直ったとは判断しません。

Step 5: WSLへ戻す判断を分ける

Windows側の経路で問題が出なくても、すぐにWSL設定を元へ戻して長い作業を始める必要はありません。Issueの更新、Codexのリリース説明、自分の新規会話と既存スレッドの結果を確認し、戻す理由があるかを決めます。WSLが必要な作業なら、まず重要度の低い作業場所で再確認し、戻す前後の版と設定を残します。回避できたことと、原因が修正されたことは別です。

Failed to resume chat と別ウィンドウの症状

Codex Desktopで「Failed to resume chat」が出る場合、WSLのinvalid transportと同じ原因だとは限りません。OpenAI公式リポジトリのIssue #40955には、同じタスクを二つのデスクトップウィンドウで開き、一方で停止、過去のメッセージを編集して送信した後、もう一方のウィンドウで再選択すると、古い履歴を参照して再開に失敗する報告があります。エラー文が似ていても、発生した操作を先に比べてください。

Step 1: 同じタスクを複数画面で開いたか確認する

別ウィンドウや別画面で同じタスクを開いていた場合、どの画面で停止したか、どの画面で過去のメッセージを編集したかを記録します。Issue #40955の報告では、停止後に以前のメッセージを編集して送信すると、同じスレッド番号を保ったまま参照する履歴が置き換わり、もう一つのウィンドウが古い場所を持ち続ける状況が説明されています。二つの画面を同時に操作したかどうかが、WSLを使っていない環境でも重要な分岐になります。

Step 2: 古い画面を何度も再読み込みしない

別画面で空の計画が表示されたり、同じ再開エラーが繰り返されたりする場合、再選択を何度も行う前に元の画面とタスク名を控えます。元の画面で現在の履歴が表示されるなら、そこから必要な結果を保存し、古い画面を閉じて一つの画面で再確認します。これはIssueにある履歴の食い違いと自分の症状を比べるための一時的な扱いであり、正式な修正方法と断定しません。

Step 3: Stop・編集・送信の順番を残す

エラーが出たときは、停止したか、以前の入力を編集したか、編集後に送信したか、別画面で同じタスクを開いていたかを順に書きます。単に「会話を再開できない」と記録するより、操作の順番があれば公式Issueとの照合が容易です。編集前の履歴を保ちたい場合は、重要な作業を複数画面で同時に扱わず、一つの画面で現在の状態を確認してから次の入力へ進みます。

Step 4: 修正版が明記されているかを見る

公開Issueが存在することや、リリース番号が新しいことだけで、履歴の食い違いが修正済みとは判断できません。Issue本文、関連する変更説明、現在のアプリ版を一緒に確認し、修正内容と適用版が書かれているかを見ます。明記がない場合は、再現条件を避けて一つの画面で作業を続ける、別の新規会話で確認する、公式の更新を待つという判断を分けて記録します。

版番号と公式更新をどう照合するか

2026年8月下旬は、Codexの安定版と先行版、Desktopの同梱版、アプリ間の接続方法が同時に動いています。OpenAI公式のCodexリリース一覧で安定版と先行版を区別し、手元の番号と照合してください。先行版の番号が大きくても、既存スレッドの復旧に適しているとは限りません。エラー解消を目的に版を替える場合は、変更前の版へ戻せる状態を作り、別の条件を混ぜないことが重要です。

安定版と先行版を分ける

リリース一覧には、日常利用の基準にしやすい安定版と、検証向けの先行版が別の表示で並びます。Issue #40819や#40955に出てくる0.150.0-alpha.8は、Desktopに同梱されたランタイムの情報として読む必要があり、単体CLIを同じ番号へ更新した証拠ではありません。アプリの版とCLIの版を別々に記録し、片方が直った結果をもう片方へそのまま当てはめないでください。

8月24日のMCPサーバー変更を読む

OpenAIの公式リリースノートは、2026年8月24日にcodex mcp-serverを非推奨とし、Codex App Serverを使う方向を案内しました。これは、過去にMCPサーバーとしてCodexを呼び出していた人が移行を検討するための告知であり、今回のWindows・WSLエラーがすべてこの変更で起きたという説明ではありません。ただ、mcp_servers.codex_appという対象がエラーに含まれる場合は、利用している入口と接続方法が現在の公式案内と一致しているかを確認する価値があります。

App Serverの役割を公式記事で確認する

OpenAIのApp Server解説では、Codexの各画面が共通の処理基盤を使い、App Serverがクライアントと処理の間で双方向の情報を渡す仕組みとして説明されています。ここから分かるのは、Desktop、IDE、CLIなどの画面が見た目だけでなく、会話の状態や承認、設定の受け渡しでも結び付いていることです。だからこそ、エラーが出たときはモデルだけでなく、入口、同梱版、スレッドの状態、WSL経路を一つの組み合わせとして確認します。

よくあるCodexエラーとの違い

Codexエラーを一つの言葉で扱うと、今回のWSL再開エラーと、ログインやモデル名の問題を取り違えます。画面に数字や英語の短い文が出たら、まず番号、対象名、発生した操作を分けます。番号は最初の手がかりであって、すべての原因を決めるものではありません。特にアプリとCLI、通常の会話と既存スレッドをまたいで比べるときは、入口をそろえた結果だけを比較します。

401・403はログインと利用許可を先に見る

401や403が出る場合は、現在どのアカウントでログインしているか、利用しているプランや組織で対象機能が使えるかを確認します。Codex Desktopで過去のスレッドを開けないからといって、今回のinvalid transportと同じ経路問題だと決める必要はありません。ログインをやり直す前に、エラー全文と入口を保存し、アカウントを変えた場合は変更した時刻も記録すると、認証状態の差を追いやすくなります。

404は対象名と処理経路を確認する

404やModel not foundなら、選択したモデル名、現在の版、利用している接続先を確認します。長い会話の整理や既存スレッドの再開にだけ出る場合は、通常のモデル選択ではなく、処理経路や履歴の状態が関係している可能性があります。新しい短い会話で同じモデルが使えるかを比べ、モデル、会話、経路の三つを同時に変更しないことが大切です。

429は利用量と時間を確認する

429や上限を示す表示なら、短い時間に集中して使ったか、契約中の利用枠に達していないかを確認します。時間を置けば戻る症状に対して、設定ファイルを初期化したり、WSL経路を変えたりする必要はありません。逆に、時間を置いても特定の既存スレッドだけ失敗するなら、利用量の問題とは分けて、会話状態と発生操作を記録します。

番号がない場合は画面と処理を分ける

画面が固まる、応答が途切れる、再開ボタンだけが反応しないという症状には、番号付きエラーが隠れている場合と、画面側の状態だけが止まっている場合があります。ターミナルやアプリのログに残る文を確認し、表示が止まった時刻と最後に成功した操作を控えます。「Codexが動かない」と一括りにせず、どの画面で、どの会話を、どの操作から続けられないのかを分けてください。

復旧後に同じCodexエラーを再発させない確認

エラーが消えた直後は、すぐに元の長い作業へ戻りたくなります。しかし、今回のように新規会話と既存スレッドで結果が違う場合、短い成功だけでは十分ではありません。復旧後は、変更した項目、成功した入口、成功した会話、まだ試していない経路を整理します。成功の条件を残しておけば、次回の版更新で同じエラーが出たときに、前回との違いをすぐ比べられます。

成功条件を三つに分ける

まず新規会話で短い読み取り依頼が通るか、次に重要度の低い既存スレッドを再開できるか、最後に本来のWSL作業場所で問題が出ないかを別々に確かめます。三つすべてが成功して初めて「自分の条件では戻った」と判断します。いずれか一つだけ成功した場合は、その範囲を記録し、他の範囲が未確認であることを明記します。こうすれば、復旧の報告が過大になりません。

変更した設定を一つずつ戻す

WSL経路を外して改善した場合、すぐに複数の設定を戻さず、一つだけ戻して短い確認を行います。戻した時点で再発するなら、原因候補は経路へ絞れます。戻しても再発しないなら、アプリ版やスレッド状態など別の条件を比べます。設定を戻す順番と結果を残しておくと、次に同じ版を使う人が、推測ではなく実測をもとに判断できます。

公式更新と自分の結果を照合する

OpenAI公式リリースノートやCodexリリース一覧に修正内容が追加されたら、版番号だけでなく、修正対象と自分の発生条件を比べます。WSL、既存スレッド、Desktopの同梱版が修正対象に含まれるかを確認し、含まれない場合は「最新版だから直る」とは考えません。更新後に同じ記録欄で再試行し、エラー文が消えたのか、別の文へ変わったのかも残すことが大切です。

問い合わせやIssue報告に残す情報

自分で切り分けても解消しないときは、再現条件を短く整理して公式の窓口や公開Issueへ相談します。会話の本文を大量に貼るより、版、OS、入口、発生操作、エラー全文、成功した条件をそろえるほうが、同じ症状の比較に役立ちます。認証情報や業務上の内容は含めず、問題の再現に必要な技術情報だけを残してください。

Step 1: 環境を書く

Windowsの版、WSL2の有無とディストリビューション、Codex Desktopの版、同梱ランタイムの版、単体CLIを使った場合の版を分けて書きます。アプリをMicrosoft Storeから入れたのか、別の導入経路なのかも、分かる範囲で記録します。版が不明なら「不明」と書き、推測で埋めないことが重要です。

Step 2: 操作の順番を書く

新規会話を作ったのか、既存スレッドを再開したのか、別ウィンドウで同じタスクを開いたのかを先に書きます。その後、停止、過去メッセージの編集、送信、再選択など、エラー直前の操作を順番に並べます。操作の順番が分かれば、Issue #40819のWSL再開型か、Issue #40955の履歴食い違い型かを比較しやすくなります。

Step 3: 成功した条件も書く

Windows側の新規会話は成功した、WSL側の既存スレッドだけ失敗した、WSL設定を外すと新規会話は成功した、というように、直った条件も書きます。失敗の情報だけでは原因候補が広がりますが、成功と失敗の差があれば、入口や会話状態を絞れます。再現しない場合も、何回試して何回成功したかを無理に断定せず、試した範囲として記録してください。

Step 4: 公式URLを添える

照合した資料として、Issue #40819、Issue #40955、Codexリリース一覧、OpenAI公式リリースノートを添えます。どの記述を参考にしたかを分けて示せば、報告者と確認者が同じ条件をたどれます。公式資料にない推測は、事実と混ぜずに「可能性」として明記します。

まとめ

Codexエラーの復旧で最初に行うのは、設定ファイルの初期化や再インストールではなく、入口、版、会話、経路を固定することです。2026年8月26日のOpenAI公式リポジトリIssue #40819は、Windows 11とWSL2、Codex Desktop、同梱0.150.0-alpha.8、既存スレッドの再開という条件でinvalid transport in mcp_servers.codex_appが出た例を記録しています。自分の条件が一致するかを比べてから、設定を変更します。

同じ日に近い「Failed to resume chat」でも、別ウィンドウで同じタスクを開き、停止後に過去の入力を編集して送信したことが関係する報告があります。WSLの経路エラーと会話履歴の食い違いを分け、新規会話と既存スレッドを別々に確認してください。WSL経路を一時的に外す回避を試す場合も、それで原因が修正されたとは決めず、版と設定を戻せる状態を保ちます。

8月24日の公式リリースノートでは、codex mcp-serverからCodex App Serverへ移る方向が示されています。更新の多い時期ほど、安定版と先行版、Desktopの同梱版、単体CLIを混ぜずに記録することが重要です。エラー全文、発生操作、成功した条件、照合した公式URLを残しておけば、利用者側で直せる問題と、公式の修正を待つ問題を落ち着いて判断できます。