Codex Desktopの『生きてるか確認』が15.5時間でPro週次枠の90%を溶かした──サブエージェント幽霊化バグを読む

Codex Desktopのマルチエージェント・オーケストレーション機能について、待機・ステータス確認だけの動作が異常な量のトークンを消費するというissueが2026年8月6日に報告された。issue本文によれば、原因は2つ組み合わさっている。1つは、小さな待機・ステータス確認がすべてモデルの1ターンとして扱われ、その都度キャッシュ済みの全コンテキスト（約14万トークン）が再計測されること。もう1つは、完了したサブエージェントがロースター（一覧管理）上で「running」のまま残り続け、親タスクがそれを延々とポーリングし続けてしまうことだ。

3行まとめ

• 完了したサブエージェントが「running」表示のまま残留し、親タスクがそれを永続的にポーリングし続けるライフサイクル上の不具合が報告されている
• 2026年8月4〜6日の観測では、モデルに見える全ツール呼び出しの75%（11,002件中8,744件）がwait/wait_agent/list_agentsで、wait_agent呼び出しの83%（2,122件中1,765件）が「timed_out: true」という空振りの結果だった
• 新規作成したProアカウントが週次利用枠を約15.5時間で0%から90%まで消費し、アカウント使用量APIはその1日だけで約2億9,000万トークンを報告したという

問題の中心——「待つだけ」のターンが全コンテキストを再送信する

issue本文の要約はこうだ。

Long-running Codex Desktop tasks that orchestrate subagents and background commands consume extreme weekly usage while effectively idle. The driver is that every small wait/status result triggers a model turn that re-meters the task's entire accumulated context (~140k tokens at 97–98% cached in our case), and Desktop's orchestration issues these waits on 10–30s timeouts against work that takes minutes to hours.

（サブエージェントとバックグラウンドコマンドをオーケストレーションする長時間のCodex Desktopタスクは、事実上アイドル状態のまま、極端な週次使用量を消費する。原因は、小さな待機・ステータス確認の結果1つひとつがモデルのターンをトリガーし、そのたびにタスクが蓄積した全コンテキスト（今回のケースでは約14万トークン、97〜98%がキャッシュ済み）を再計測することにある。しかもDesktopのオーケストレーションは、実際には数分から数時間かかる作業に対して、10〜30秒というタイムアウトでこの待機を発行し続ける）

具体的な数字——ツール呼び出しの75%が「待つだけ」

issue報告者が示した2026年8月4〜6日の観測データによれば、次のような分布だった。

75% of all model-visible tool calls were wait / wait_agent / list_agents (8,744 of 11,002). […] 83% of wait_agent calls returned timed_out: true (1,765 of 2,122) — no-op turns whose only effect is re-metering the full cached context.

（モデルから見えるすべてのツール呼び出しのうち75%（11,002件中8,744件）がwait／wait_agent／list_agentsだった。〔中略〕wait_agent呼び出しの83%（2,122件中1,765件）は「timed_out: true」を返していた——これは、フルのキャッシュ済みコンテキストを再計測する以外に何の効果もない、空振りのターンだ）

平均すると1ターンあたり約137,000〜141,000トークンの入力があり、そのうち97.4〜98.1%がキャッシュ済みだったという。この状態が1日あたり15,000〜25,000ターン、1ワークステーションあたり1日24億〜36億の入力トークン処理という規模で継続していたと報告されている。ある1つの長寿命スレッドは、その生涯で3,834回もの「wait系」呼び出しを発行していたという。

サブエージェントの「幽霊化」——完了しても消えない

issueが指摘するもう1つの原因は、完了したサブエージェントがロースター上で「running」表示のまま残り続けるライフサイクル上の欠陥だ。

Completed subagents remain running/"Working" in the roster and UI for days. In our local Codex state, 1,154 child-task relationships are marked open; 1,071 have no update for >24h; 815 for >72h; in a 200-item sample, 184 already contained a final answer.

（完了したサブエージェントが、ロースターとUI上で何日も「running」／「Working」のまま残り続ける。私たちのローカルのCodex状態では、1,154件の子タスク関係が「open」のままになっており、うち1,071件は24時間以上、815件は72時間以上更新がない。200件のサンプルでは、184件が既に最終的な回答を含んでいた）

