Codexの「thread not found」は、履歴が残っていても出るエラーで、会話が消えたとは限りません。履歴は消さずに、同じタスクの開き直し→アプリの完全な再起動→短い確認文の送信、の順に試します。保存先のエラー（os error 2 など）も出ている場合は別の対処になります。
最初に見るのは、エラーの続き
履歴を消す前に、症状を分ける
thread not found
保存先の参照エラー（履歴は読めることも多い）
Timeout・App server request expired while queued
目次
1. thread not foundは何が見つからないのか
OpenAIのCodexで既存タスクに続きを送ったとき、次のようなエラーが出ることがあります。後ろのIDは対象の会話を識別するもので、以下では伏せています。
メッセージの送信中にエラーが発生しました
thread not found: <対象の会話ID>英語表示のアプリでは、1行目がError submitting messageになります（#30710）。
Error submitting message
thread not found: <conversation ID>この記事はデスクトップアプリの既存ローカルタスクが対象です。私たちの環境（Windows）で起きた例のログ、公開ソース、利用者の不具合報告をもとに、2026年9月21日時点で整理しています。
「読める」と「送れる」は、別の確認
保存された履歴
過去のやり取りを読む
保存データの読み出し
実行用に読み込まれた会話
新しい指示を受け取る
会話の再開 → 次の指示
実行用の会話が見つからなければ、過去の履歴を表示できても送信に失敗することがあります。
履歴の表示と、新しい指示の受け付けは別の仕組みです。しばらく離れていたタスクでは、履歴は読めても、指示を受け付ける側に会話が読み込まれていないことがあり、そのまま送るとこのエラーになります。
仕組みの詳細（アプリ内部の通信名）
公式App Server仕様では、thread/readは保存履歴を読む操作で、会話を実行用メモリに読み込む操作ではありません。続行のためのthread/resumeとは役割が違います。これらはアプリ内部の通信名で、チャット欄に打つコマンドではありません。
私たちの環境の保存メタ情報にあるCLI版0.155.0-alpha.9に対応する送信処理の公開ソースでは、turn/startの入口が会話を取得し、失敗するとthread not foundを返します。取得先はメモリ上の会話一覧なので、このエラーは保存ファイルの消失を意味しません。
notLoadedは、保存された会話が今は実行用に読み込まれていない通常の状態です。公式App Server仕様では、最後の購読者が外れた会話は、購読者も動作もない状態が30分続くとアンロードされ、notLoadedに変わります。問題なのは、その状態から必要な再開処理が行われず、次の指示を受け取れないことです。私たちの例でも、失敗は直前の送信成功から1時間以上たってからでした。
2. 実例：履歴を残したまま送信が復旧した
私たちの環境で起きた例です。Windows版アプリ26.915.31029のタスクで、続行の指示を送った際にこのエラーが出ました。以下は2026年9月21日のアプリログを日本時間にそろえ、会話ID・作業内容を省いて整理したものです。
画面上の再試行から、実際の再読み込みへ
送信失敗（内部応答は thread not found）
画面側はすでに再開済みと扱っていた
開き直した後も、同じ送信エラー
単なる画面の切り替えでは改善しなかった
未ロード状態を確認 → 会話の再読み込みに成功
未ロード → 再開が必要と判定 → 再開に成功
次の指示を受理し、送信処理が成功
後の履歴確認では両ターンがcompleted・errorなし
保存された会話と作業ディレクトリは残っており、履歴を読む操作も成功しました。元のタスクはアーカイブされていませんでした。
この事例で確認できたこと
- 履歴は残っていた
- 再読み込み後に送信が成功した
- 調査では履歴・設定を変更していない
この例からは分からないこと
- 内部の会話が外れた正確なきっかけ
- すべての利用者に共通する原因
画面は「再開済み」と扱っていたのに、内部では会話が読み込まれていなかった、という食い違いが原因と考えられます。送信が戻った後は、そのターンの作業内容が正しいかも確かめてください。
3. 送信だけ失敗するときに試す順番
まず、入力文を失わないよう手元に控えます。送信ボタンを繰り返し押す前に、同じ指示が会話に追加されていないか、処理が始まっていないかを見てください。特に公開・削除・購入などを含む指示では、応答が遅れた要求を重ねて送らないことが大切です。
会話と、直前の作業を確認する
過去の発言が読めるか、最後の指示が完了・実行中・エラーのどれに見えるかを確認します。タスクが一覧に見当たらない場合は、設定の「アーカイブ済みチャット」も開きます（公式トラブルシューティングの案内）。編集したファイルがあるなら保存し、作業場所も控えます。会話表示の不調と、作業ファイルの消失は分けて考えます。
読み込みを待ち、同じタスクを開き直す
開いた直後なら履歴の表示が落ち着くのを待ちます。いったん別のタスクへ移って戻り、小さな確認を試します。私たちの例ではこの操作だけでは直らなかったので、同じ再送を何度も続けるより次の手順へ進みます。
他の作業を確認して、アプリを完全に再起動する
別タスクが動いている場合は、完了を待つか必要な内容を保存して停止します。その後アプリを終了し、起動し直して同じタスクを開きます。タスク表示の切り替えと、アプリ全体の再起動は別の操作です。
短い応答が完了するか確かめる
元の大きな作業をすぐ再送せず、ファイル変更やツール使用を伴わない確認を送ります。応答が完了したら、直前の作業内容を確かめて通常の続行へ戻ります。
確認文は、例えば次のように範囲を絞ります。モデルへの普通の指示として送るので、通常どおり利用量がかかる場合があります。
接続確認です。以前の作業は再開せず、ファイルの読み書きや
ツール呼び出しもせずに、「応答できました」とだけ返してください。OpenAIのGitHubリポジトリへの報告 #30710には、Windowsで会話を開いた直後の送信失敗が、アプリの完全な再起動で解消した例があります。公式トラブルシューティングにある「動作中のタスクの完了を待ってから再起動する」手順は、内蔵ターミナルが固まった場合の案内で、この送信エラー向けのものではありません。
更新を試す場合は、先に現在のアプリ版と症状を記録してください。公式トラブルシューティングによると、デスクトップアプリに同梱されたCodexと、別途インストールしたCLIは版が異なることがあります。CLIを更新しても、アプリ側の不具合が直ったことにはなりません。
4. 同じ表示でも、原因と対処は一つではない
「メッセージの送信中にエラー」という見出しだけで判断せず、その後ろの文言と失敗した操作を見ます。次の表は、公開報告と私たちの環境での例を症状ごとに分けたものです。
| 見える症状 | 確認する点 | 早合点しないこと |
|---|---|---|
| 履歴は読めるが送れない | 再読み込み後に送信できるか | 履歴が読める＝送信できる、ではない |
| アーカイブも失敗／os error 2 | 保存ファイルと参照先の状態（履歴は読めることも多い） | 再起動で送信が戻っても、アーカイブは失敗し続けることがある |
| Timeout／App server request expired while queued | 30秒ほど待たされたか・応答停止・待ち行列の状態 | 即座に返るthread not foundと混ぜない |
| 続行だけでなく停止も失敗 | 本当に動いているか、古い表示か | 画面の実行中表示だけを信じない |
履歴が残る例では、#30710のmacOS利用者の追記が参考になります。画面は再開済みと扱っていましたが送信は繰り返し失敗し、後に新しい画面側で再読み込みが成功しています。「開いた瞬間だけの競合」では説明しきれない状態不整合の報告で、今回の事例とよく似た経過です。
一方、Windowsの報告 #39179では、履歴は読めるのに送信とアーカイブが失敗し、投稿者の環境では再起動後も続きました。後の追記には、アプリを完全に再起動すると続行できるようになったが、アーカイブの失敗は確実には直らなかった、という報告もあります。#39575には保存ファイル名の時刻と参照処理に関する診断があります。いずれも利用者の調査なので、パスの接頭辞や時差があるだけで、自分のデータも壊れていると決めつけないでください。
待たされる型は#27395の送信タイムアウト報告で、turn/startが30秒（timeoutMs=30000）で打ち切られ、Timeoutとして失敗したログが載っています。#23644の追記では、送信の前提となる要求が待ち行列で約30秒（queueWaitMs=30001）待たされた末に、App server request expired while queuedで失敗しています。停止も失敗する型は#42604の履歴・実行状態の不整合報告で確認できます。
5. 直らないときの確認と引継ぎ
再起動しても直らない場合は、保存履歴を読めるかを調べます。別の正常なCodexタスクから対象タスクを読む機能が利用できるなら、読み取り専用の確認から始めます。対象IDを名前の似たタスクと取り違えないことも重要です。
対象タスクを読み取り専用で調査してください。
対象ID：ここにエラーに表示された会話ID
履歴を読めるか、最後のターンの状態、エラーを報告してください。
別タスクへのメッセージ送信、以前の作業の再開、フォーク、
アーカイブ、設定変更、DB編集、履歴ファイルの移動・削除はしないでください。
利用できるタスク管理機能がなければ、その旨を報告してください。タスク管理機能が使える環境向けの文例です。機能が見つからない場合は、似た名前の内部コマンドを推測して実行せず、6章の報告へ進みます。
確認結果に合わせて、次を選ぶ
- 履歴を読める・前の作業は完了している
- 追加の送信確認や、履歴を引き継ぐフォークを候補にする。元のタスクは残す。
- 履歴を読める・作業が実行中か不明
- 動作状態とファイルの変更を先に確認。別タスクで同じ作業を二重に走らせない。
- 保存先のエラーが出る（os error 2 など）
- バックアップを保全し、ログを添えて報告。読み込みを直す目的で原本を消さない。
#39179の追記には、別の正常なタスクから短い確認メッセージを送り、応答完了後に通常の会話も復旧した例があります。ただし、別の追記では同様の送信が失敗し、完了済み履歴のフォークで新しい指示が受理されています。この反例を受け、先の報告者も一般的な解決策ではないと補足しています。
フォークは完了済みの履歴を別タスクへ引き継ぐ操作で、元のタスクは直りません。未完了の作業がそのまま続くとは考えず、引継ぎ後に作業ディレクトリ、変更ファイル、最後に終わった工程を確認してください。
履歴データと作業ファイルも別です。会話が開けなくてもプロジェクトの編集結果が残っている場合があります。逆に、会話が読めてもファイルが最新とは限りません。Gitを使うプロジェクトなら変更一覧を確認し、何を実行済みかを整理してから続けます。
6. 調査を依頼するときに残す情報
報告では「送れない」だけでなく、何が成功し、何が失敗したかを分けます。アプリ版、OS、発生時刻とタイムゾーン、対象の会話ID、直前の操作があると、別系統の障害を混ぜずに追いやすくなります。最初から会話全文を公開する必要はありません。
報告メモのひな形
- 環境
- アプリ版／OS／ローカル・リモートなどの実行先
- 発生
- 時刻とタイムゾーン／エラー全文／直前にした操作
- できること・できないこと
- 履歴表示／送信／停止／アーカイブの各結果
- 試した操作
- 開き直し・再起動の前後で、何が変わったか
ログを調べられる場合は、失敗した要求の前後を見ると役立ちます。method=turn/startは指示の開始、thread/resumeは会話の再開、errorCodeは内部応答の手掛かりです。成功行も残し、同じ失敗が複数のログ行に出ているだけなのか、実際に複数回失敗したのかを区別します。
アプリログの場所として、公式トラブルシューティングにはmacOSの~/Library/Logs/com.openai.codex/YYYY/MM/DDが載っています。Windowsでは、私たちの環境で次の2か所にありました。
- 今回エラーが出たPC：
%LOCALAPPDATA%\Codex\Logs - 別のPCのMicrosoft Store版（2026年3月のログ）：
%LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs（このPCには%LOCALAPPDATA%\Codexというフォルダ自体がありませんでした）
Microsoftの説明によると、パッケージ化されたアプリがAppDataに新しく作るファイルは、アプリ専用の場所に書き込まれ、アプリからは通常の場所にあるように見えることがあります。片方で見つからなければ、もう片方も探してください。セッションの保存先は、公式に$CODEX_HOME/sessions（既定値~/.codex/sessions）と案内されています。設定や実行先が違えば見ているフォルダに対象がないだけの可能性もあるので、「検索で出ない」だけで削除済みと判断しないでください。
Codex のデータ（CODEX_HOME）やアプリ本体を別のドライブへ移したときに、どこに何があるかを確かめた記録は、ChatGPT・Codex を別ドライブへ移すにまとめています。
公式トラブルシューティングでは、入力欄で/を入力してフィードバックを送る案内があります。ログやスクリーンショットには会話本文、メールアドレス、他のプロジェクト名、ローカルパスが含まれることがあります。公開Issueには必要な部分だけを匿名化して載せ、完全なIDなどを渡す際は送付先と公開範囲を確認してください。
7. 復旧できたかは、短い応答で確かめる
このエラーへの最初の対応は、履歴の削除ではなく、読めるか・再開できるか・新しい指示が完了するかを分けて確かめることです。今回の事例は会話の再読み込みで送信が戻りました。保存先のエラーが出ている場合は別の経路なので、5章の確認へ進みます。
短い応答が完了したら、元の指示がどこまで実行されたかを確認し、必要な工程から再開します。直らない場合は、読み取り専用の調査とログの保全を優先します。エラー表示が消えただけ、あるいはフォークが作れただけで復旧完了としないことが大切です。
関連する記事：
- Codexの容量エラーと利用枠切れの違い・対処法（「Selected model is at capacity」と出る場合）
- Remoteの接続条件と切断後の確認手順（実行場所とPCのスリープ）
- Claude Codeの似たエラー：Prompt is too long（入力の容量）・MCP error -32000: Connection closed（外部ツールとの接続）
FAQ
Q. thread not foundが出たら、会話は消えていますか？
A. そうとは限りません。保存履歴は読めても、送信先として必要な実行用の会話が読み込まれていない場合があります。一方、保存先の参照やファイル自体に問題がある場合もあるため、実際に読めるかを確認します。
Q. notLoadedはエラーですか？
A. それ自体は通常の状態です。保存された会話が、今は実行用に読み込まれていないことを示します。問題になるのは、続行時に再開されず、短い応答も完了しない場合です。
Q. 再起動すれば必ず直りますか？
A. 必ず直るわけではありません。完全な再起動で解消した報告（#30710）も、再起動後も送信やアーカイブの失敗が続いた報告（#39179）もあります。私たちの例では、会話の再読み込みの後に送信が戻りました。
Q. 最新版に更新すれば解決しますか？
A. 2026年9月21日時点では、この症状全体を直したと明記された修正版は見当たりませんでした。更新するときは、前後のアプリ版と結果を記録してください。別途インストールしたCLIと、アプリ同梱のCodexの版は同じとは限りません。
