AI 注目記事

【2026年9月3日】実際に自分の.codexフォルダを確認したら19.4GBになっていた

記事内に広告・プロモーションを含む場合があります。

原因のほとんどはsessionsフォルダだった

その後もCodexを継続して使用していましたが、改めて自分のPCにある .codex フォルダの容量を確認したところ、約19.4GBまで増えていることに気付きました。

そこで今回は、実際にどのファイルが容量を使っているのか調査してみました。

最初に .codex 内のフォルダごとの容量を調べたところ、結果は次のようになりました。

.codex 全体：約19.4GB

sessions       18.25GB
plugins         0.41GB
.sandbox-bin    0.36GB
.tmp            0.18GB
その他          少量

なんと、約19.4GBのうち18.25GBをsessionsフォルダが占めていました。

割合にすると約94％です。

以前から問題になっていたSQLiteログも確認しましたが、私の環境では、

logs_2.sqlite        約124MB
logs_2.sqlite-wal      約4MB

程度でした。

少なくとも今回の私の環境では、SSD容量を圧迫していた主原因はSQLiteログではなく、過去のCodexセッションでした。

巨大なrollout JSONLを発見

さらにsessionsフォルダの中を容量順に調べたところ、7月に作成されたセッションに非常に大きなファイルが残っていました。

上位6ファイルは次のとおりです。

5.545GB
3.332GB
2.298GB
1.920GB
1.566GB
0.764GB

すべてCodexがセッション履歴として保存している、

rollout-*.jsonl

というファイルです。

このわずか6ファイルだけで合計約15.43GBありました。

最大のファイルは5.545GBです。

ゲームデータや3Dモデルではありません。

AIとの作業セッション1本だけで5GBを超えていました。

さすがにこれは驚きました。

最終更新日も確認

現在使用中のセッションを誤って移動しないように、ファイルの最終更新日時も確認しました。

今回見つかった6ファイルは、

作成日：2026年7月13日～7月22日
最終更新：2026年7月13日～7月30日

となっており、9月3日時点ですべて1か月以上更新されていませんでした。

そのため、今回は削除するのではなく、念のためDドライブへバックアップとして退避することにしました。

いきなり削除せずバックアップへ退避

rollout-*.jsonlは単なるキャッシュではなく、過去のCodexセッションに関係するデータです。

そのため、容量が大きいからといっていきなり削除するのではなく、

C:\Users\ユーザー名\.codex\sessions

から、

D:\sessions_backup

へ古い巨大セッションだけを移動しました。

※ファイルを移動する場合は、念のためCodex Desktopを完全終了してから行うことをおすすめします。

18.25GBから2.82GBまで減少

6ファイルをDドライブへ退避したあと、再びsessionsフォルダの容量を確認しました。

結果は、

移動前：18.25GB
移動後： 2.82GB

となりました。

約15.43GBの削減です。

つまり、今回 .codex が約19.4GBまで増えていた原因の大部分は、7月に作られたわずか6本の巨大なセッションファイルだったことになります。

自分の環境を確認する方法

同じようにCodexを長期間使用している方は、一度sessionsフォルダの容量を確認してみることをおすすめします。

PowerShellで次のコマンドを実行します。

$size = (Get-ChildItem "C:\Users\ユーザー名\.codex\sessions" -Recurse -File |
Measure-Object Length -Sum).Sum

"{0:N2} GB" -f ($size / 1GB)

※「ユーザー名」の部分は自分のWindowsユーザー名へ変更してください。

さらに、容量の大きなセッションを確認する場合はこちらです。

Get-ChildItem "C:\Users\ユーザー名\.codex\sessions" -Recurse -File |
Sort-Object Length -Descending |
Select-Object -First 30 `
    @{Name="SizeGB";Expression={[math]::Round($_.Length/1GB,3)}},
    LastWriteTime,
    FullName |
Format-Table -AutoSize

これで、どのrollout-*.jsonlが容量を使用しているのか確認できます。

古いからといって、すぐ削除するのはおすすめしない

注意したいのは、巨大なJSONLを発見してもすぐ削除しないことです。

私は今回、

  1. ファイル容量を確認
  2. 最終更新日時を確認
  3. 1か月以上更新されていないことを確認
  4. Codexを終了
  5. 別ドライブへバックアップとして移動

という手順を取りました。

しばらくCodexを使用して問題がないことを確認してから、バックアップを今後も残すか削除するか判断する予定です。

9月3日時点で分かったこと

今回、自分の環境を実際に調査したことで重要なことが分かりました。

Codexのストレージ問題というと、これまでlogs_2.sqliteやlogs_2.sqlite-walへの大量書き込みが注目されていました。

しかし、私の環境では、

logs_2.sqlite       約124MB
logs_2.sqlite-wal     約4MB

sessions            18.25GB

でした。

つまり、現在の環境ではSQLiteよりもセッション履歴の方が圧倒的に大きなストレージ消費要因になっていました。

しかも18.25GBのうち約15.43GBは、たった6本の古いセッションです。

Codexを長時間利用している方、特にAIエージェントへ長期間の開発作業を任せている方は、SSDの空き容量だけを見るのではなく、

C:\Users\ユーザー名\.codex\sessions

の容量も一度確認してみることをおすすめします。

少なくとも私の環境では、古いセッションを別ドライブへバックアップしただけで、Cドライブから約15GBを回収することができました。

それではここまでご覧いただきありがとうございます！

次回もよろしくお願いします


-AI, 注目記事