短答案：修复了一部分，但不能简单说“彻底修好了”。 目前公开信息显示，Codex 的“狂写日志导致 SSD 写入异常”的问题确实存在过，主要是本地日志（尤其 ~/.codex/logs_2.sqlite / WAL）过度写入。后续有修复和缓解，但仍有人报告类似 I/O 问题。GitHub

具体情况：

  • 早期问题：
    • Codex 的日志系统会产生大量 TRACE 级别日志。
    • 某些情况下 SQLite 日志库持续写入，导致 logs_2.sqlite-wal 快速增长。
    • 有用户报告出现 GB/s 级别累计写入、几十 TB SSD 写入量。GitHub
  • 后续状态：
    • 一些相关问题被关闭/修复或降低影响，但 GitHub 上仍有新的性能和写盘相关 issue，例如 macOS Desktop 持续写盘、长会话导致日志膨胀等。GitHub
    • 所以更准确的说法是：核心的严重日志风暴问题已经处理过，但 Codex 的本地状态、日志、长会话仍可能产生异常 I/O。GitHub

如果你现在用的是 macOS，我建议先检查你的机器有没有被影响：

1. 看 Codex 日志大小

1
du -sh ~/.codex/*

重点看：

1
2
3
~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/sessions

如果看到：

  • 几百 MB：正常
  • 1～2 GB：偏大
  • 5GB+：明显异常

2. 看 SSD 已经写了多少

Apple Silicon：

1
sudo smartctl -a /dev/disk0 | grep -E "Data Units Written|Percentage Used"

重点：

1
2
Data Units Written
Percentage Used

如果没有 smartctl：

1
brew install smartmontools

然后：

1
sudo smartctl -x /dev/disk0

重点看：

1
2
Data Units Written
Percentage Used

例如：

1
2
Data Units Written: 12,345,678
Percentage Used: 3%

说明：

  • SSD 已写约 1.2PB（不同厂商换算略有差异）
  • 寿命消耗约 3%

3. 看 Codex 是否还在疯狂写

打开：

1
活动监视器 → 磁盘 → 数据写入

或者终端：

1
sudo fs_usage -w -f filesystem | grep codex

如果空闲状态下仍持续出现大量：

1
2
3
4
write
pwrite
sqlite
logs_2.sqlite

说明还有问题。

4. 如果你担心 SSD，暂时可以做：

关闭 Codex 后：

1
pkill codex

检查：

1
ls -lh ~/.codex/logs_2.sqlite*

如果很大，可以备份后清理：

1
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.backup

下次启动 Codex 会重新创建。

如果你告诉我：

  1. 你的 Codex 版本（Codex → About 或 codex --version）
  2. macOS 版本
  3. du -sh ~/.codex/* 输出
  4. SSD 的 Data Units Written

我可以帮你判断你的 SSD 是否已经被这个 bug 明显消耗寿命。