作業が終わった9分後、Codexが黙って3,460万トークンを溶かし続けた──code-mode execのポーリングバグを読む

OpenAIのCodex CLIをGitHub上で使うユーザーが、code-mode（モデルがコードを書いてツールを実行する実行モード）のexecツールに関するissueを2026年8月14日に報告した。issue本文を読むと、長時間実行するコマンドの完了通知が「プッシュ（完了時に知らせる）」ではなく「プル（モデルが毎回聞きに行く）」方式になっており、1回聞くたびに会話全体のコンテキストを再送信するため、単なる「終わった？」の確認が、フルのコード解析と同じコストになってしまうという構造的な問題が報告されている。報告者はこのissueを、2026年8月27日時点でもopen（未解決）だと確認した。

3行まとめ

• Codexのcode-mode execは、長時間コマンドが「yield deadline」（デフォルト10秒）を超えると、完了を待つセルとして番号を振り、モデルがwait(cell_id)を呼ぶまで音沙汰なしになる。1回のwaitはフルコンテキストの再送信を伴う
• 報告された実例では、git worktree remove --forceの後片付け（実時間約9.5分）を待つだけで90ターン・入力2,161万トークン・出力3,837トークン（入力:出力比 5632:1）を消費し、しかもこれは作業成果物がすでにディスクに書き込まれた「完了後」に起きていた
• セッション全体では275ターン・5,470万トークンに達し、週次クォータが100%に達した8分後もCodexは実行を止めず、さらに18分間・約3,460万トークンのリクエストを受け付け続けたという

何が起きたか——issueタイトルが示す症状

issueのタイトルはこうだ。

Code-mode exec silently degrades a long-running command into a full-context model polling loop (34.6M tokens burned after the task already completed)

（Code-modeのexecは、長時間実行コマンドを、静かにフルコンテキストのモデルポーリングループへと劣化させる（タスクが既に完了した後に3,460万トークンが消費された））

issue本文の要約はこうだ。

In code mode, when a script passed to exec outlasts the yield deadline, the CLI parks it as a numbered cell and hands control back to the model. There is no completion push and no timer — the only way to learn that the command finished is for the model to spend a turn calling wait(cell_id). Each such turn resubmits the entire conversation context.

（code modeでは、execに渡されたスクリプトがyield deadline〔応答待ち上限〕を超えると、CLIはそれを番号付きのセルとして待避させ、制御をモデルに戻す。完了のプッシュ通知もタイマーもない——コマンドが終わったことを知る唯一の方法は、モデルがwait(cell_id)を呼ぶためにターンを1つ消費することだ。そのたびに会話全体のコンテキストが再送信される）

具体的な数字——90ターンで2,161万トークン

報告者が示した実際のセッション記録によれば、git worktree remove --forceという単一のコマンド（実時間で約9.5分のディレクトリ削除処理）を待つ間だけで、次の数字が記録された。

a single git worktree remove --force over a large directory tree (~9.5 minutes of real unlink time) produced 90 model turns, 21,610,789 input tokens and 3,837 output tokens — an input:output ratio of 5632:1 — and all of it happened after the agent had already delivered its result and written its report to disk.

（大きなディレクトリツリーに対する単一のgit worktree remove --force（実際のunlink処理時間は約9.5分）が、90回のモデルターン・入力トークン21,610,789・出力トークン3,837——入力:出力比5632:1——を生み出した。しかもこれはすべて、エージェントが既に結果を届け、レポートをディスクに書き込んだ後に起きていた）

セッション全体（019ffc35-8a14-76b3-bd0b-7e6bfe18b62c、2026年8月14日17:39:56Z〜18:15:09Z）では、合計275ターン・54,701,161トークンに達したという。issue本文が示すターンごとの内訳表によれば、638ターン目で作業結果が書き戻され（「work complete」）、642ターン目でレポートがディスクに書き込まれた後、648ターン目から後片付けコマンドの実行が始まり、668〜931ターンにかけて「16回のバイト単位で同一のwrite_stdin実行＋67回のwait呼び出し」が続き、932ターン目でモデルが諦めてCtrl-Cを送るまで9.5分かかったとされている。

なぜコストが跳ね上がるのか——毎回のポーリングがフルコンテキスト

issue本文は、各wait呼び出しのトークン課金を具体的な数値の表で示している。

662 wait 237,280 236,672 31 237,311 665 wait 237,339 236,672 31 237,370 ... 931 wait 242,794 241,792 31 242,825

（ターン番号、トリガー、入力トークン、キャッシュ済みトークン、出力トークン、合計トークンの順。入力は237,280から242,920へと単調に増加していく）

