最近、Codex Appのtask切り替えや、task間の操作が重く感じることが増えた。
最初は、同時に開いているtaskや補助processが多いからだと思っていた。
ただ、ローカル環境をmetadataだけで確認すると、別の数字が見えてきた。
Codexのrollout履歴が374件。
合計26.62GiBまで増えていた。
rolloutは、短い会話だけを残す軽いテキストではない。
長時間task、toolの呼び出しと出力、画像入力、compaction後の状態などが積み上がるため、使い方によってはかなり大きくなる。
そこで、不要なtaskは公式のcodex deleteで削除した。
残したい古いtaskは、Codex CLI 0.144.5に入っていた開発中の圧縮実装を5件だけ検証した。
2026年7月19日17時18分の再計測では、plain rollout 154件とcompressed rollout 5件、合計18.57GiB。
開始時から8.05GiB、30.2%減った。
ただし、容量が減ったからCodex全体が必ず速くなる、という話ではない。
削除、archive、/compact、rollout圧縮は目的が違う。
この記事は、Codexの履歴を手動で消す手順ではありません。
公開してよいmetadataだけで整理対象を分け、公式の削除経路と限定的な圧縮検証で容量を減らした記録です。
確認環境はCodex CLI 0.144.5。
数値と仕様は2026年7月19日時点のものです。
Codex Appが重くなり、ローカル履歴を確認した
自分はCodexを、たまにコードを書くためのCLIとして使っていない。
ブログ記事、WordPress、GitHub、調査、AIチームの受け渡し、公開後の確認まで、日々の仕事にかなり入り込んでいる。
taskも短いものだけではなく、数日続く役割taskや、画像・ブラウザ操作を含む作業がある。
最近、そのCodex Appでtaskを開く時や、履歴を読む操作が重く感じる場面があった。
ここで、いきなりsessions directoryを開いて中身を調べることはしなかった。
rollout本文には、会話、prompt、response、tool出力、作業内容が含まれ得る。
最初に使ったのは、自分で公開しているcodex-healthkitです。
codex-healthkit check --json
du -sh ~/.codex/sessions ~/.codex/archived_sessions見るのは、ファイル数、容量、更新時刻、active / archivedなどのmetadataだけ。
credentials、token、cookie、SQLite本文、session transcript本文は読まない。
調査開始時のrolloutは374件、28,581,097,183 bytes、26.62GiBだった。
古い履歴が少しずつ増えただけではなく、最近更新された長時間taskの容量が大きい状態でした。
同じような報告はOpenAIのGitHub Issueにもある。
Issue #24948では、ある利用者のsessions directoryが約91GB、100MBを超えるJSONLが184件、最大ファイルが約1.95GBになったと報告されています。
Issue #25215には、約3.06GBまで増えた長時間threadをDesktop更新後にresumeできなくなったという報告もある。
ただし、どちらも個別環境の報告です。
自分の26.62GiBと同じ原因だとは決めつけない。
rolloutは会話だけを保存するファイルではない
rolloutはJSONL形式の実行履歴です。
会話文だけではなく、taskを再開するための情報が積み上がる。
公式実装を見ると、message、tool call、tool result、turn context、compaction後の状態、world state、eventなど複数の記録種別があります。
画像入力がinlineのdataとして残る場合や、terminal・browser・build・testの大きな出力がtool resultへ入る場合もある。
つまり、形式はテキストでも、中身が短い文章だけとは限らない。
一方で、repoやローカルファイルが自動的に丸ごと複製されるわけでもない。
Codexが読み、tool出力として履歴へ含めた内容が積み上がり得る、という理解が近い。
今回は安全境界を優先し、実rolloutの本文や内訳は調べていない。
そのため、画像、compaction、大量出力のどれが自分の環境で最大要因だったかまでは断定しません。
/compact・archive・deleteは役割が違う
履歴を整理する前に、似て見える操作を分けた。
/compactは、現在のchat contextを要約して空きを作るもの。
公式docsでは、以前のturnを簡潔なsummaryへ置き換え、重要な情報を残しながらcontextを空けると説明されています。
これは、保存済みrolloutのディスク容量を減らす機能として案内されているものではない。
archiveは、activeな一覧を整理する操作です。
transcriptはローカルに残るため、archiveしただけでは容量削減にならない。
deleteは別です。
公式のcodex deleteは保存sessionを永久削除するstable commandで、削除後は元へ戻せない。
今回、容量を減らすために使ったのはdelete。
一覧を片付けるarchiveや、contextを整える/compactとは目的が違います。
metadataだけで削除候補と保護対象を分けた
26.62GiBあるからといって、古い順に全部消すわけにはいかない。
継続して使う役割taskがある。
自動処理やtask間の受け渡し先になっているものもある。
まだdocsやGitへ成果を残せていないtaskもあり得る。
そこで、削除候補はmetadataだけで分けた。
- 完了済みの単発taskか
- 継続中の作業ではないか
- 現在の役割taskや自動処理から参照されていないか
- 未処理の受け渡し先ではないか
- 成果と判断がdocs、Git、Task Control Roomへ残っているか
- 親taskと一緒に消える子taskがないか
task名、thread ID、route、automation IDは公開しない。
rollout本文やSQLite本文も見ていない。
ここで大事だったのは、容量ではなく成果の正本を先に決めること。
作業結果が会話の中にしかないtaskは、削除できない。
docsやGitへ成果を残せていれば、不要になった実行履歴を判断しやすくなる。
不要taskは公式codex deleteで段階的に削除した
codex deleteは永久削除です。
継続task、自動処理、受け渡し先、未保存の成果が残っていないことを確認してから使う必要がある。
手動でJSONLを削除したり、SQLiteを直接更新したりはしなかった。
Codexが管理しているrolloutとindexの整合を壊さないため、公式CLIだけを使いました。
codex delete <SESSION>自分の限定運用では、metadataで対象を十分に確定したうえで、UUID指定の--forceも使った。
ただ、確認を省く操作を一般向けの例にはしない。
誤削除を避けるため、記事では対話確認のある標準commandだけを載せています。
UUIDの探し方や、一括削除scriptも載せません。
今回は、小さなpilotから始め、その後も段階ごとに保護対象とindexの整合を確認した。
最終的に公式deleteで削除したのは220 task。
操作上の削減量は約9.98GiBでした。
削除対象の残留は0。
保護した継続taskも残っていることを確認した。
継続taskはcold rollout圧縮を5件だけ検証した
削除できない古いtaskには、容量を減らしながら履歴とtask IDを残したいものもある。
Codex CLI 0.144.5の公式ソースには、local_thread_store_compressionという実装がありました。
7日以上更新されていないrolloutをzstd level 3で圧縮し、圧縮結果を展開検証してからplain fileを削除する仕組みです。
ただし、feature registry上の状態はUnderDevelopment。
既定offです。
一般利用者向けの安定機能として勧められる段階ではない。
この記事にも有効化commandは載せません。
自分の環境では、routeや自動処理から参照されず、7日以上更新されていないcold rolloutを5件だけ選んだ。
圧縮後は、zstdの検証、全展開後のSHA-256一致、同じtask IDでreadできることを確認した。
5件の圧縮前は合計約2.70GiB、圧縮後は約1.81GiB。
削減量は954,625,581 bytes、約910MiBだった。
容量は減った。
でも、readは速くならなかった。
zstdの展開が入るため、遅くなる可能性もある。
今回確認できた圧縮の効果は、ディスク容量の削減です。
速度改善策としては扱いません。
rolloutを26.62GiBから18.57GiBへ減らせた
2026年7月19日17時18分に、記事化前の状態を再計測した。
| 項目 | 結果 |
|---|---|
| 調査開始時 | 374 rollout / 26.62GiB |
| 公式delete | 220 task / 約9.98GiB削減 |
| cold rollout圧縮 | 5件 / 約910MiB削減 |
| 再計測時 | plain 154件 + compressed 5件 / 18.57GiB |
| 開始時からの純減 | 8.05GiB / 30.2% |
| archived rollout | 0件 / 0B |
ここは数字を分けて見た方がいい。
公式deleteと圧縮を足した操作上の削減効果は約10.87GiB。
一方、作業中にもactive taskは増えている。
そのため、開始時の26.62GiBと再計測時の18.57GiBを比べた純減は8.05GiBです。
「10.87GiB消した」と「全体が8.05GiB減った」は別の数字。
同じ結果として混ぜない。
なお、同時点のcodex-healthkit check --jsonではsessions directory全体が約18.79GiBだった。
こちらにはrollout以外の管理ファイルも含まれるため、rolloutだけの18.57GiBとは一致しません。
容量削減とthread toolの改善は分けて考える
公式delete後、同じtaskをmetadata-onlyで読む時間は、削除前1回の8.9秒から、削除後5回の中央値3.1秒へ短縮した。
数字だけ見ると改善している。
ただ、削除前は1回しか測っていない。
cache、内部queue、taskの状態、tool bridgeの変動も除外できない。
なので、「rolloutを削除したからreadが速くなった」とは断定しない。
過去に70秒を超えたlist_threadsのtimeoutも、今回の確認では再現しなかった。
これも、容量だけで説明できる材料ではない。
Codex Appの重さには、同時task、補助process、巨大な単一rollout、内部queueなど複数の要因があり得る。
今回、確実に言えるのは二つ。
rolloutのディスク使用量を8.05GiB減らせた。
保護対象を残し、公式deleteと限定圧縮の整合確認を通せた。
そこから先の速度は、継続して観測する話です。
docsを正本にして、task履歴を定期整理する
今回の整理で、一番大きかったのは削除commandではない。
成果を会話の外へ残しておくことだった。
記事原稿はdocsへ残す。
実装はGitへ残す。
タスクの状態はTask Control Roomへ残す。
継続taskのrouteや受け渡し先も、削除前に確認する。
この型があれば、Codexのtask履歴をすべて永久保存しなくてもよくなる。
自分の運用では、今後もcodex-healthkitでmetadataだけを定期確認する。
archiveは一覧整理として使い、容量対策とは分ける。
不要taskを削除する前には、成果の保存先と参照状態を確認する。
大きな作業が終わったら、同じtaskへ積み続けるのではなく、docsへcloseoutを残して次のtaskへ移る。
resumeが不要な単発処理では、履歴を保存しない実行方法も検討する。
rolloutが増えること自体は、Codexを使った記録が残っているということでもある。
問題は、何を残し、何を正本にするかが決まっていないこと。
まずは容量と件数を見る。
削除する前に成果を残す。
消すなら公式経路を使う。
開発中機能は小さく検証する。
Codexの履歴整理は、その順番で進めるのがよさそうです。
Codexの履歴管理そのものを解説する本ではありませんが、AIエージェントがツールやAPIを使って仕事を進める仕組みを整理したい人には、この入門書が分かりやすいです。
今回のような長時間taskや運用設計を考える前提をつかむ補助になります。
ポチップ
関連記事
- Codexを日々使う人へ。ヘルスチェックCLI「codex-healthkit」を公開しました
- Codexを使い倒すなら、使用量だけでなくローカル環境も点検すべきって話
- Codexを日々使うならCLI更新前後の状態を点検しておくべき