Codexの「thread not found」対処法｜履歴を消す前の確認と復旧事例

Codexの「thread not found」は、履歴が消えたという意味とは限りません。まず、送信だけが失敗するのか、会話を開くこともできないのかを分けて確認します。

1. thread not foundは何が見つからないのか

OpenAIのCodexで既存タスクに続きを送ったとき、次のようなエラーが出ることがあります。後ろのIDは対象の会話を識別するもので、以下では伏せています。

メッセージの送信中にエラーが発生しました
thread not found: <対象の会話ID>

本記事の対象はデスクトップアプリの既存ローカルタスクです。自端末で発生した送信失敗のログ、公開ソース、利用者の不具合報告を2026年9月21日に照合しました。Windowsでの自端末事例が中心で、すべての環境に共通する修復方法を実証した記事ではありません。

公式App Server仕様では、thread/readは保存履歴を読む操作で、会話を実行用メモリに読み込む操作ではありません。続行のためのthread/resumeとは役割が違います。これらはアプリ内部の通信名で、チャット欄に打つコマンドではありません。

自端末の保存メタ情報にあるCLI版0.155.0-alpha.9に対応する送信処理の公開ソースも確認しました。turn/startの入口は会話を取得し、失敗するとthread not foundを返します。取得先はメモリ上の会話一覧で、このエラーだけから保存ファイルの消失は判断できません。

notLoadedという状態自体も異常とは限りません。保存された会話が、今は実行用に読み込まれていないことを示します。問題なのは、その状態に必要な再開処理が行われず、次の指示を受け取れないことです。通常のアンロード、保存先の参照問題、誤った会話IDなどを、文言だけで区別することはできません。

2. 実例：履歴を残したまま送信が復旧した

AI Arteの制作環境では、Windows版アプリ26.915.31029の別タスクで、続行の指示を送った際にこのエラーが出ました。以下は2026年9月21日のアプリログを日本時間にそろえ、会話ID・作業内容・個人情報を省いて整理したものです。

保存された会話と作業ディレクトリは存在し、履歴を読む操作も成功しました。元タスクはアーカイブされていませんでした。調査では会話のデータベースや設定を変更せず、ログと保存状態を読み取り専用で確認しています。

画面の「再開済み」という扱いと内部の状態が食い違っていた、という説明が有力です。ただし、なぜその状態になったかを再現実験で特定したわけではありません。また、最新ターンの状態確認と、そこで行われた作業内容の正しさの検証も別です。本記事の復旧確認は送信・会話状態の範囲です。

3. 送信だけ失敗するときに試す順番

まず、入力文を失わないよう手元に控えます。送信ボタンを繰り返し押す前に、同じ指示が会話に追加されていないか、処理が始まっていないかを見てください。特に公開・削除・購入などを含む指示では、応答が遅れた要求を重ねて送らないことが大切です。

確認文は、例えば次のように範囲を絞ります。これはモデルへの指示であり、アプリの不具合を修理するコマンドではありません。送信やモデル応答に通常の利用量が発生する可能性もあります。

接続確認です。以前の作業は再開せず、ファイルの読み書きや
ツール呼び出しもせずに、「応答できました」とだけ返してください。

OpenAIのGitHubリポジトリへの報告 #30710には、Windowsで会話を開いた直後の送信失敗が再起動で改善した例があります。公式トラブルシューティングでは、内蔵ターミナルが固まった場合に、動作中のタスクの完了を待って再起動する手順を案内しています。これはこの送信エラー専用の復旧手順ではありません。しかし、これらは再起動がすべてのthread not foundを直すという保証ではありません。

更新を試す場合は、先に現在のアプリ版と症状を記録してください。アプリに同梱されたCodexと、別途インストールしたCLIは版が異なる場合があります。CLIだけを更新しても、デスクトップアプリ側の不具合が直ったことにはなりません。本記事では、この症状に対する恒久修正版を特定できていません。

4. 同じ表示でも、原因と対処は一つではない

「メッセージの送信中にエラー」という見出しだけで判断せず、その後ろの文言と失敗した操作を見ます。次の表は公開報告と自端末の観測を分類したもので、発生頻度のランキングではありません。

履歴が残る例では、#30710のmacOS利用者の追記が参考になります。画面は再開済みと扱っていましたが送信は繰り返し失敗し、後に新しい画面側で再読み込みが成功しています。「開いた瞬間だけの競合」で説明しきれない状態不整合の報告です。今回の事例と似ていますが、同一原因と確定したわけではありません。

一方、Windowsの報告 #39179では、送信に加えてアーカイブも失敗し、再起動後も問題が続きました。#39575には保存ファイル名の時刻と参照処理に関する診断もあります。ただし、いずれも利用者の調査です。パスの接頭辞や時差があるだけで、自分のデータも壊れていると決めつけないでください。

待たされる型は#27395の送信タイムアウト報告、停止も失敗する型は#42604の履歴・実行状態の不整合報告で確認できます。似た表示の報告があることと、全利用者に頻発していることは別です。利用者数や送信回数を分母とする発生率は、本調査では確認できませんでした。

5. 直らないときの確認と引継ぎ

