
AIコーディングCLIツールがSSDを壊す? Codex・Claude Code・Claude Desktopのディスク書き込み問題を調査してみた
はじめに
2026年6月、OpenAIのCodex CLIが年間640TBもの書き込みをSSDに行い、ドライブの寿命を1年未満で使い切る可能性があるというバグが報告され、話題になりました。
AIコーディングCLIツールを日常的に使っている開発者として、これは他人事ではありません。本記事では、Codex CLIの問題の詳細を整理した上で、自分の環境でClaude CodeとClaude Desktopに同様の問題が起きていないか実際に調査した結果を共有します。
Codex CLIのSSD書き込みバグ
何が起きているのか
GitHub Issue #28224で報告された内容をまとめると:
- Codex CLIが
~/.codex/logs_2.sqliteにTRACEレベルのログを永続的に書き込み続ける - 21日間で約37TBの書き込みが発生(年間換算で約640TB)
RUST_LOG=warnを設定しても、SQLiteシンクはTRACEレベルで書き込み続ける(環境変数を無視する)- SQLiteのWAL(Write-Ahead Logging)モードにより、書き込み増幅(Write Amplification)が発生
なぜ深刻なのか
一般的な1TBコンシューマ向けSSDには、メーカーが保証する書き込み総量の上限値「TBW(Terabytes Written)」が設定されています。Samsung 990 PRO 1TBの場合、TBWは約600TBです。この1つのバグだけで、SSDの保証寿命を1年未満で消費してしまう計算になります。
2026年6月23日時点で、3つのPRがマージされ約85%のログ削減が見込まれていますが、完全な修正にはまだ至っていません。
ワークアラウンド
macOS/Linuxユーザーは、シンボリックリンクでログファイルをRAMディスクにリダイレクトできます:
ln -sf /tmp/codex_logs.sqlite ~/.codex/logs_2.sqlite
このファイルに会話データは含まれないため、再起動時に失われても問題ありません。
他のAIコーディングツールの状況
Codex CLI以外のツールで同様の問題が報告されているか調査しました。
| ツール | SSD書き込み問題 | 備考 |
|---|---|---|
| Codex CLI | 深刻(640TB/年) | TRACEレベルSQLiteロギング |
| Claude Code | 過去に報告あり | デバッグログ無限ループ、ファイル履歴肥大化 |
| Claude Desktop | 過去に報告あり | 1時間で8-13GBの書き込み |
| Gemini CLI | 報告なし | - |
| Aider | 報告なし | - |
| Cursor | 報告なし | - |
| GitHub Copilot | 報告なし | - |
Claude Codeの過去の問題
Claude Codeでは2つの関連する問題が報告されています:
-
デバッグログ無限ループ (#16093):ロガーが75ms以上かかる操作をログに記録するが、デバッグログファイルが大きくなると書き込み自体が75ms以上かかるようになり、「ログの書き込みが遅い」というログを書き込む無限ループが発生。7日間で
.claude/debug/が42GBに膨張した事例がある -
ファイル履歴によるディスク枯渇 (#10107):ファイル履歴の追跡で300GBのディスク使用量が発生した事例がある
Claude Desktopの問題
Claude Desktopでも別の問題が報告されています(#43390):
- 1時間で8-13GBのディスク書き込み
- macOSがシステムディスク書き込み制限(閾値:86400秒間で約99KB/s)を超過としてフラグ
- 実際の書き込みレートは2,000-5,000KB/s(閾値の20-50倍)
自分の環境を調査してみた
実際に自分のmacOS環境で、Claude CodeとClaude Desktopの状態を確認しました。
Claude Codeの調査
デバッグログディレクトリ
$ du -sh ~/.claude/debug
2.8M /Users/username/.claude/debug
$ wc -l ~/.claude/debug/* | tail -1
18431 total
2.8MB、合計約18,000行。114個のデバッグファイルがあり、最大のものでも207KB。無限ループバグ(#16093)で報告された42GB / 5億行超とは桁が全く違います。
ファイル履歴
$ du -sh ~/.claude/file-history
12M /Users/username/.claude/file-history
12MB。ファイル履歴枯渇バグ(#10107)の300GBとは比較にならない正常な値です。
.claude/ 全体の内訳
$ du -sh ~/.claude/*/ | sort -hr | head -10
866M plugins/
434M projects/
266M security/
12M file-history/
2.8M debug/
532K telemetry/
合計1.5GB。pluginsとprojectsが大部分を占めますが、いずれも正常な範囲です。
Claude Desktopの調査
Application Supportディレクトリの全体像
$ du -sh ~/Library/Application\ Support/Claude/
9.2G
9.2GBと一見大きく見えますが、内訳を確認します:
6.2G vm_bundles/
1.1G local-agent-mode-sessions/
1.1G Cache/
240M Code Cache/
225M claude-code-vm/
206M claude-code/
175M Claude Extensions/
10M pending-uploads/
vm_bundles/ の正体(6.2GB)
最も大きい vm_bundles/ の中身を確認しました:
$ ls -lh ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/
-rw------- rootfs.img 10G (apparent) → 5.6G (actual)
-rw-r--r-- sessiondata.img 749M (apparent) → 634M (actual)
rootfs.img はスパースファイルで、表示上10GBですが実ディスク使用量は5.6GBです。これはClaude Desktopのエージェントモードで使われるLinux VMのルートファイルシステムで、サンドボックス内でコード実行するために必要なものです。
バージョンごとに新しいバンドルが蓄積されるのではなく、1つのバンドルのみ存在していたので、バージョン肥大化の問題はありませんでした。
エージェントモードセッション(1.1GB)
$ ls ~/Library/Application\ Support/Claude/local-agent-mode-sessions/
26e16885-.../
├── 45517894-... 89M
└── 5c883d62-... 984M (1,120 conversations)
3月から6月までの約3ヶ月分の会話履歴データ。バグではなく、通常の蓄積です。不要であれば削除して容量を回復できます。
macOSのディスク書き込み警告
$ log show --predicate 'process == "dasd" AND eventMessage CONTAINS "Claude"' --last 7d
(出力なし)
macOSからの過剰ディスク書き込み警告は検出されませんでした。
調査結果
| チェック項目 | 結果 | 判定 |
|---|---|---|
| Claude Code デバッグログ | 2.8 MB | 正常 |
| Claude Code ファイル履歴 | 12 MB | 正常 |
| Claude Desktop ログ | 52 MB | 正常 |
| Claude Desktop VMバンドル | 6.2 GB(VM本体) | 正常(基本コスト) |
| Claude Desktop セッション | 1.1 GB | 正常(蓄積、削除可能) |
| macOS ディスク書き込み警告 | なし | 正常 |
今回の調査では、既知のバグの影響は受けていませんでした。
定期的な監視のすすめ
現時点で問題がなくても、今後のアップデートで状況が変わる可能性があります。以下のコマンドで定期的にチェックすることをおすすめします:
# Claude Codeのデバッグログとファイル履歴のサイズ確認
du -sh ~/.claude/debug ~/.claude/file-history
# Claude Desktopの全体サイズ確認
du -sh ~/Library/Application\ Support/Claude/
# macOSのディスク書き込み監視(リアルタイム)
sudo fs_usage -w -f diskio | grep -i "claude"
異常な増加が見られた場合は、各ツールのGitHub Issueを確認してみてください。
まとめ
- OpenAI Codex CLIの640TB/年ディスク書き込みバグは実際に深刻な問題
- Claude CodeとClaude Desktopにも過去に類似の問題が報告されているが、現在のバージョンでは修正されている模様
- 自分の環境では既知のバグの影響は検出されなかった
- IDE系ツール(Cursor、Copilot)や軽量CLI(Aider、Gemini CLI)では同様の報告は見つからなかった
- ローカルでTRACEレベルのSQLiteロギングを行うツールは特にリスクが高い傾向にある
- 定期的なディスク使用量の監視が予防的な対策として有効
AIコーディングツールは便利ですが、バックグラウンドで何をしているか把握しておくことも大切です。特にSSDの寿命に関わる問題は、気づいた時にはすでに手遅れになっている可能性があるため、予防的な監視を心がけましょう。





