Codexで長い作業を続けていると、remote compactが実行されることがあります。そのときに次のエラーが出る場合があります。
Error running remote compact task: {"detail":"Bad Request"}
これは、Codexのコンテキスト圧縮処理が正常に完了しなかった、という意味です。
ただし、{"detail":"Bad Request"}は具体的な原因名ではありません。この表示だけでは、コンテキストが大きすぎたのか、画像が多かったのか、履歴項目が不正だったのか、サーバー側の一時的な問題だったのかまでは分かりません。
remote compactとは
コーディングエージェントとの会話が長くなると、過去のやり取りやツール実行結果をすべて同じ形でモデルへ渡し続けるのが難しくなります。
そこで、過去の会話状態を圧縮して、必要な情報を残したまま同じ作業を続けられるようにする処理があります。Codexで表示されるremote compactは、そのための処理です。
OpenAIのAPIドキュメントでも、長時間のツール実行を含む処理に対してcompactionを使い、圧縮後の状態を次のリクエストへ渡して会話を継続する仕組みとして説明されています。Compactionの出力は暗号化された不透明な項目として扱う設計です。
Codex内部のremote compactが、公開APIのcompactionと完全に同じリクエストや制限で動いているかは、表示されたエラーだけでは判断できません。ここでは、Codexで実際に見えるエラーの意味を整理します。
Error running remote compact taskとは
Error running remote compact taskは、compactを実行するタスク自体が失敗したことを示しています。
通常の応答を生成している途中で出たエラーではなく、長くなったコンテキストを圧縮して次のターンへ進むための処理で失敗しています。
そのため、単に「今回の応答だけ生成できなかった」という状態より面倒になることがあります。Codexが次の応答を作る前に、もう一度compactを必要とする状態に戻る可能性があるためです。
{"detail":"Bad Request"}は何を意味するか
HTTPの400 Bad Requestは、送信されたリクエストをサーバーが受け付けられなかったことを表します。
ただし、400というステータスだけでは失敗理由を一つに絞れません。Codexの画面に表示された{"detail":"Bad Request"}も、サーバー側から返された詳細がその短い文字列だけだった、ということしか分かりません。
原因としては、例えば次のようなものが考えられます。
- コンテキスト全体が大きすぎる
- リクエストボディの構造やサイズが受け付けられなかった
- 画像やファイルなど特定の履歴項目をcompact側で処理できなかった
- 履歴の一部が不正、または現在の処理では扱えない状態だった
- サーバー側の一時的な不具合や、経路上の失敗が起きた
このうちどれなのかは、Bad Requestだけでは判定できません。
400を見てすぐに「コンテキスト上限を超えた」「画像が原因だ」と決めつけるのは危険です。実際の原因を絞るには、エラーの詳細、発生直前の履歴、画像やファイルの有無、同じ条件での再現性などを確認する必要があります。
context_length_exceededとの違い
context_length_exceededのようなエラーは、コンテキスト長が上限を超えたことを、エラー名としてより具体的に示します。
一方、次の表示にはその情報がありません。
{"detail":"Bad Request"}
コンテキストが大きい状態で発生したとしても、Bad Requestという表示だけからcontext_length_exceededと同じだとは言えません。
逆に、compactを実行する段階まで会話が長くなっているなら、コンテキストや履歴のサイズが関係している可能性はあります。ここで重要なのは、「関係している可能性」と「エラーの直接原因が確定していること」を分けることです。
413 Payload Too Largeとの違い
413 Payload Too Largeは、HTTPリクエストのペイロードが大きすぎるため、サーバーが処理を拒否したことを示すステータスです。
今回のような400とは、表示上も意味上も別です。
400 Bad Request
リクエストを受け付けられないが、表示だけでは理由が分からない
413 Payload Too Large
リクエストのペイロードが大きすぎることを示す
画像が大量に含まれていたとしても、サーバーから413が返っていなければ、413が原因だったとは言えません。400の本文が短い場合は、内部でサイズに関係する処理が失敗していても、利用者には400としてしか見えない可能性があります。
つまり、次の三つは区別した方がよいです。
context_length_exceeded
コンテキスト長の上限に関する、より具体的なエラー
413 Payload Too Large
HTTPリクエストのペイロードサイズに関するステータス
400 Bad Request
リクエストを受け付けられなかったことだけが分かる、より一般的な表示
具体的な理由が返る場合と返らない場合
Bad Requestでも、いつも同じ情報量になるとは限りません。
サーバー側の実装や失敗した場所によっては、400と一緒に入力項目や形式の問題を示す詳細が返ることがあります。その場合は、どの項目を直せばよいか推測しやすくなります。
一方で、Codexの画面に次のような内容だけが出る場合もあります。
Error running remote compact task: {"detail":"Bad Request"}
この場合、エラーコードや失敗した履歴項目、サイズ上限などは公開されていません。表示されていない情報を、エラーメッセージから逆算することはできません。
なぜ次のターンも失敗しやすいのか
compactが不要な状態で一度のリクエストが失敗しただけなら、再試行で戻ることがあります。
しかし、すでにcompactが必要なほどコンテキストが大きくなっている場合は、次のようなループになりやすくなります。
大きいコンテキストのまま
↓
次のターンへ進む前にcompactが必要
↓
remote compactがBad Requestで失敗
↓
コンテキストが圧縮されない
↓
またcompactが必要
compactが成功していないので、再試行しても同じ履歴、同じ画像、同じ形式を送ることになります。サーバー側の一時的な問題なら時間を置いて直る可能性がありますが、履歴の特定データが毎回問題になる場合は、同じエラーを繰り返します。
この状態になると、新しいセッションへ移るだけなら作業は続けられても、元のセッションに保存されていた判断やGoalを維持したまま続けるのが難しくなります。
自分のケースでは画像が関係していた
自分の場合は、Omoikaneの開発をCodexで長時間続けていたときに、このエラーが出ました。
そのセッションには、次のような画像が含まれていました。
PNG 40枚
画像本体 約42 MB
Base64 data URL 約56 MB
PNGだけを画素を変えずに可逆再圧縮すると、画像本体は約277 KBになりました。その状態で同じセッションIDのremote compactを試すと、今度は成功しました。
この結果から、自分のケースでは巨大なinline PNGが失敗の主要な条件だった可能性が高いと考えています。
ただし、これは自分のセッションでの復旧結果です。
Bad Request = PNGが原因
と一般化できるわけではありません。画像がないセッションでも、履歴の形式やサーバー側の一時的な問題で同じ表示になる可能性はあります。
調査した内容と、画像のA/B検証、同じセッションIDの復旧手順については、大量の無圧縮PNGを含むCodexの長期セッションでremote compactが失敗したので復旧したにまとめています。
同じエラーが出たときに確認すること
まずは、一時的な失敗かどうかを切り分けます。
再起動や時間を置いた再試行で一度だけ成功するなら、サーバー側や通信経路の一時的な問題だった可能性があります。
同じセッションで何度も失敗する場合は、発生直前の履歴を確認します。
- 大量の画像やファイルを表示していないか
- 直前に大きなツール出力を追加していないか
- compact後ではなく、compact前の同じ状態を繰り返していないか
- 別の短いセッションでは通常どおり応答できるか
ただし、Codexの内部履歴やデータベースを直接書き換えるのは通常の復旧方法ではありません。形式を壊すとセッション自体を読めなくなる可能性があります。
どうしても元のセッションを維持したい場合は、元データを変更する前に完全なバックアップを作り、コピー側で再現と検証を行う必要があります。詳細な復旧手順は先ほどの実例記事に分けています。
まとめ
Error running remote compact task: {"detail":"Bad Request"}は、Codexが長い会話コンテキストを圧縮しようとしたremote compact処理が完了しなかった、という表示です。
Bad Requestは具体的な原因名ではありません。コンテキストの大きさ、リクエストのサイズや形式、特定の画像・履歴項目、サーバー側の一時的な問題など、複数の可能性が残ります。
context_length_exceededや413 Payload Too Largeのように、原因をより直接示すエラーとは区別する必要があります。400だけでは、そこまでの情報はありません。
compactが必要な状態で失敗すると、コンテキストが圧縮されないまま次のcompactを繰り返すことになり、セッションを継続しにくくなります。
自分のケースでは、40枚のPNGを可逆再圧縮して約277 KBまで小さくすると、同じセッションIDでcompactが成功しました。ただし、これは一つの復旧例であり、Bad Requestの一般的な原因をPNGだと断定するものではありません。
このエラーの意味を調べている場合は、まず「compact処理の失敗」と理解し、Bad Requestだけから原因を決めつけないのがよさそうです。