Codex「メッセージの送信中にエラーが発生しました」は2行目で判断

Codexでメッセージを送ると、次のような通知が出て送れなくなることがあります。英語表示ではError submitting messageです。

メッセージの送信中にエラーが発生しました
App-server queued follow-up no longer exists

1行目はアプリが出す共通の見出しで、原因は2行目に書かれています。2行目が違えば効く対処もまったく違うため、見出しだけでは原因は決まりません。最初にすることは3つです。送れなかったテキストをコピーして退避する、会話にそのメッセージや応答がすでに出ていないかを見る、それから2行目に合う対処を選ぶ。「再試行」を先に押すと、実は届いていたメッセージと作業が二重に走ることがあります。

以下の内容の根拠は、2026年10月16日時点の次の4つです。ChatGPTデスクトップアプリ（バージョン26.1013.31256、macOS）に入っているコード、オープンソースのapp-server（openai/codex）、作業用Mac 1台のデスクトップ版ログ（10月2日〜16日）、openai/codexのGitHub issue 34件とOpenAI開発者フォーラムの報告。どのエラーも意図的に再現してはいません。「報告者が効果を確認」と書いた対処は、issueやフォーラムで本人が効いたと書いたもので、OpenAIの公式手順でも保証でもありません。

送信エラーの見出しは共通、原因は2行目に出る

この通知はサーバーのエラーコードではなく、アプリ側が出す見出しです。デスクトップアプリのコードではError submitting message{br}{error}という1つの文言になっていて、改行の後ろの{error}に、送信処理が受け取った実際のエラー文が入ります。日本語表示も同じ形で「メッセージの送信中にエラーが発生しました」の下にエラー文が並びます。

• スレッドの中の表示：失敗したターンには、エラー文があればそれがそのまま表示されます。エラー文がないときだけ、英語のError submitting messageだけが出ます。
• 2行目がない場合：アプリがエラー文を受け取っていない状態です。タイムアウトか接続切れであることが多いと考えられます（後述のタイムアウトの報告とコードからの推測）。
• 見出しが違う場合：「タスクの作成中にエラーが発生しました」や英語表示のError creating chatでも、2行目の種類は同じです。GitHubの#23644には、日本語表示で「タスクの作成中にエラーが発生しました」の下にtimeoutと出た報告があります。

送信の流れは次のとおりです。デスクトップアプリやVS Code・Cursorの拡張機能は、メッセージを送るとローカルで動くapp-serverにturn/start（1回の応答＝ターンを始める要求）を送ります。拡張機能のコード（バージョン26.513）では待ち時間が30秒（30,000ms）で、それまでに応答がないか、app-serverがエラーを返すと、そのターンは失敗になりこの見出しが出ます。現行のデスクトップ版でも、報告者のログにはmcp_request_timeout method=turn/start … timeoutMs=30000と[Composer] submit failed errorMessage=Timeoutが残っています。

exceeded retry limit, last status: 429、401、stream disconnectedは送信後の通信で起きる別のエラーで、Codex exceeded retry limit 429の意味：401・Stream Disconnectedで扱っています。Selected model is at capacityはモデル側の容量不足で、このエラーとは原因が別です。

再試行の前に確認：メッセージがすでに届いていないか

「失敗」と表示されていても、メッセージが届いて作業が始まっていることがあります。逆に、まったく届いていないこともあります。どちらなのかを先に確かめると、同じ作業を二重に走らせずに済みます。

届いていた例：

• #44781では、9月13日と15日に、メッセージが一度保存されてターンが始まった後でエラーが出た報告があります。報告者は「再試行していたら二重に届く危険があった」と書いています。
• WindowsのEPERMエラー（#52012）では、画面上は失敗なのにメッセージがエージェントに届いており、再試行でユーザーのメッセージと応答が重複しました。
• 作業用Macのログでも、10月3日に定期実行のオートメーションでturn/startがタイムアウトした直後、app-serverの応答が遅れて届き、response_orphaned（受け取り手のいない応答）として記録されていました。アプリが待つのをやめた後にサーバー側は応答していた、ということです。

届いていなかった例もあります。#35949や#23644では、失敗したメッセージはturn/startにも会話の記録にも届いておらず、送り直して問題ありませんでした。

