Codex响应变慢，真正的原因通常不在于项目体量过大，也不是模型性能不足，而是SQLite在TRACE级别下持续高频写入日志，直接把磁盘I/O占满；常见现象包括WAL文件超过30MB、主键在15秒内快速增加近3000、SSD写入量明显升高。要解决这个问题，通常只需要修改config.toml，将日志级别调低，或者直接关闭WAL模式。

Codex响应太慢并不是因为项目太大，而是本地SQLite日志库在TRACE级别下不断高频写盘，短短15秒内数据库主键ID就能增加近3000，WAL文件体积甚至突破46MB，SSD写入量也被持续拉高——你感受到的“卡顿”，本质上其实是硬盘I/O压力过大。

确认是否是日志写盘导致Codex响应慢

打开终端，执行：ls -lh ~/.codex/logs_2.sqlite*。

如果看到logs_2.sqlite-wal文件大小超过30MB，或者logs_2.sqlite本身增长异常（例如一天内增加200MB以上），基本就可以判断是日志写入机制失控，导致Codex变卡、响应变慢。

这一步非常关键，不能省略——很多用户会误以为是项目代码太多、上下文太大或模型响应变慢，实际上往往只是后台日志持续刷盘，把磁盘I/O通道完全占满。

立即停止TRACE日志写入

方法一：临时关闭日志（推荐先用于快速验证）
编辑~/.codex/config.toml，在[logging]区块下添加或修改：
level = "INFO"
trace_enabled = false

方法二：直接删除当前日志库（适用于已经确认问题且不需要保留历史日志）
rm ~/.codex/logs_2.sqlite*
【注意：此操作不可逆，删除后所有本地日志记录都会丢失】

删除完成后重启Codex Desktop，观察右下角状态栏是否不再持续闪烁“writing log”提示。

永久禁用WAL模式，避免日志写入放大

第一步：进入SQLite日志库所在目录
cd ~/.codex

第二步：使用命令行SQLite工具执行PRAGMA设置
sqlite3 logs_2.sqlite "PRAGMA journal_mode = DELETE;"

第三步：检查是否已经生效
sqlite3 logs_2.sqlite "PRAGMA journal_mode;"
返回结果必须是delete，而不是wal。如果仍然显示wal，说明配置没有生效，或者文件被其他进程占用，此时需要先结束所有Codex进程后再重试。

WAL模式会让日志写入产生更明显的双重I/O负担，关闭后写入量通常可下降70%以上，尤其对NVMe SSD的性能和寿命保护更明显。