#技术教程 [附临时解决方案] Codex 桌面版、CLI 版被发现持续写入低级别日志，这可能会导致固态硬盘寿命大幅下降。有开发者称 Codex 因某种故障会忽略进程环境变量的日志级别设置，导致 21 天写入 37TB 数据，这会严重缩短固态硬盘寿命。目前临时解决方案是阻止新日志插入，等待官方修复。查看全文：https://ourl.co/113555

近期有开发者反馈 Codex 应用可能因为某些异常导致频繁写入 TRACE 级别的日志，这种行为会将日志持久化到本地数据库中然后再进行删除，对用户而言造成的直接影响就是固态硬盘被频繁读写，进而降低固态硬盘寿命。有开发者称自己在 21 天内固态硬盘写入量约为 37TB，平均每天 1.76TB，按这种情况持续下去的话每年写入将达到 643TB，而固态硬盘本身是有写入寿命限制的。

什么是固态硬盘 TBW：

消费级固态硬盘 (其实企业级固态硬盘同样有) 有 TBW 写入量总计，原因是 NAND 闪存芯片都有固有的编程 / 擦除周期，闪存芯片反复写入就会逐渐磨损，而固态硬盘制造商会通过磨损均衡、垃圾回收、纠错码、超量预留等技术来延长固态硬盘的写入寿命。

常见的 1TB 消费级固态硬盘通常官方标准是 600TBW，制造商提供 5 年有限保修，当固态硬盘购买超过 5 年或者 TBW 达到限额则会触发过保 (以先到者为准)。对大多数普通用户而言基本不需要关注写入寿命，因为 600TBW 按照每天写入 100GB 来算，大约需要 16 年才能达到标准。

但如果像开发者反馈的这种情况，同样假设是 1TB 的固态硬盘且含有 600TBW，如果每天写入 1.76TB 则只需要 11 个月就会达到 TBW 限额。触发限额后固态硬盘可能还可以继续使用，但如果出现问题将无法获得官方售后服务，而且部分固态硬盘会在固件里设置限制，触发 TBW 限额后可能进入只读模式或限制读写性能。

Codex 的问题出现在哪：

Codex 在启动后会持续向用户目录下的 SQLite 日志数据库写入数据，相关文件包括：`~/.codex/logs_2.sqlite`、`~/.codex/logs_2.sqlite-wal`、`~/.codex/logs_2.sqlite-shm`。这种情况并非偶尔，在部分用户环境中，正常对话、流式响应甚至后台运行时都可能触发持续写入。

根据 Codex Issue #17320 错误报告，用户在 Linux 环境下观察到 Codex 的 `app-server` 在模型流式输出期间持续向 `logs_2.sqlite-wal` 写入，速率约为 `5 MiB/s`，峰值速度可达 `16 MiB/s`。而且即便进程环境变量已经设置 `RUST_LOG=warn`，数据库日志写入似乎也没有遵循这种日志过滤级别，仍然将大量 TRACE 级别日志持久化到本地数据库中。

从反馈情况来看，这更像是 Codex 诊断日志的持久化策略过于激进，低价值或高频内部日志占比很高，也就是 Codex 可能将本应该短暂用于调试的内部事件当成长期日志写入数据库。在频繁使用 Codex 的情况下，这会给用户的固态硬盘带来寿命压力。

影响哪些版本：

• Codex Desktop for macOS
• Codex CLI for Linux
• Codex CLI for macOS (大概率受同类问题影响，但目前公开样本较少)
• 目前尚未看到关于 Codex Desktop for Windows 是否受影响的报告

如何检查自己是否受影响：

# 用户可以在终端中执行如下命令查看数据库文件大小
ls -lh ~/.codex/logs_2.sqlite*

# 也可以在启动 Codex 并进行正常任务时运行命令，观察数据库文件是否持续大幅增加
for i in 1 2 3 4 5; do
date
stat ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm
sleep 10
done

# 还可以检查日志级别分布，如果 TRACE / DEBUG 数量异常高则与反馈情况相同
sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC;"

如何临时解决这个问题：

在 Codex 官方尚未确认问题或彻底修复这个问题前，开发者可以使用命令阻止新日志的插入。这种方案的优点是简单、可逆、对固态硬盘友好，缺点则是禁用 Codex 本地持久诊断日志后，后续关于 Codex 本身问题的排查可用信息会少一些，但这对大部分用户来说应该不是问题。

# 完全退出 Codex 后执行如下命令阻止新日志的插入
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

# 验证是否生效
sqlite3 ~/.codex/logs_2.sqlite "SELECT name, tbl_name, sql FROM sqlite_master WHERE type='trigger';"

# 如果命令执行结果看到 block_log_inserts 则代表成功添加
# 如果需要恢复日志写入则执行如下命令
sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;"

清理现有数据库文件：

阻止日志插入后并不会自动缩减现有的日志库，如果要回收空间则需要在完全退出 Codex 后执行如下命令进行清理。清理后整个数据库应该会被缩小很多，后续持续使用 Codex 也不会因为低级别日志持续写入导致数据库继续膨胀，这对于固态硬盘较小的机器来说也是件好事。

cp ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
sqlite3 ~/.codex/logs_2.sqlite "DELETE FROM logs;"
sqlite3 ~/.codex/logs_2.sqlite "VACUUM;"

via Codex Issue #17320、#28224

活动推荐终于补货！99元/年境外CN2服务器又可以购买，限量销售，售完即止。另有3年超低价国内VPS服务器。