デスクトップアプリ26.1013.31256の日本語表示には、キューのメッセージについて「メッセージが届いたか確認できませんでした。この保存済みメッセージを削除する前に、会話を確認してください。」という文言も入っています。アプリ自身も、まず会話を見ることを求めています。

確認の手順：

1. 入力欄やキューに残ったテキストをコピーして、エディタなどに退避します。チャットを切り替えたら他のキューのメッセージも消えたという報告があるためです。
2. 会話を一番下まで表示して、自分のメッセージ、Codexの応答、コマンドの実行やファイルの変更が始まっていないかを見ます。始まっていれば再送せず、その結果を待つか確認します。
3. 別のチャットか新しいチャットで、短いメッセージを1つ送ってみます。通れば問題はそのチャットだけです。どのチャットでも失敗し、サイドバーやスレッドの読み込みまで遅いなら、app-server全体が詰まっているか、アプリ全体の問題です。

3の見分け方は作業用Macのログとも一致します。10月2日〜16日のturn/startの応答156回は、中央値63ms、95パーセンタイル1,184ms、最大9,042msで、通常は一瞬で返ります。一方でタイムアウトはturn/startだけでなく、同じ時間帯にthread/start（8回）、thread/list（8回）、thread/resume（6回）などでもまとまって起きていました。app-serverが止まると、送信以外の操作も一緒に遅くなります。1台・1人分の作業の記録なので、一般的な発生率ではありません。

2行目別の原因と対処（2026年10月16日時点）

2行目の原文で照合してください。「対処」の列は報告者が効果を確認したもので、効いた人数が少ないものはそう書いています。ビルドは毎週のように変わるため、9月に多かった文言が現行版では出ないこともあります。

ほかにもapp-serverのコードには、remote image URLs are not supported; use an inline data URL instead（画像はURLではなくデータとして添付する）やServer is draining; retry after reconnecting（再接続してから送り直す）のように、文言そのものが対処を示すものがあります。

キューの編集でApp-server queued follow-up no longer exists

ターンの実行中にキューへ入れたメッセージで「メッセージを編集する」を押す、または取り消して送り直すと出る、というのが最も多い報告です。編集なしの通常のフォローアップや、自動コンパクションの後に出た報告もあります。1度出ると、そのチャットではその後の送信もキューモード・「今すぐ反映」（英語表示ではSteer）のどちらでも失敗し続けます。2026年9月11日〜10月1日に、Windows、macOS、Linuxのデスクトップ版とVS Code拡張機能（26.908.40401）でissueが7件立ちました。

報告者が効果を確認した対処：

• 別の会話に切り替えてから戻り、送り直す（約8人）。ただし1人は、切り替えで他のキューのメッセージが消えたと書いています。先にテキストをコピーしてください。
• 実行中のターンが終わるのを待つか停止してから、同じテキストを新しいメッセージとして送る。「ときどきしか効かない」という人もいます。

メッセージの削除や、再起動・更新の繰り返しでは直らなかったという報告です。

OpenAIのスタッフは9月13日に#44781で「問題は把握しており、修正は次のリリースに入る」と回答しましたが、どのバージョンかは示していません。その後も9月21日ごろまで、Windows 26.908.9136.0、macOS 26.908.70816、VS Code 26.908.40401で報告が続きました。

デスクトップアプリ26.1013.31256のコードにはこの文言がもう含まれておらず、キューの処理では代わりにQueued follow-up changed before dispatchが出るようになっています。現行版ではキュー編集の衝突がこの新しい文言で表に出る、とコードからは読めますが、OpenAIが説明したものではありません。

dotが作ったWindowsタスクでAbsolutePathBufエラー

2行目がinvalid turn/start params: AbsolutePathBuf deserialized without a base path（code=-32602）なら、9月下旬以降もっとも報告が活発なケースです（#49477、#50428、#51593。最新は10月15日）。dot（エージェント）が接続済みのWindows PC上に作ったタスク（英語表示では「Cloud / Runs on your computer when available」）に、デスクトップアプリの入力欄から直接返信すると出ます。タスクの作業フォルダが/tmp/codex-cloud-agent-…/workspace/C:\Users\…のようにLinux形式とWindows形式の混ざったパスになっているのが共通点で、タスクの履歴は読めますし、dot自身からそのタスクへのメッセージは通ります。