再起動しても直らない場合は、保存履歴を読めるかを調べます。別の正常なCodexタスクから対象タスクを読む機能が利用できるなら、読み取り専用の確認から始めます。対象IDを名前の似たタスクと取り違えないことも重要です。

対象タスクを読み取り専用で調査してください。
対象ID：ここにエラーに表示された会話ID

履歴を読めるか、最後のターンの状態、エラーを報告してください。
別タスクへのメッセージ送信、以前の作業の再開、フォーク、
アーカイブ、設定変更、DB編集、履歴ファイルの移動・削除はしないでください。
利用できるタスク管理機能がなければ、その旨を報告してください。

これは、タスク管理機能が使える環境で調査を依頼する文例です。すべての画面やCLIに同じ機能があるわけではありません。機能が見つからない場合に、似た名前の内部コマンドを推測して実行する必要はありません。

#39179の追記には、別の正常なタスクから短い確認メッセージを送り、応答完了後に通常の会話も復旧した例があります。ただし、別の追記では同様の送信が失敗し、完了済み履歴のフォークで新しい指示が受理されています。この反例を受け、先の報告者も一般的な解決策ではないと補足しています。

フォークは元のタスクを修理する操作ではなく、完了済みの履歴を別タスクへ引き継ぐ選択です。未完了の作業がそのまま再現されると思わず、引継ぎ後に作業ディレクトリ、変更ファイル、最後に終わった工程を確認してください。公開報告で新しい指示を受理したことも、その後の作業が最後まで正しく終わる保証ではありません。

履歴データと作業ファイルも別です。会話が開けなくてもプロジェクトの編集結果が残っている場合があります。逆に、会話が読めてもファイルが最新とは限りません。Gitを使うプロジェクトなら変更一覧を確認し、何を実行済みかを整理してから続けます。

6. 調査を依頼するときに残す情報

報告では「送れない」だけでなく、何が成功し、何が失敗したかを分けます。アプリ版、OS、発生時刻とタイムゾーン、対象の会話ID、直前の操作があると、別系統の障害を混ぜずに追いやすくなります。最初から会話全文を公開する必要はありません。

ログを調べられる場合は、失敗した要求の前後を見ると役立ちます。method=turn/startは指示の開始、thread/resumeは会話の再開、errorCodeは内部応答の手掛かりです。成功行も残し、同じ失敗が複数のログ行に出ているだけなのか、実際に複数回失敗したのかを区別します。

今回のWindows端末ではアプリログが%LOCALAPPDATA%\Codex\Logsにありました。これは自端末で確認した場所で、全配布形態に共通する保証ではありません。公式資料はセッションの保存先を$CODEX_HOME/sessions、既定値を~/.codex/sessionsと案内しています。設定や実行先が違う場合、見ているフォルダに対象がないだけの可能性もあります。「検索で出ない」だけで削除済みと判断しないでください。

公式トラブルシューティングでは、入力欄で/を入力してフィードバックを送る案内があります。ログやスクリーンショットには会話本文、メールアドレス、他のプロジェクト名、ローカルパスが含まれることがあります。公開Issueには必要な部分だけを匿名化して載せ、完全なIDなどを渡す際は送付先と公開範囲を確認してください。

7. 復旧できたかは、短い応答で確かめる

このエラーへの最初の対応は、履歴の削除ではなく、読めるか・再開できるか・新しい指示が完了するかを分けて確かめることです。今回の事例では会話の再読み込み後に送信が成功しましたが、別の保存先エラーまで同じ方法で解決できるとは言えません。

短い応答が完了したら、元の指示がどこまで実行されたかを確認し、必要な工程から再開します。直らない場合は、読み取り専用の調査とログの保全を優先します。エラー表示が消えただけ、あるいはフォークが作れただけで復旧完了としないことが大切です。

Claude Codeも併用している場合、Prompt is too longは入力の容量、MCP error -32000: Connection closedは外部ツールとの接続を確認する別のエラーです。「AIに指示できない」という見た目が似ていても、製品名とエラー全文から対処を選びます。これらの対処コマンドをCodexの会話にそのまま流用するものではありません。

FAQ

Q. thread not foundが出たら、会話は消えていますか？
A. そうとは限りません。保存履歴は読めても、送信先として必要な実行用の会話が読み込まれていない場合があります。一方、保存先の参照やファイル自体に問題がある場合もあるため、実際に読めるかを確認します。

Q. notLoadedはエラーですか？
A. 状態名だけではエラーと判断できません。保存された会話が今は実行用に読み込まれていない正常な状態にも使われます。続行時に再開でき、短い応答が完了するかを確かめます。

Q. 再起動すれば必ず直りますか？
A. いいえ。改善した報告も、再起動後も保存先やアーカイブのエラーが続いた報告もあります。今回の自端末で確認したのは会話の再読み込み後の送信成功で、再起動の効果を実験したわけではありません。

Q. 最新版に更新すれば解決しますか？
A. 本記事の確認時点では、この症状全体を解消する特定の修正版は確認できていません。更新前後のアプリ版と結果を記録してください。別途インストールしたCLIと、アプリ同梱のCodexの版は同じとは限りません。