40
这个用户还没有留下简介。
40
{“version”:1,“blocks”:[{“id”:“public-1”,“type”:“PUBLIC”,“text”:"
Codex 是 OpenAI 推出的一个命令行编程助手。但最近用户发现它在后台疯狂往硬盘里写数据——写入量巨大，远超 SSD 正常承受范围。
一位用户在 2026 年 6 月 14 日报告了这个问题。他发现自己的硬盘一直异常忙碌，一查才知道是 Codex 在不停地写日志文件。这台电脑连续运行了 21 天，Codex 竟然写入了大约 37 TB 的数据。
换算一下，一年下来就是 640 TB。
而普通 1 TB 的消费级 SSD，整个寿命周期的保修写入量通常只有 600 TB 左右。也就是说，照这个速度，一年之内你的 SSD 就可能被"写废"，直接超出厂家承诺的耐用上限。
问题出在 Codex 的日志系统配置上。
- 它的日志级别被设成了 “TRACE”——这是最详细、最"啰嗦"的模式，几乎什么都记，连打开系统文件这类琐事都写进日志。
- 而且，它忽略 RUST_LOG 环境变量，用户想自己调低日志级别都做不到。
- 在这些记录中，大约 71% 都是 TRACE 级别的冗余信息，对普通用户完全没有实际用处。
- 更糟的是"写入放大"
日志不仅一直在变大，数据库还在频繁地增删记录——每分钟好几次万。这让实际写入硬盘的数据量，比日志文件本身要大得多，进一步加速了 SSD 的损耗。
这个问题其实早在 2026 年 4 月就陆续有人反映过了。OpenAI 最近的更新中提到过一些 SQLite 相关的修复，但没有解决写入量过大的核心问题。截至目前，这个 Bug 在 GitHub 上仍处于未解决状态。
临时解决办法
Linux 或 macOS 用户，可以暂时把日志文件 ~/.codex/logs_2.sqlite 通过软链接指向 /tmp/ 目录（这个目录存在内存中）。这样写入操作就会被重定向到内存，而不是硬盘。
注意：这个文件不包含你与 AI 的对话内容，所以即使重启后丢了也没关系。
如果不需要保留日志，也可以直接关闭日志功能或定期清理该文件，作为临时避险手段。
相关 GitHub Issue：
- 链接：https://github.com/openai/codex/issues/28224
- 标题：Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance"}]}