報告者が効果を確認した対処（タスクごと）：

1. 入力欄の下の権限メニューを「カスタム」から「代わりに承認」（英語表示ではApprove for me）に変えて送る（4〜5人）。1人は、しばらくすると元の設定に戻って再び失敗したと書いています。
2. 「フルアクセス」に変えて送る（2人）。日本語表示の説明どおり「インターネットとコンピュータ上のすべてのファイルに無制限でアクセス」する設定になるため、報告者自身も勧めてはいません。
3. 新しいローカルタスク、またはWSL上のCodex CLIに引き継いで続ける。

「代わりに承認」は「安全でない可能性があると検出された操作についてのみ確認を求めます」というモードで、カスタムの権限設定とは承認の範囲が変わります。権限を変えたら、作業が終わった時点で元に戻すかどうかを決めてください。

再起動、PCの再起動、更新、再インストール、アーカイブ、再試行、Windowsのフォルダを明示した新しいタスクは、どれも効かなかったと報告されています。GitHubにもXにもOpenAIスタッフの返答はありません。

Timeoutまたは2行目なし：長時間の起動と重いスレッド

2行目がTimeoutやtimeout、App server request expired while queued、あるいは何も出ない場合は、多くはapp-serverが時間内に応答していません。報告されたきっかけは、3日半ほど起動しっぱなし、154MBになった巨大なスレッド、1.4〜2.2GBまで膨らんだ~/.codex/logs_2.sqliteを複数のcodexプロセスが共有していた、前回の起動で残ったcodex_chronicleプロセス、PC全体のCPU負荷、古いスレッドだけが遅く新しいスレッドは速い、などです。

報告者が効果を確認した対処を、軽いものから順に並べます。

1. 上の手順でメッセージが届いていないことを確かめてから、1〜5分待って送り直す。

2. ウィンドウを閉じるだけでなく、アプリを完全に終了して起動し直す。複数の人に効きましたが、一時的です。

3. macOSで、前回の起動から残ったcodex_chronicleがないか確かめる。

   bashコピー

   ps -axo pid,lstart,etime,command | grep codex_chronicle

   起動時刻（lstart）が今回アプリを起動した時刻より古いものが残っていれば、そのPIDをkillで終了します。ある報告者はこれで送信の失敗が4回から0回になりました。

4. 関係のない重いプロセスを止めて、CPUを空ける。

5. 新しいスレッドで続ける。同じプロジェクトでも、古いスレッドだけが遅いことを計測した報告があります。

コンテキストのコンパクションは効かなかったと報告されています。logs_2.sqliteは2GBを超えることがありますが、削除して直ったという報告も、削除を勧めた人もいません。

アプリ全体が遅い状態が続くなら、Codex Windows アプリが遅い時の CLI と Desktop の切り分けも参考になります。

agent loop died unexpectedly：承認待ちや使用上限の後

2行目がfailed to start turn: internal error; agent loop died unexpectedlyまたはfailed to submit turn input: …なら、そのスレッドのエージェントの処理が止まっています。対話式の確認を答えないまま放置して戻ったとき、承認の途中でPlusの5時間の使用上限に達したとき（上限がリセットされてもスレッドは止まったまま）、サブエージェントを閉じさせたとき、何度もコンパクションした長いスレッドで報告されています（5月22日〜10月10日）。

アプリを完全に終了して再起動すると直ったという報告が約6人ありますが、一時的だと書く人もいます。アプリの更新で直り、止まったセッションも消えなかったという報告が1件あります。他のチャットは使えることが多く、#35949では失敗したメッセージが会話の記録に書き込まれておらず、新しいターンも作られていませんでした。使用上限の残りとリセット時刻はCodexの週次上限はいつリセット？Usageの見方と有料即時リセットで確かめられます。

thread not foundとno client found：スレッドの担当がずれたとき

thread not found: <id>は、保存済みのスレッドを開いた直後に送信したときや、画面側が古い状態を持ったままになったときに出ています。デスクトップアプリの再起動か、新しいウィンドウでスレッドを開き直すと直ったという報告で、フォークや再読み込みは効きませんでした（最新の報告は10月15日、Windows）。

