Xで、CodexのログファイルがSSDに大量書き込みしている、という投稿を見かけました。
「年間で数百TB相当の書き込みになるかもしれない」
「MacのSSD寿命が削られるかもしれない」
そんな話を見たら、さすがに不安になります。
Macの内蔵SSDは、あとから簡単に交換できるものではありません。私はエンジニアではなく、Codexも「便利そうだから使ってみている」くらいの温度感です。
急に logs_2.sqlite-wal とか SQLite とか言われても、最初は何のことかよく分かりませんでした。
とはいえ、本当に裏でSSDへ大量に書き込み続けているなら怖いです。気持ち悪いので、自分のMacで実際にどうなっているのかを確認してみました。
先に結論
私の環境では、今のところCodexによる異常な大量書き込みは確認できませんでした。
確認したときの数字は、だいたいこんな感じです。
~/.codex 全体 1.9G
logs_2.sqlite 181M
logs_2.sqlite-wal 約6M
.codex フォルダ全体は1.9GBありました。最初は「けっこう大きいな」と思いましたが、中身を見ると、主な正体はセッション履歴のようなものでした。
話題になっていた logs_2.sqlite-wal は数MB程度で、数GBや数十GBに膨らんでいる状態ではありませんでした。
さらに、アクティビティモニタでもCodex関連プロセスの「書き込みバイト数」を見ました。起動直後から数百MB程度の書き込みはありましたが、その後、何もしていない状態で短時間にGB単位へ増え続けるような動きは確認できませんでした。
今回分かったのは、ひとつの数字だけで判断しない方がいいということです。
.codex が1.9GBあることと、SSDへ1.9GBだけ書き込んだことは別です。logs_2.sqlite-wal が数MBだからといって、SSDへの累計書き込み量まで少ないとは限りません。アクティビティモニタの「書き込みバイト数」も、SSDの寿命情報そのものを直接見ているわけではありません。
そこで今回は、ログファイルのサイズと、アクティビティモニタでの増え方をセットで見ることにしました。
以下の最新のバージョンにアップデートしていたから、すでに修正が入っていたのかもしれません。
Version 26.616.81150
Released Jun 24, 2026
問題になっていたファイル
今回話題になっていたのは、CodexがMac内に作るローカルログのようです。
場所はこのあたりです。
~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm
特に名前が出ていたのが、logs_2.sqlite-wal でした。
ざっくり言うと、logs_2.sqlite はログを保存するデータベース本体で、logs_2.sqlite-wal は一時的な書き込み用ファイルのようなものです。
私はターミナルで使うCodex CLIではなく、MacのCodexアプリを使っています。
最初は「CLIだけの話なら、自分には関係ないのでは？」とも思いました。
ところが、自分のMacにも .codex フォルダがあり、同じようなログファイルが存在していました。Codexアプリしか使っていない人でも、一度見ておいた方が安心だと思います。
まずログファイルのサイズを確認した
Macのターミナルを開いて、次のコマンドを入力しました。
ls -lh ~/.codex/logs_2.sqlite*
du -sh ~/.codex
非エンジニアには、このくらいの素直なコマンドの方が分かりやすいです。
No such file or directory や zsh: no matches found のような表示が出た場合は、Codexのログファイルがまだ作られていないか、保存場所が違う可能性があります。
私の環境では、だいたい次のような結果でした。
logs_2.sqlite 181M
logs_2.sqlite-shm 32K
logs_2.sqlite-wal 4.1M
~/.codex 全体 1.9G
最初に .codex 全体が1.9GBと出たので、少し驚きました。
この1.9GBは「SSDにこれだけ書き込まれた」という意味ではありません。あくまで、今そのフォルダがSSD上で使っている容量です。
たとえるなら、フォルダ容量は「部屋に置いてある荷物の量」です。SSDへの累計書き込み量は「その荷物を何回出し入れしたか」に近い。同じ1.9GBでも、一度置いただけなのか、何度も書き換えられているのかで意味は変わります。ここを混同すると、必要以上に不安になります。
logs_2.sqlite-wal が小さくても、それだけでは判断できない
私の環境では、logs_2.sqlite-wal は最終的に6MB前後でした。
logs_2.sqlite-wal 約6M
これだけ見ると、「6MBなら全然大丈夫そう」と思いたくなります。
ここが少しややこしいところです。
SQLiteのWALファイルは、書き込み内容をいったん受け止める作業用ファイルのようなものです。一定のタイミングで、その内容がメインの logs_2.sqlite に反映されることがあります。この処理はチェックポイントと呼ばれます。
つまり、WALファイル自体の見た目のサイズが小さくても、裏側で書き込みと反映が何度も繰り返されていれば、SSDへの累計書き込み量はもっと大きくなる可能性があります。ここは、最初に私も勘違いしそうになりました。
logs_2.sqlite-wal のサイズ確認で分かるのは、主に「WALファイルが数GB、数十GBに肥大化していないか」です。SSDへの累計書き込み量そのものは、WALファイルのサイズだけでは分かりません。
だからこそ、次にアクティビティモニタも見ることにしました。
アクティビティモニタで書き込み量の増え方を見た
Macのアクティビティモニタを開き、Codex関連のプロセスを検索しました。
表示項目から「書き込みバイト数」と「読み込みバイト数」を追加すると、Codex関連プロセスごとの読み書き量が見られました。
私の環境では、起動後に次の大きな数字が見えました。
Codex 書き込み 488.0 MB
codex 書き込み 256.6 MB
正直、ここでも少し驚きました。Codexアプリを終了して、また開いたばかりだったからです。起動しただけで、もう数百MB単位の書き込みが表示されていました。
アクティビティモニタの「書き込みバイト数」は、瞬間的な速度ではなく、プロセスが動いている間に積み上がる数字として見た方がよさそうです。Codexを起動すると、セッションの復元、設定の読み書き、ログDBの準備、キャッシュ確認などが走るはずです。起動直後にある程度の読み書きが発生すること自体は、それだけで異常とは言い切れません。
見るべきなのは、1回表示された数字そのものよりも、その後の増え方です。
私はCodexを開いたまましばらく放置してみました。少なくとも私の環境では、何もしていないのに短時間でGB単位へ増えていくような動きは確認できませんでした。
アクティビティモニタの値も、SSD寿命の総書き込み量を直接測るものではありません。あくまで「Codex関連プロセスがどれくらい書き込みをしていそうか」を見るための目安です。それでも、ログファイルのサイズだけを見るよりは、かなり安心材料になりました。
追記
ただし、Codexを実際に30分くらい動かすと、書き込みバイト数は数GB単位で増えることがありました。これはセッション保存やログ、キャッシュなどの処理も含まれるため、増えること自体がすぐ異常というわけではありません。見るべきなのは、作業していない状態でも増え続けるか、短時間で異常なペースで増えるかです。
.codex 全体1.9GBの中身も確認した
次に、.codex フォルダの中で何が容量を使っているのかも見てみました。
使ったコマンドはこちらです。
du -sh ~/.codex/* | sort -h
大きかったものは、だいたい次の通りです。
986M sessions
314M plugins
183M logs_2.sqlite
88M sqlite
53M computer-use
6.0M logs_2.sqlite-wal
一番大きかったのは sessions でした。名前から考えると、Codexで開いたスレッドや作業履歴のようなものだと思います。
つまり、私の環境で .codex が1.9GBある主な理由は、ログファイルの暴走というより、セッション履歴や関連データが積み上がっているからに見えました。
容量を空けたいだけなら整理する選択肢もあります。ただ今回の目的は、SSDに異常な書き込みが続いていないかを確認することです。その観点では、すぐに .codex を消す必要はなさそうだと判断しました。
今回は削除しないことにした
.codex フォルダを丸ごと消せば、容量は空くかもしれません。その代わり、Codexの履歴、設定、セッション情報なども消える可能性があります。
特に、Codexが起動している状態で logs_2.sqlite-wal だけを手動で消すのは避けた方がよさそうです。SQLiteが使う作業中のファイルなので、ログDBや履歴まわりがおかしくなる可能性があります。
私の環境では、logs_2.sqlite-wal は数MB程度でした。.codex の大部分は sessions でした。アクティビティモニタでも、何もしていないのに書き込みバイト数が異常に増え続ける様子はありませんでした。
この状態なら、削除よりも様子見でよさそうです。もし本当に削除や初期化をするなら、少なくともCodexを完全に終了してから、何が消えるのかを確認した上でやった方がいいと思います。
Codexアプリは最新版だった
私が確認した時点で、Codexアプリのバージョンは次の通りでした。
Version 26.616.81150
Released Jun 24, 2026
これは、About Codexの画面で確認したものです。
OpenAIのCodex changelogを見ると、永続ログへの書き込みを減らす修正が入った旨の記載がありました。具体的には、WebSocket payloadのイベントごとのログ保存を減らしたり、重複テレメトリをフィルタしたりする修正です。
古いバージョンを使っている場合は、まず最新版にアップデートした方がよさそうです。私の環境で大きな問題が見えなかった理由のひとつとして、最新版を使っていたことも関係しているのかもしれません。
もちろん、これだけで原因を断定することはできません。使い方、起動時間、バージョン、環境によって結果は変わるはずです。あくまで今回は、「私のMacでは、確認した範囲で異常な大量書き込みは見えなかった」という話です。
非エンジニアが確認するなら、この2つを見るとよさそう
今回やってみて、非エンジニアでも最低限この2つを見れば、ある程度は判断できると思いました。
まずは、ターミナルでログファイルのサイズを見ます。
ls -lh ~/.codex/logs_2.sqlite*
du -sh ~/.codex
logs_2.sqlite-wal が数GB、数十GBになっていたら、かなり気にした方がよさそうです。WALファイルが小さいからといってSSDへの累計書き込み量まで少ないとは限りませんが、少なくとも「ファイルが目に見えて肥大化していないか」は確認できます。
次に、アクティビティモニタでCodex関連プロセスの「書き込みバイト数」を見ます。
ポイントは、1回見て終わりにしないことです。起動直後の数字をメモして、5〜10分ほど何もせずに置いてから、もう一度見ます。何もしていないのに短時間でGB単位に増え続けるなら、少し怪しいです。起動直後に数百MB程度の書き込みがあっても、その後ほとんど増えないなら、少なくとも「今この瞬間に暴走している」状態ではなさそうです。
リアルタイムでログサイズを見る方法
ログファイルが増えているかをリアルタイムで見たい場合は、次のコマンドも使いました。
while true; do
clear
echo "---- Codexログ監視中：止めるときは Control + C ----"
date
echo ""
ls -lh ~/.codex/logs_2.sqlite*
echo ""
du -sh ~/.codex
sleep 10
done
10秒ごとに、Codexのログファイルと .codex 全体のサイズを表示するだけのコマンドです。止めるときは Control + C です。
分かるのはあくまでファイルサイズの変化であって、SSDへの累計書き込み量そのものではありません。ログサイズの確認とアクティビティモニタの確認は、セットで見た方がよさそうです。
まとめ
今回いちばん大事だったのは、「怖い投稿を見たあとに、すぐ削除しないこと」でした。
Codexのログ書き込み問題そのものは軽視できません。MacのSSDは気軽に交換できませんし、ローカルで動くAIアプリが裏で何をしているのかは、ある程度気にした方がいいです。一方で、怖い話を見て、いきなり .codex フォルダを丸ごと消すのも違うと思いました。
今回は、ログファイルのサイズを見て、.codex の中身を見て、アクティビティモニタで書き込み量の増え方も見ました。その結果、少なくとも自分の環境では、今すぐ削除が必要な状態には見えませんでした。
Codexは便利です。便利だからこそ、全部おまかせにしすぎない方がいいのかもしれません。ローカルで動くAIツールを使うなら、自分のMacの中で何が起きているのかを、ときどき数字で見ておく。非エンジニアの私には、そのくらいの距離感がちょうどよさそうです。
コメント