Codex 持续写入
logs_2.sqlite？
先检查，再决定是否处理
电脑变卡、磁盘一直忙，不等于一定是这个问题。先用四次采样确认，再决定要不要动数据库。
我遇到过 Codex 日志数据库持续写入，使用时间越长，电脑越容易发热、卡顿。OpenAI Codex 仓库里也有用户报告类似现象，可参考 Issue #17320 和 Issue #20213。
这更像是部分 Codex 客户端或 app-server 版本的日志持久化问题，不是 GPT 模型本身的问题，也不是每台电脑都会遇到。正常日志本来就会写入；只有在没有任务时仍连续、快速增长，才值得继续排查。
先看自己有没有这些现象
- Codex 没有明显任务时，磁盘仍持续繁忙。
logs_2.sqlite或对应的-wal文件持续增大。- Codex 使用越久越卡，退出后磁盘活动明显下降。
如果没有这些现象，不用为了“预防”去改数据库。想检查，就新建一个 Codex 对话，把下面整段粘贴到对话框：
先只检查，不修改任何文件。请定位当前 Codex 使用的 logs_2.sqlite 和对应的 -wal 文件：
1. 记录数据库和 WAL 当前大小；
2. 在没有其他 Codex 任务运行时，每隔 10 秒采样一次，共 4 次；
3. 检查 logs 表近期记录是否主要为 TRACE 级别；
4. 报告文件是否持续增长、增长速度和判断依据。
不要创建 trigger，不要 checkpoint，不要删除或截断任何文件。- 大小基本不变：到这里就停，不需要处理。
- 只在任务运行时小幅增长：先更新 Codex，继续观察。
- 空闲时仍快速增长，近期记录又以 TRACE 为主：确认中招后，再考虑下面的临时办法。
确认异常后，先备份再临时拦截
这不是官方修复。它会阻止
logs 表继续保存本地日志，可能减少以后排查问题所需的诊断信息。数据库路径、表结构或备份只要有一项不对，就应停止。
如果检查结果明确显示持续异常增长，再把下面整段发到同一个 Codex 对话。执行前关闭其他 Codex 任务，避免数据库正被多个进程占用：
我已确认 logs_2.sqlite 在持续异常增长，准备使用临时 workaround。请按下面顺序操作：
1. 再确认目标文件属于当前 Codex 数据目录；
2. 使用 Python sqlite3 backup API 创建带时间戳的备份，并对备份运行 PRAGMA integrity_check；
3. 备份有效后，执行 CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END; 创建临时拦截 trigger；
4. 执行 PRAGMA wal_checkpoint(TRUNCATE)；
5. 每隔 10 秒采样 MAX(id) 和 WAL 大小，共 4 次，确认不再持续增长；
6. 报告备份路径、trigger 定义、采样结果和撤销方法。
如果数据库被占用、表结构不符、备份失败或 integrity_check 不是 ok，立即停止。不要删除数据库或 WAL，也不要强制结束其他进程。不要只看“命令执行成功”。最后四次采样里，MAX(id) 和 WAL 大小不再持续增长，才算临时拦截生效。备份路径也要自己记下来。
更新后想恢复日志，删掉 trigger 即可
Codex 更新后，可以先撤销临时办法，再跑一次普通任务复测。新建对话，把下面整段粘贴进去：
请恢复 Codex 日志写入：先确认当前数据库和之前的备份路径，再执行 DROP TRIGGER IF EXISTS block_log_inserts;，执行一次 PRAGMA wal_checkpoint(TRUNCATE)，然后运行一条普通 Codex 任务并检查 logs 表是否恢复新增记录。只处理这个 trigger，不恢复整个数据库；如果验证失败，停止并报告，不要删除任何文件。简单说：没有异常增长就别处理；确认异常才备份和临时拦截；版本更新后再撤销、复测。这样比直接删数据库安全得多。