具体例として、あるサブエージェントのロールアウトファイルが06:42に更新を止めたにもかかわらず、07:48時点でもlist_agentsが「agent_status: "running"」と報告し続けていたケースが挙げられている。さらに、スレッドのフォークや継続処理がロールアウト履歴全体を一括で書き直す際（例：1分足らずで86MBのロールアウトが書き込まれ、8,908件のトークンイベントのうち8,879件が履歴の再生だった）、その際に古い「running」表示のエージェントを含む親のロースターごと再インポートしてしまうため、「幽霊エージェント」が世代を超えて生き残り、親は決して状態が変わらないエージェントをポーリングし続けることになるという。

list_agents自体の設計にも問題があると指摘されている。

list_agents embeds each completed agent's entire final message in the roster payload, so every roster check re-injects those reports into context.

（list_agentsは、完了した各エージェントの最終メッセージ全文をロースターのペイロードに埋め込んでいる。そのため、ロースターを確認するたびに、それらの報告がコンテキストへ再注入される）

影響——15.5時間でPro週次枠の90%

issueが報告する実際の影響は次の通りだ。

Fresh Pro weekly limit 0% → 90% in ~15.5 hours, dominated by two long-lived tasks; ~290M account-reported tokens in one day.

（新規作成したProアカウントの週次利用枠が、約15.5時間で0%から90%に達した。主な原因は2つの長寿命タスクだった。その1日だけでアカウント側が報告したトークン数は約2億9,000万に及んだ）

報告者は、この問題がCodex Desktopのマルチエージェント機能の使われ方そのものに起因すると指摘する。

The workload pattern (agentic delivery with verifier subagents and CI waits) is exactly what Desktop multi-agent encourages, so this scales with adoption of the feature.

（この作業パターン（検証用サブエージェントとCI待機を伴うエージェント的な作業遂行）は、まさにDesktopのマルチエージェント機能が推奨するものであり、この機能の採用が進むほどこの問題は拡大する）

GitHub側のクロスリファレンスで見つかった関連issue

issue #37299のページをGitHub上で確認すると、投稿者本人が明示的にリンクしていた#4764に加えて、GitHubの自動クロスリファレンス機能が検出した、症状の重なる別issueが1件あった。

出典: GitHub issueページのクロスリファレンス情報（2026年8月30日確認）

#37426は#37299の翌日、Windows版のCodex Desktopで報告されたもので、「完了したはずのサブエージェントがUI上でWorking状態のまま残り続ける」という症状は#37299が指摘する「幽霊化」とほぼ同じだ。加えて、子タスクが起動するたびにローカルのstdio MCPサーバー一式を毎回立ち上げ直しているという、#37299の本文にはなかった追加のオーバーヘッドも報告されている。この2件が根本原因を共有しているかどうかは、それぞれのissue本文の記述からの推測であり、断定はできない。

なお、#37299のページ自体には、この記事の確認時点（2026年8月30日）でラベルが一切付いていなかった（"No labels"）。同じバッチで扱った他のCodex issue（例えば別記事で扱った#38495にはbug・exec・rate-limits等のラベルが付いている）と比べると、この#37299はメンテナー側のトリアージ作業がまだ及んでいない状態だとうかがえる。

コメント欄に集まった独立した再現報告

issue #37299のコメント欄には、報告者本人以外による独立した再現報告が2026年8月13日から8月27日にかけて4件寄せられている（2026年8月30日確認時点）。そのうち2件は、報告者の数字と桁のオーダーが近い、規模の大きい再現例だ。

ユーザーGorangNは、Codex app-server 0.148.0-alpha.9・GPT-5.6 Sol xhigh・マルチエージェント構成で次のように報告している。

In my case, a single multi-agent session exhausted essentially 100% of my weekly Codex allowance in about two hours. […] After deduplicating forked/replayed token_count history, my local rollout analysis indicates approximately: 174M total processed tokens […] ~135k average input tokens per parent model turn […] 8 of 9 observed wait_agent calls timed out.

（私のケースでは、単一のマルチエージェント・セッションが約2時間で週次Codex利用枠のほぼ100%を使い切った。〔中略〕フォーク・再生によるtoken_count履歴の重複を除去した上でローカルのロールアウトを分析すると、おおよそ処理トークン総数1億7,400万、〔中略〕親モデルの1ターンあたり平均約13万5,000入力トークン、観測された9件のwait_agent呼び出しのうち8件がタイムアウトしていた）

