最近，许多开发者反映，OpenAI Codex 在命令行和桌面端使用时存在一个严重问题。它会不断向用户主目录下的 ~/.codex/logs_2.sqlite 文件写入日志，导致固态硬盘写入量急剧增加，影响硬盘寿命。有用户反馈，仅一两个月内写入数据已达几十甚至上百 TB，远超普通应用的写入负载，硬盘在两三年内可能出现损坏或报废。在一些依赖 Codex 的开发环境中，这个问题更为明显，硬盘可能提前退役。
如果你正在使用 Codex，建议先保存本文。后续会提供排查思路、临时解决方案和监控方法，帮助避免类似问题。即使现在没有遇到写入过度，也可以为团队的硬盘健康增加保障。这个写入“杀手”会对硬件造成实际损害，必须引起重视。
Codex 经常向 SQLite 日志库写入大量零散的小文件碎片，导致 SSD 长时间处于高强度写入状态，这种负荷远超正常业务水平。这不是偶发状况，而是一种长期存在的、类似“写入炸弹”的持续现象。
关键在于：如果日志写入量每年达到数百 TB，典型的消费级 SSD（如采用 TLC 或 QLC 存储技术的）寿命会因大量写入骤降。
Codex 执行的日志写入机制存在缺陷，使写入数据量被极大放大且持续增长。SSD 寿命依赖写入总量，因而存在硬盘寿命被“透支”的风险。
社区反馈中最常见的情况包括：Codex 进程所在目录下的 logs_2.sqlite 文件容量迅速增长，达到几十 GB；日志写入频率极高，累计写入量超过正常软件负载十倍以上；系统出现卡顿甚至崩溃，特别是在多个进程并发调用时更明显；使用 CrystalDiskInfo 或 smartctl 监测时，写入量异常升高；关闭 Codex 或禁用日志写入功能后，写入量明显下降，硬盘温度和负载也恢复正常。
部分用户测量到一年写入总量超过 600 TB，相当于普通 1T SSD 的质保写入上限 600 TBW 有可能被一年内耗尽。
“写入炸弹”不是突然发生的，而是持续累积，最终导致 SSD 健康度无法恢复地下降。
大多数普通消费者用的SSD会选用TLC或QLC存储芯片，每个存储单元的擦写次数有限，通常在1000到3000次左右。SSD的寿命主要通过“写入总量”来衡量，厂商用TBW（总写入字节数）作为质保标准。
实际使用时，频繁进行小块写入，像SQLite将小事务写入日志，会造成写入放大，即SSD写入的数据量远超用户看到的数据。这有点像在同一页纸反复擦写，使纸张渐渐变薄。
时间久了，即使SSD没出现物理损坏，性能也会明显下降，有时甚至无法被系统识别，坏块增多。相比机械硬盘，SSD有使用寿命限制，而Codex带来的频繁写入则加速了SSD的损耗。
有人认为“SSD寿命不重要，坏了换就行”，但在企业和开发者环境中，这存在很大风险。一旦SSD损坏，数据恢复难度大幅增加，可能导致项目停滞或数据丢失。
许多场景用关系型数据库存储trace log，但全部依赖数据库写日志负担很重，写入放大效应也明显，因此不算理想方案。
依靠系统监控记录写入动作，对应对瞬时写入峰值帮助有限。监控只能感知写入后的结果，无法提前干预来防止突发问题，结果导致问题反复出现却难以及时发现。
固态硬盘寿命不像机械硬盘那样容易判断，寿命曲线很不规则，可能在正常运行时突然故障，增加了运维判断的难度。
针对 Codex 写入过载的问题，有几种实用且能立即投入使用的应对措施：
在 logs_2.sqlite 的日志表上添加 BEFORE INSERT 触发器，拒绝新增日志插入，以减少写入次数。该触发器语句可用 sqlite3 命令行或 Python 脚本执行，阻止应用端写入该表。
将日志目录迁移到内存盘（ramdisk），虽然断电会丢失日志，但能显著降低对 SSD 的写入压力。
设置环境变量 RUST_LOG=info，关闭 TRACE 等高频调试日志，减少写入频率。
定期用脚本检查日志大小，超过限制时自动清理或归档。
这些方法可能会带来日志丢失或运维复杂等副作用，实际应用时应根据具体环境和风险承受能力选用。
若开发或生产环境对日志完整性有严格要求，不应直接阻断日志写入。
对于写入负载低的旧机械硬盘或企业级固态硬盘，可根据实际情况灵活调整策略。
不建议用数据库存储大量高频的 trace 日志，尤其是非专门设计为日志收集的数据库。
禁止日志写入会增加运维排障难度，适合临时调试，不宜作为关键业务机房的长期配置。
实际操作中，应先评估日志的重要性，再选择合适方案，不可将临时应急方法当作根本解决。
如果怀疑 Codex 导致 SSD 损耗，可以按以下流程排查：
监测写入量
使用 CrystalDiskInfo、smartctl、HWInfo 等工具，持续查看 SSD 累计写入量和健康状态。
识别高写入文件
检查应用目录中的大文件，重点关注 ~/.codex/logs_2.sqlite 和临时日志文件。
开启 debug 或 trace 级别日志监测
观察写入高峰，判断是否与日志写入相关。
应用临时日志拦截
利用之前提到的触发器等方法，确认写入源头是否为 Codex 生成的日志，观察写入量是否明显下降。
长期监控与报警
结合硬盘健康指标，设定写入阈值报警，提前发现硬盘寿命风险。
这套清单适合写入异常时使用，能快速定位问题，避免盲目更换硬件或误判原因。
线上环境遇到类似情况时，按这个步骤排查可以节省很多时间。
Codex 频繁写入 SQLite 日志，导致 SSD 寿命缩短，这是实际应用中存在的问题。解决前，需要了解写入放大现象和存储介质的限制。
屏蔽日志写入触发器、迁移内存盘、调整日志等级，都是短期内较有效的缓解措施。但长远看，日志机制需要官方优化，同时合理设计日志存储架构。
注意以下几点：
如果想更清楚写入问题和应对方法，可保存参考。团队中负责基础设施或运维的同事也可以转发。遇到复杂问题，欢迎留言交流，促进环境更稳定可靠。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。