- Codex CLI で再開された長期セッションが Subagent を繰り返し生成する際、
~/.codex/sessions配下の JSONL セッションファイルが異常に増大する問題が報告された - 公開事例では、1つの再開された親セッションから 2,393 個の Subagent セッションファイルが生成され、それらが約 731.5GiB を占有した
- Codex のセッションデータ全体は約 755GiB まで増え、1.8TiB の APFS ボリューム使用率が 99〜100% に達した
- 短い Subagent セッションでも数十万件のイベントが記録され、別のセッションでは
compacted履歴と Tool output が数百 MB 単位で繰り返し保存されていた - この問題は最新事例の Codex CLI 0.144.6 でも確認されており、関連する GitHub Issue は 2026年7月20日現在オープンのまま
問題の症状
Codex CLI はセッションを再び開けるように、次のパスへ会話と実行履歴を JSONL 形式で保存する。
~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
2026年7月18日に登録された事例では、~/.codex 全体が約 760GiB、そのうち ~/.codex/sessions が約 755GiB を使用し、7月のセッションだけで約 734GiB を占めていた。
760G ~/.codex
755G ~/.codex/sessions
734G ~/.codex/sessions/2026/07
このデータはキャッシュではなく、codex resume に使われるセッション履歴であるため、ファイルを削除すると過去のセッションを再び開けなくなる可能性がある。報告当時も複数の Codex プロセスが該当 JSONL ファイルを開いたままだった。
どれほど速く増えたのか
この事例の7月ディレクトリには約 2,931 個のセッションファイルがあり、そのうち 797 個がそれぞれ 400MiB を超えていた。7月11日には1日で約 109.1GiB、7月12日には約 149.2GiB のセッションデータが生成されたと集計されている。
日付 セッションファイル 400MiB超 おおよその容量
7月10日 50 0 2.8GiB
7月11日 473 0 109.1GiB
7月12日 506 0 149.2GiB
7月15日 340 265 108.6GiB
7月16日 355 263 109.0GiB
7月17日 300 189 81.7GiB
容量の大半は、1つの再開された親セッションに紐づいていた。この親セッションは 2,393 個の Subagent JSONL ファイルを生成し、それらの論理サイズの合計は約 731.5GiB だった。調査時点で、親の codex resume プロセスは約23時間実行中だった。
どのような workload で発生したのか
報告された workflow は次の通り。
- ローカルプロジェクトで Codex TUI を実行
- Subagent またはコラボレーション機能を使う長期セッション作業
- 既存の親セッションを
codex resume <thread-id>で再開 - 再開されたプロセスを数時間にわたり実行し続ける
- 親セッションが depth 1 の Subagent を繰り返し生成
この workflow では、1日に数百個の子 JSONL ファイルが生成され、多数のファイルが数分以内に 400〜500MiB まで増大した。ただし報告者は、これは最小再現手順ではなく、実環境で観察された再現 workflow だと明記している。
したがって、現在公開資料で確認できる主な増幅条件は次の組み合わせである。
長時間実行される親セッション
+ codex resume
+ 繰り返される Subagent 生成
+ Context Compaction
+ Tool output およびセッションイベントの永続保存
この組み合わせは公開事例のデータで確認されているが、各要素のいずれか1つだけで常に問題が発生するかは、まだ立証されていない。
単一ファイルの内部では何が増えたのか
代表的な Subagent の1つは約3分19秒実行されただけだったが、483,714,063バイトと 353,255 件の JSONL レコードを記録していた。これは毎秒約 1,770 件のレコード、約 2.31MiB の書き込み量に相当する。
このファイルで大きな割合を占めたレコードは次の通り。
event_msg/token_count 185,461件 約 139.3MB
compacted 1,618件 約 121.6MB
event_msg/patch_apply_end 36,295件 約 110.7MB
event_msg/agent_message 104,653件 約 41.6MB
response_item/message 9,947件 約 34.4MB
world_state 607件 約 18.6MB
turn_context 5,322件 約 11.0MB
1つの巨大な JSON レコードがファイルの大半を占めていたのではなく、短い実行時間のあいだに複数種類のイベントが数千〜数十万回記録された形だった。報告者はこれを深刻な event amplification と分析している。
別の代表的なファイルは約 925.6MB で、compacted レコード 175 件が約 571.6MB、custom_tool_call_output 27,848 件が約 211.7MB を占めていた。このファイルは、イベント数だけでなく、大きな Compaction および Tool output payload の反復保持も容量増加に寄与している根拠として提示されている。
発生原因は何か
現在 GitHub Issue には、OpenAI が確定した Root Cause Analysis は投稿されていない。したがって以下は、セッションファイルを調査した報告者のデータから導かれる推定原因である。
1. Subagent ごとのイベント増幅
約3分実行された Subagent 1つに、token_count が18万件超、agent_message が10万件超、patch_apply_end が3万件超保存されていた。通常のユーザーに見える activity より多くのイベントが子セッション writer に渡されたり、繰り返し記録されたりした可能性が指摘されている。
2. Compaction history の反復保存
大きなセッションでは、compacted レコードがファイルの大半を占めていた。別の Codex Issue #24948 でも、Context Compaction の replacement_history と元の Tool output が繰り返し保存され、単一 JSONL が 732MB、sessions ディレクトリ全体が約 91GB まで増えた事例が報告されている。この Issue は Codex CLI 0.118.0 と macOS arm64 環境で再現され、2026年5月28日に登録された。
3. Resume 時の過去履歴の重複 materialization
Windows Codex App の別 Issue #29531 では、2GB 以上に増えた既存セッションを Resume すると、新しい日付ディレクトリに再び 2.3〜2.4GB サイズの rollout ファイル群が生成された事例が報告されている。報告者は、新しいファイルが増分イベントだけを記録するのではなく、既存の historical context をコピーまたは replay していると推定している。
4. Subagent ファイルごとの親状態または出力の重複
Issue #34061 では、1つの親セッションから生成された 2,393 個の子セッションが約 731.5GiB を占め、子ファイルで compacted、Tool output、高頻度イベントが繰り返し観察された。これに基づき、親状態やイベント stream が Subagent ごとの JSONL に重複記録されることが、主要な増幅要因の1つと推定されている。これは現在の公開データを使った推論であり、OpenAI が確定した原因ではない。
現在の修正状況
最大規模の Subagent ディスク使用問題を扱う Issue #34061 は、2026年7月20日現在オープンであり、Issue に表示されている再現バージョンは Codex CLI 0.144.6 である。
Compaction および Tool output 問題を扱う Issue #24948 も現在オープンで、Resume 重複問題を扱う Issue #29531 もオープンのままだ。
したがって、現在公開されている Issue の状態だけを基準にすると、セッション JSONL 増大問題全体が解決されたと見なせる正式リリースは確認されていない。それぞれの Issue が同じコード欠陥に起因するのか、複数の persistence 問題が結合したものなのかも、まだ確定していない。
確認方法
セッション全体の容量確認:
du -sh ~/.codex/sessions
年月別の容量確認:
du -sh ~/.codex/sessions/*/*
最大の JSONL ファイル確認:
find ~/.codex/sessions \
-type f \
-name '*.jsonl' \
-exec du -h {} + |
sort -hr |
head -30
月別ファイル数の確認:
find ~/.codex/sessions/2026/07 \
-type f \
-name '*.jsonl' |
wc -l
Issue #34061 と似たケースでは、特定月のファイル数が急増したり、数百 MB サイズの子セッションファイルが数百〜数千個見つかったりする可能性がある。
暫定対応
公式修正が確認されるまでは、次の workload を減らすことが妥当な暫定対応となる。
- 1つの親セッションを長時間
codex resumeで維持しない - 再開された長期セッションで Subagent を大量に生成しない
- 大きなコマンド出力をそのまま context に返さず、ファイルに保存してから必要な部分だけ参照する
~/.codex/sessionsの月別容量と大きな JSONL ファイルを定期的に確認する
これは Issue #24948、#29531、#34061 で観察された増幅条件を避けるための予防策であり、公式に検証された workaround ではない。
セッションファイルを削除すればディスク容量は回収できるが、該当セッションを codex resume で再び開けなくなる可能性がある。先に Codex プロセスを終了し、必要なセッションをバックアップしてから削除する方が安全である。
関連する別 Issue: SQLite フィードバックログの書き込み増幅
この問題は GeekNews で紹介された logs_2.sqlite の過剰ロギング問題 とは、保存場所と役割が異なる。
既存 Issue は、次のファイルにグローバルな TRACE レベルの diagnostic および feedback ログを継続保存し、SSD 書き込み量を増幅させた問題だった。
~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm
この問題は 2026年6月14日に GitHub Issue #28224 として報告され、WebSocket イベントおよびノイズログを減らす PR がマージされ、約 85% のログが削減されたと整理されている。一部の修正は Codex 0.142.0 に含まれ、追加修正は 0.143.0 リリース対象として記録されている。
一方、今回の問題は Resume 可能なセッション履歴を保存する ~/.codex/sessions/**/rollout-*.jsonl が対象であり、Context Compaction、Resume、Subagent session persistence が主な増幅条件として観察されている。SQLite feedback log の修正だけで session JSONL 問題が解決したという根拠はない。
まとめ
Codex CLI のセッションストレージは、長時間 Resume された親セッションが Subagent を繰り返し生成する workload で異常に増大する可能性がある。最大の公開事例では、1つの親セッションから生成された 2,393 個の子セッションが約 731.5GiB を占め、sessions ディレクトリ全体は約 755GiB まで増大した。
セッション内部では、短時間に数十万件のイベントが記録される event amplification と、compacted history および Tool output の反復保持があわせて観察された。Resume 時に既存の multi-GB history が新しい rollout ファイルへ再生成される別事例も報告されている。
問題は macOS Codex CLI で最大規模として報告されたが、Windows Codex App でも類似の session duplication が確認されており、2026年7月20日現在、主要な関連 Issue はオープンのままだ。公式修正が確認されるまでは、長期 Resume と大量の Subagent 利用を制限し、~/.codex/sessions のサイズを定期的に確認する必要がある。
2件のコメント
私もMacBookの容量が足りなくて外付けSSDまで買ったんですが、
これはまず確認してみないといけませんね 🥲
最近、MacBookの容量が不足しているという通知が頻繁に出るので調べてみたところ、codex cliが原因でした。私も今、余裕がない中で数十GBを食っているので、過去の履歴を削除しようか悩んでいるのですが、皆さんはどう対処されていますか？