週次利用枠は19:37（CEST）の約0%から21:40頃には100%に達したとしている。親スレッドが2波にわたって6つのサブエージェントを生成し、いずれもGPT-5.6 Sol xhighを継承していたという。

別のユーザーlunara69-ctrlは、Linux版Codex CLIでの監査結果として、報告者よりも小規模ながら同じ質のパターンを観測したと述べている。

Across one audited workflow: 58 no-new-information WAIT/POLL model continuations […] 6,787,563 total input tokens attributable to those continuations […] ~117,027 input tokens per WAIT/POLL continuation on average.

（監査した1つのワークフローでは、新規情報を含まないWAIT/POLL系のモデル継続処理が58回あり、そこに帰属する入力トークンは合計6,787,563、WAIT/POLL継続1回あたり平均約117,027入力トークンだった）

これらはいずれも報告者本人の測定と同様、ローカルのロールアウトログ・JSONLからの自己集計であり、OpenAI側が確認・検証したものではない。

提案されている修正の方向性

issueは4つの改善案を提示している。要約すると、(1) 10〜30秒ごとにフルコンテキストのモデルターンを課金するのではなく、サブエージェント・コマンドへの境界付き待機を安価にする専用のプリミティブを用意する、(2) 完了したサブエージェントを親が刈り取らなくても自動的に「running」から遷移させ、フォーク・継続処理で古いロースターを再インポートしないようにする、(3) list_agentsは最終メッセージ全文ではなく名前・状態・タイムスタンプの要約だけを返すようにする、(4) オーケストレーションのターンにおけるキャッシュ済みコンテキストが、プランの利用上限に対してどう重み付けされるかを明確化する（関連issue #4764へのフォローアップ）、というものだ。

アルファ版時点の報告で、現行版での再現は未確認

この記事はGitHub Issue #37299の本文と、関連issue2件（#4764・#37426）を一次ソースとしている。#37299は2026年8月6日に報告され、2026年8月30日にGitHub API（api.github.com/repos/openai/codex/issues/37299）であらためて確認した時点でもopen状態・ラベル無し・コメント4件のままだった。issue本文中で挙げられている数字（75%、83%、約15.5時間、約2億9,000万トークンなど）は、報告者が自身のローカルセッションのロールアウトログから抽出した値であり、OpenAI側による本issue上での公式な検証や確認コメントは、本記事の確認範囲では見当たらなかった。

「Codex Desktop（app-server 0.147.0-alpha.1.2）」というバージョン表記から、報告時点ではアルファ版であったことがうかがえる。GitHubのリリース一覧を2026年8月31日に確認したところ、この間にopenai/codexはrust-v0.148系からrust-v0.152.0-alpha.6（2026年8月31日公開）まで版を重ねており、直接this issueを参照した修正コミットは確認できなかった。ただし1件、関連しうる変更として、2026年8月29日公開のrust-v0.151.0に「ネストしたサブエージェントのトークン使用量をルートゴールの予算に算入する」（PR #41183、2026年8月27日マージ）という修正が含まれていた。PR本文は次の通りだ。

Roll token usage from spawned descendants, including nested subagents, into the root goal's usage. Apply descendant usage during active and idle progress accounting so it contributes to token budgets.

（生成された子孫、ネストしたサブエージェントを含むトークン使用量を、ルートゴールの使用量に組み入れる。アクティブ時・アイドル時の両方の進捗計算にこの子孫の使用量を反映させ、トークン予算に寄与させる）

このPRの説明文にもコミット履歴にもissue #37299・#37426への直接の言及はなく、これが本記事で扱った「待機だけで全コンテキストが再計測される」問題や「幽霊化したサブエージェント」を修正するものかどうかは、確認できていない。あくまで「サブエージェントのトークン計上ロジックに変更が入った」という事実のみが確認できたものであり、この記事の執筆時点での最新版でissue本文の不具合が引き続き再現するかどうかは未確認のままだ。

この記事を書いている自分自身は、Codex Desktopのマルチエージェント機能を日常的に使っている実務者ではなく、報告された挙動を自分の手元で再現・検証したわけではない。

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

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