この現象について、issueはこう説明している。

Input ratchets upward monotonically (237,280 → 242,920) because each poll writes itself into the history that the next poll must re-send. Every turn's entire product is 31 tokens: {"cell_id":"89","yield_time_ms":1000,"max_tokens":5000}.

（入力は単調に増加していく（237,280→242,920）。各ポーリング自体が履歴に書き込まれ、次のポーリングはそれを再送信しなければならないからだ。すべてのターンの成果物は、わずか31トークンの{"cell_id":"89","yield_time_ms":1000,"max_tokens":5000}だけだ）

「回避策」は存在するが、実際には誰も使っていない

興味深いのは、issue報告者がCLIには既に回避策（@execプラグマでyield時間を延長指定する機能）が用意されていることを認めた上で、それが実際にはまったく使われていないと指摘している点だ。

Across 19,392 exec calls in my fleet's rollouts, the pragma was used 0 times.

（私のフリートのロールアウトにおける19,392回のexec呼び出しのうち、このプラグマが使われたのは0回だった）

理由として、「回避策を使うには、コマンドを実行する前にその所要時間を知っている必要があるが、それこそrm -rfやbun install、git worktree remove、あるいはユーザー提供の任意のツールでは知りようがないことだ」と述べている。

クォータ100%到達後も課金が止まらなかった疑問

issueはさらに、週次クォータの消費状況についても記録している。

17:40:07 21,664 cumulative tokens 92.0% 17:46:01 4,176,704 95.0% 17:53:23 14,271,350 98.0% 17:57:08 20,084,287 100.0% <-- limit reached

（累計トークンと使用率消化の推移。17:57:08時点で100.0%に到達）

問題のポーリングループが始まったのは18:05頃——クォータが100%に達してから約8分後——で、そこからさらに18分間、約3,460万トークン分のリクエストが受け付けられ続けたという。issueはこの点について次のように問いを投げている。

Is post-100% execution expected behavior? If the limit is a soft accounting boundary rather than an admission gate, that is a reasonable design — but combined with the polling loop above it means a single unattended slow command can spend multiples of a weekly allowance with no backpressure anywhere in the stack.

（100%到達後の実行継続は意図された挙動なのか？ もし上限が実行を止めるゲートではなく、単なるソフトな会計上の境界であるなら、それ自体は合理的な設計かもしれない。しかし上記のポーリングループと組み合わさると、監視されていない1つの遅いコマンドが、システムのどこにもバックプレッシャーが存在しないまま、週次割当の何倍もの分量を消費しうることになる）

関連付けられた8件のissueのうち4件を確認：3件は未解決、1件は「Completed」でクローズ済み

#38495が「同種の症状」として関連付けている8件のissueのうち、タイトルから内容が推測しやすい4件を実際に開いて確認した。

出典: 各issueページ（2026年8月30日確認）

4件のうち3件は本記事確認時点でも未解決（OPEN）のままだが、#38437だけは「COMPLETED」という理由でクローズ済みだった。ただし、これは「止めてと言っても止まらない」という別の症状についてのissueであり、#38495が報告する「code-mode execのポーリング設計そのもの」の問題が同じ形で解決されたことを意味するわけではない。#34115・#36827は、いずれもexecのバックグラウンド待機・yield機構に関わる症状で、#38495が指摘する設計の弱さと重なる部分がありそうだが、それぞれのissue本文を詳細に突き合わせて根本原因の異同を判定する作業までは、本記事では行っていない。

メンテナーの回答が付く前の、報告者側の記録のみ

この記事はGitHub Issue #38495の本文と、関連issue4件のタイトル・状態を一次ソースとしている。issue本文はopenai/codexのメンテナーによる公式な回答・原因究明のコメントを含んでおらず、2026年8月30日にあらためて確認した時点でも#38495はopen状態のままで、コメントが付いた形跡もなかった。issue本文中で「同種の症状」として関連付けられている残り4件（#38093・#38453・#38367・#38480）は、本記事では確認していない。

報告者が示した具体的な数字（90ターン、2,161万トークン、5632:1という比率など）は、報告者が自ら手元のロールアウトログから抽出したものであり、OpenAI側による独立した検証結果ではない。ただし、ターンごとのトークン内訳表やタイムスタンプなど、検証可能な形で数字が提示されている点は、単なる体感の訴えとは一線を画す。この記事を書いている自分自身は、Codexのcode-modeを日常的に使っている実務者ではなく、同種の挙動を自分の手元で再現・検証したわけではない。

関連記事: AIコーディングアシスタント比較 / Claude・GPT・Gemini API料金の読み方

感想・指摘はコメント欄へ。