近日，一名 Codex 用户在 GitHub 上提交了编号为 #28224 的 issue，详细记录了一个令人担忧的发现：OpenAI Codex 在后台会持续、高频地向本地的 SQLite 反馈日志数据库写入数据，写入强度远超正常使用范畴，已构成对 SSD 硬件寿命的实质性威胁。
21 天写入 37 TB，折算全年达 640 TB
该用户在自己的机器上发现，Codex 会在 ~/.codex/ 目录下持续写入三个 SQLite 相关文件：logs_2.sqlite、logs_2.sqlite-wal 以及 logs_2.sqlite-shm。通过系统级磁盘写入监控，他确认这些文件是机器上最主要的持续写入来源。
在连续运行约 21 天 后，该用户主 SSD 的累计写入量已达 37 TB。按此速度折算，全年写入量将超过 640 TB。对于一块标称耐久度约 600 TBW（Total Bytes Written）的主流 1 TB 消费级 SSD 而言，这意味着在不到一年的时间内，硬盘的全部保修写入寿命将被 Codex 单独消耗完毕。
日志数据库不大，但写入极其密集
更令人惊讶的是，数据库文件本身的体积并不算异常——当前保留约 68 万行日志，估算内容约 1 GB。问题的真正所在，是背后剧烈的写放大（write amplification）现象。
该用户在 15 秒的观测窗口内对比数据库状态，发现保留行数几乎没有变化，但数据行的 max row id 增加了约 3.6 万。这说明 Codex 在持续执行"写入 → 索引 → 记录 WAL → 再清理"的循环，大量日志行被写入后立即被删除，但对磁盘的物理写入已实际发生，无法撤销。
根本原因：默认启用了全局 TRACE 日志级别
经过分析，该用户指出问题的根源在于 Codex 的 SQLite 反馈日志默认以全局 TRACE 级别运行。TRACE 是日志系统中最详细、频率最高的级别，通常只在开发调试阶段启用。
从保留日志的内容分布来看，TRACE 级别的日志占据了约 70.7% 的存储字节，其中充斥着大量底层细节，例如 inotify 文件系统事件（ld.so.cache、locale.alias、passwd 等系统文件的频繁打开事件），以及 WebSocket/SSE 连接的每一次底层读写操作。此外，OpenTelemetry 的镜像遥测日志又额外占据了约 25.3%。两者合计已构成约 96% 的磁盘写入负担，而这些内容与普通用户的实际使用反馈几乎毫无关系。
开发者提出改进建议
该用户表示，他并非要求完全关闭反馈日志功能，而是呼吁 OpenAI 对默认日志策略进行合理收紧：将默认持久化范围限制在真正有价值的日志 target，过滤掉 TRACE 级别的底层噪音以及 OTel 镜像事件。按其估算，仅此一项改动便可消除约 96% 的磁盘写入量。他同时建议提供一个 sqlite_logs_enabled = false 的显式配置开关，供有需要的用户彻底禁用该功能。
目前，该 issue 已在 GitHub 社区引发广泛关注。对于长期保持 Codex 在后台运行的开发者而言，在官方修复发布之前，定期检查上述 SQLite 文件的磁盘写入情况或手动禁用相关功能，或许是目前最为稳妥的自保措施。