Codex日志狂写SSD：5M/s烧盘大Bug与止血方法
Codex日志狂写SSD，问题到底有多严重
最近不少用户发现，Codex在流式传输和自动化任务场景下，会持续向磁盘写入日志，而且速度非常夸张。外界反馈显示，写入量可能达到5M/s级别，长期累积下来，对消费级SSD非常不友好。
更麻烦的是，这个问题不是单一版本才有，CLI、桌面App、VSCode插件都可能受影响。也就是说，只要相关功能频繁运行，硬盘就可能在不知不觉中被大量消耗。
为什么看起来“文件不大”，实际却很伤盘
很多人第一眼看到日志文件，觉得体积没涨多少，就会误以为问题不大。其实真正影响SSD寿命的不是你看到的文件大小，而是底层真实写入量，也就是TBW。
这类日志写入常见两个特点：
- 大量TRACE级别内容被写进
~/.codex/logs_2.sqlite。 - SQLite在频繁插入和删除时，会让WAL持续刷盘，真实写入量远高于表面文件大小。
有网友反馈，机器连续运行21天后，主盘TBW增加了37TB。按这个速度外推，一年可能接近640TB，足以把一块1TB消费级SSD的官方写入寿命逼近极限。对重度用户来说，风险不算小。
如何快速判断自己有没有中招 🔍
先看日志文件是否异常增长，再检查日志级别分布。Linux和Mac用户可以直接执行：
ls -lh ~/.codex/logs_2.sqlite
sqlite3 ~/.codex/logs_2.sqlite "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"如果发现TRACE占比很高，而且文件持续变大，基本就能确认问题存在。尤其是Codex使用越频繁、会话越多，写盘速度通常越明显。
再进一步观察系统层面的写入量变化，也能验证是否存在异常。若你发现电脑越用越卡、切换会话有延迟、工具响应变慢，就要优先怀疑磁盘写入压力，而不是单纯性能不足。
3种止血办法，先保护SSD再说
如果暂时等不到官方修复，建议先做止血处理。下面这三种方法，从强到弱都能用。
1. 直接阻止日志写入
这是最直接的方法，适合愿意动命令行的用户。因为这个文件记录的是诊断日志，不是对话历史，所以直接屏蔽写入通常不会影响核心使用。
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"这个做法的好处是立刻生效，坏处是会让日志功能基本失效。如果你当前更在意硬盘健康，它是最省事的方案。
2. 把日志文件放到内存盘
如果你不想硬切日志写入，可以把文件软链到tmpfs，让它在内存里折腾，不去磨SSD。重启后内容自动清空，适合临时过渡。
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
ln -s /tmp/logs_2.sqlite ~/.codex/logs_2.sqlite这个方法的思路很简单：能写，但不写到固态硬盘上。对于暂时还想保留程序运行行为的人来说，算是比较温和的处理方式。
3. 挪到机械硬盘
如果机器里还有第二块机械盘，把这个日志文件移过去也是可行的。机械盘更适合承受持续写入，至少不会像SSD那样担心寿命被快速消耗。
这种方案适合不想折腾太多配置、但又希望保留日志功能的用户。缺点是读写速度会慢一些，但对诊断日志来说通常问题不大。
为什么大家都在吐槽
这次争议大，主要是因为它写进去的很多内容并不“有用”。比如内部状态、系统细节、TRACE信息，用户既看不到，也很少直接用得上，但却要承担真实的写入成本。
相比之下，很多人更能接受大文件来自真正有价值的工作内容，比如模型运行时的临时数据或虚拟机镜像。可如果只是内部噪音，却长期高速刷盘，用户自然会觉得不划算。
给普通用户的建议
如果你近期正在高频使用Codex，建议马上做三件事：
- 检查
~/.codex/logs_2.sqlite是否异常增长。 - 确认SSD写入量是否明显上升。
- 优先选择止血方案，别等硬盘已经被大量消耗再处理。
对于消费级SSD来说，持续高写入比很多人想象中更危险。尤其是QLC或容量较小的盘，寿命余量本来就不宽裕，遇到这种日志狂写问题更要早处理。
先确认：是真写盘，还是读数看错了
排查的第一步，不是急着删日志，而是先确认 SMART 或 TBW 的口径有没有理解错误。很多盘的“写入量”并不完全等于系统层看到的写入，还可能包含写放大。
需要重点确认三件事：
- 读到的是 Host Writes 还是 NAND Writes
- 单位是不是 512,000 bytes、32MiB 或 GiB
- 是否存在厂商属性换算误差
macOS 上可以先试这些命令：
brew install smartmontools iotop
diskutil list
sudo smartctl -a /dev/disk0
ioreg -r -c AppleANS2NVMeController | grep -i written如果只是想快速看内置盘写入量，后面这条通常也很有参考价值。
mac 上怎么安装排查工具
如果是 mac 用户，优先装两个工具就够开始排查了：smartmontools 和 iotop。安装方式很简单：
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install smartmontools iotop装好后，建议按这个顺序看：
- 先看 SMART，确认累计写入有没有异常增长
- 再看实时 I/O，确认是谁在持续写盘
- 最后再追目录和文件，找到具体来源
如果 iotop 不方便使用，可以直接用系统自带工具辅助判断。
实时抓写盘进程，找出“元凶”
如果怀疑某个程序一直在写盘，最有效的方式是盯实时 I/O。这样能直接看到哪个进程在持续输出数据。
Linux 常用命令如下：
sudo iotop -aoP
pidstat -d 5
iostat -dx 5这些命令分别适合看进程级写入、按时间采样的磁盘吞吐、以及块设备整体压力。若平均写入长期维持在几十 MB/s，就说明问题不是偶发，而是持续发生。
macOS 可以试：
- fs_usage：查看文件系统级别的访问
- 活动监视器：在“磁盘”页按写入字节数排序
- powermetrics：辅助看任务活动
sudo fs_usage -w -f filesys
sudo powermetrics --samplers tasks -i 5000如果 Codex 或相关自动化工具运行时写盘突然上升，基本就能在这里抓到。
再查目录：是日志、缓存，还是数据库
进程定位后，还要看具体写到了哪里。很多高 TBW 问题，最终都落在下面几类目录里。
- 日志目录：/var/log、应用 debug 日志、Electron/Chrome 日志
- 缓存目录：~/.cache、~/Library/Caches、AppData/Local/*/Cache
- 容器目录：Docker 容器日志、overlay2
- 数据库目录：WAL、binlog、redo log、AOF
- 临时目录：/tmp、/var/tmp
结语
Codex这个日志写盘问题，本质上不是“卡一下”的小毛病，而是实打实的硬盘寿命风险。最稳妥的做法，是先排查、再止血、最后等待官方修复。
如果你已经发现自己的盘在异常燃烧，别犹豫，先把日志写入控制住。SSD坏了可以换，数据和时间可没那么容易补回来。
创建: 2026-06-22 更新: 2026-06-24
消息提醒
定海神经