no client foundは、macOSからRemote SSHでリモートのホストにつないでいるときや複数のウィンドウを開いているときに、スレッドの担当が別のウィンドウに移った状態で出ています。会話を開き直しても直らず、2つ目のウィンドウを閉じる案は検証されていません。

Codex Web・クラウドタスクの環境エラーは解決策なし

Codex Webやクラウドタスクで2行目がUnable to determine project root for task（9月30日〜10月4日）またはa managed thread must retain its original environment（10月12日〜16日、デスクトップ・Web・Androidで報告）の場合、2026年10月16日時点で効いた対処は報告されていません。ハードリロード、環境の編集と再公開、環境の作り直しはどれも効かず、OpenAIサポートに勧められて新しい環境を作った人は「Task creation is not yet confirmed…」のまま24分止まりました。dotからそのセッションへメッセージを中継できたという部分的な報告はあります。

報告者たちは、作業内容を保存するまで環境をリセット・削除しないよう呼びかけています。残したいコードや結果があるなら、まずそれを確保してください。

WindowsのEPERMとENOENT：状態ファイルとフォルダ設定

• EPERM: operation not permitted, rename '…\.codex-global-state.json.tmp-…' -> '…\.codex-global-state.json'（ログにFailed to persist queued submission outcome）：Windows 10/11のデスクトップ版で10月8日以降に報告されています。状態ファイルの作り直し、再起動、Windows Searchの停止は効いていません。このケースでは届いたメッセージも失敗と表示され、再試行で重複したため、送り直す前の会話の確認が特に重要です。
• ENOENT: no such file or directory, mkdir '\\?'：プロジェクトなしのチャットで、~/.codex/config.tomlの[desktop]にあるprojectlessWorkspaceRootが、もう存在しないフォルダを指していると出ます。報告者は存在するフォルダに書き換えて再起動し、直りました。この設定項目は26.1013.31256にもあります。
• Unable to resolve projectless chat folder：WindowsをRemote Controlで操作しているときに出ています。ホスト側のチャットから既存のプロジェクトで作る、またはスマートフォンから作ると作成できたという報告です。

VS Code・Cursorで送信したメッセージが消える・反応しない

VS CodeやCursorのCodex拡張機能では、通知が出ずにプロンプトが消えるだけのこともあります。WSL上のVS Codeでプロンプトが黙って捨てられた報告（#46925、10月1日）では、設定chatgpt.followUpQueueModeをsteerにしても直りませんでした。

拡張機能に多い2行目は次の2つです。

• Queued follow-up changed before dispatch：chatgpt.followUpQueueModeがキュー（queue）のまま、続けて5〜7件送ると出ています（#50914、10月4日〜14日）。再試行でいずれ送れたという報告が1件あります。割り込みモードにすると避けられますが、実行中の応答は止まります。インストール済みの拡張機能を書き換えるコミュニティ製のパッチもありますが、OpenAIのものではありません。
• timeoutとCannot steer conversation … without an active turn id：OpenAI開発者フォーラムの「Why did the message fail to submit?」の報告者（拡張機能26.1007.21434、Ubuntu）は、サーバー側ではターンが完了しているのに画面は実行中のままで、その後の送信がすべてタイムアウトしました。直ったのは、コマンドパレットでDeveloper: Restart Extension Hostを実行したときだけです。

Restart Extension Hostは他の拡張機能も再起動し、そのウィンドウのCodexのセッションも中断されます。再起動の後は、各チャットとサブエージェントの状態を見直してください。新しいCodexのパネルを開いて履歴から会話を開き直す案も出ていますが、検証はされていません。

拡張機能がそもそも起動しない場合は別の問題で、Codex could not start：VS Codeで起動しない原因を環境別に切り分けで扱っています。

送れないときにやってはいけないこと：sessionsの削除と環境のリセット

送信エラーを直そうとして、かえって会話や作業を失った報告があります。

• ~/.codex/sessionsのファイルを手で消さない：セッションのファイルを手作業で削除した人は、新しい会話がすべてfailed to resolve rollout path … file does not existで失敗するようになりました（#30924）。再インストールや.codexの作り直しでは直らず、直った1人は消したファイルを作り直してから、アプリ内でアーカイブ→削除しています。不要な会話はアプリのアーカイブと削除で消し、設定を初期化して試す前には.codexフォルダをバックアップしてください。
• logs_2.sqliteを消さない：大きくなることはありますが、消して直ったという報告はありません。
• クラウドの環境をリセットしない：Codex Webやクラウドタスクは、作業内容を確保するまで環境のリセットや削除を避けてください。
• 権限を広げたままにしない：「フルアクセス」などで送れるようになっても、それは権限を広げた結果です。
• 会話を見ずに再試行を繰り返さない：届いていた場合、メッセージと作業がその回数だけ重複します。

直らないときにOpenAIへ送る情報

公式のトラブルシューティングページ（learn.chatgpt.comのCodexトラブルシューティング）には、このエラーそのものの説明はありません。チャットが止まったときの手順として、Codexが承認待ちになっていないかを見る、ターミナルでgit statusのような基本的なコマンドを実行する、小さく絞ったプロンプトで新しいチャットを始める、が挙がっています。実行を取り消してプロンプトが消えたときは、入力欄で↑キーを押すと戻せます。

それでも直らなければ、入力欄に/と入力してフィードバックを送ります。既存のチャットから送ると、そのセッションも一緒に共有するか選べ、送信後にセッションIDが表示されます。GitHubに報告する場合は、openai/codexのissue一覧で同じ2行目のissueを探し、あればそこに追記するほうが状況が伝わります。

伝える内容：

• 2行目のエラー文の原文（スクリーンショットだけでなく文字で）
• 使っている画面（ChatGPTデスクトップアプリ、VS Code・Cursorの拡張機能、Codex Web）とバージョン、OS
• 直前の操作（キューの編集、dotが作ったタスクへの返信、長時間起動など）と発生時刻
• 試したことと結果
• ログ：macOSのアプリのログは~/Library/Logs/com.openai.codex/YYYY/MM/DD、会話の記録は$CODEX_HOME/sessions（既定は~/.codex/sessions）

ログや会話の記録には、コードやトークンなど人に見せられない情報が含まれていることがあります。共有する前に中身を確認してください。

デスクトップアプリとCodex CLIは別々のバージョンのCodexを含むことがあります。CLIでは動くのにアプリでは送れない場合は、codex --versionと/Applications/Codex.app/Contents/Resources/codex --versionの両方を書き添えると切り分けに役立ちます。

再起動・障害・修正状況についての質問

再起動するとCodexのチャットやスレッドは消えますか？

報告されている範囲では、アプリの再起動や更新でスレッドが消えた例はありません。タイムアウトのケースでは「データは失われていなかった」と書いた人がいて、アプリの更新で直った人も止まったセッションは残っていました。ただし約束されたものではないため、送れなかったテキストは先にコピーしておき、~/.codex/sessionsのファイルには手を触れないでください。キューに残ったメッセージは、チャットの切り替えで消えた報告があります。

Codexの障害かどうかはどこで分かりますか？

まず別のチャットか新しいチャットで短いメッセージを送ってみてください。それが通れば、問題は今のチャットに限られています。すべてのチャットで失敗するなら、OpenAIステータスページで障害が出ていないかを見ます。障害が出ていないのに全体で送れない場合は、アプリを完全に終了して再起動するのが報告の多い対処です。

「タスクの作成中にエラーが発生しました」も同じ対処でいいですか？

はい、2行目で判断します。「タスクの作成中にエラーが発生しました」や英語表示のError creating chatの下にも、timeoutやagent loop died unexpectedlyなど同じ種類のエラー文が出ます。2行目が同じなら、上の表の同じ行の対処が当てはまります。

OpenAIはこのエラーを修正しましたか？

2026年10月16日時点で、OpenAIスタッフの公開された発言は、キューのエラーについての9月13日の1件（「修正は次のリリースに入る」）だけで、修正されたバージョンは示されていません。それ以外の2行目について、原因や修正版を示した告知はありません。範囲はopenai/codexのissue、OpenAI開発者フォーラム、learn.chatgpt.comのドキュメント、XのOpenAI関係者の投稿です。ビルドは毎週のように変わるため、更新があれば入れてから試してください。