codex 频繁刷磁盘的 bug 及解决方案

Journey95 2026-06-25 08:39 1

[消息源于 x 站]


Codex 史诗级大 BUG


高强度使用 Codex 的宝子们注意一下,你的磁盘可能正在遭受核打击


Codex 当前在流式任务和长时间运行时,会以极高频率往 ~/.codex/logs_2.sqlite 狂写 TRACE 日,这样的强度可以直接把消费级 SSD 直接写废


我自己也中招了,中招了的小伙伴自己输入这段提示词诊断一下吧先


提示词:帮我检测 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘?


如果真的中招了,再输入这个提示词赶紧止损吧


提示词:中招了就直接先备份,再用 SQLite trigger 拦截 logs 表, 并 checkpoint/truncate WAL,最后采样确认 MAX(id) 和 WAL 不再增长


临时解决方案:
sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

最新回复 (23)
  • 4NF 06-25 08:48
    1
    codex 不是已经更新解决了吗,我记得昨天还看到帖子了
  • momo31 06-25 08:49
    2
    已中招
  • watzds 06-25 08:50
    3
    还没修复吗,看 X 上有说更新最新版就好了
  • p2007 06-25 08:50
    4
    好像还没完全解决,GitHub Issue 里还在讨论: https://github.com/openai/codex/issues/28224
  • woodnaonly 06-25 08:55
    5
    叽里咕噜的说啥呢 ,最新版本已经修复了,只有用 wsl2 的会中招
  • fengyj 06-25 09:16
    6
    昨天开启了 codex 的 otel logs 和 traces ,两个 requests ,直接打了 1w+ spans ,还有无数个空 message logs
  • unusualcat 06-25 09:19
    7
    你把报 bug 的 GitHub 链接发给它,告诉它目前的故障表现,它会自己修的。
  • nxlqhmr 06-25 09:21
    8
    自己 clone codex 改代码就行了
  • ramcasky 06-25 09:21
    9
    我就说...
  • ifeng66 06-25 10:21
    10
    屮,我文件管理器一直崩的原因是这个啊。。
  • JSbiu 06-25 10:24
    11
    codex 判断中招了,已采用楼主的临时方案🌹
  • evan1 06-25 10:34
    12
    感谢,我说怎么用什么电脑每次打开 codex 鼠标指针都会卡,原来是这个导致的。
  • ziyeziye 06-25 11:19
    13
    我是 mac, 更新了最新的 codex ,发现这个 log 还是在写入,现在已经写入 27W 次了
  • justdoitzZ 06-25 12:31
    14
    干,中招了。
  • ForkNMB 06-25 12:32
    15
    @4NF 哪里更新了你确认解决问题了?
  • BestPix 06-25 14:12
    16
    请帮我只读排查本机 Codex 的 ~/.codex/logs_2.sqlite 是否仍在因为 TRACE 日志或流式事件持续高频写盘。

    约束:
    1. 只做只读诊断。
    2. 不要删除文件,不要 VACUUM ,不要 checkpoint/truncate ,不要改 schema ,不要创建 trigger ,不要 kill 进程,不要升级或重装 Codex 。
    3. 所有 SQLite 查询都用只读 URI:db="file:$HOME/.codex/logs_2.sqlite?mode=ro"。
    4. 如果 sqlite3 、lsof 或数据库文件不存在,直接说明,不要猜。
    5. 最后请输出:是否疑似中招、证据、风险等级、下一步建议。

    请按下面顺序执行并解释结果:

    第一步,确认文件大小:

    ```bash
    du -h \
    ~/.codex/logs_2.sqlite \
    ~/.codex/logs_2.sqlite-wal \
    ~/.codex/logs_2.sqlite-shm 2>/dev/null

    ls -lh ~/.codex/logs_2.sqlite* 2>/dev/null
    ```

    第二步,只读检查 SQLite schema 和日志分布:

    ```bash
    db="file:$HOME/.codex/logs_2.sqlite?mode=ro"

    sqlite3 "$db" "PRAGMA table_info(logs);"

    sqlite3 "$db" "
    PRAGMA journal_mode;
    PRAGMA wal_autocheckpoint;
    SELECT COUNT(*) AS rows, MIN(id), MAX(id) FROM logs;
    SELECT level, COUNT(*) AS rows, ROUND(SUM(estimated_bytes)/1024.0/1024.0, 1) AS mib
    FROM logs
    GROUP BY level
    ORDER BY SUM(estimated_bytes) DESC;
    "
    ```

    第三步,做 15 秒短窗口采样:

    ```bash
    db="file:$HOME/.codex/logs_2.sqlite?mode=ro"
    before_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;")
    before_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;")
    sleep 15
    after_id=$(sqlite3 "$db" "SELECT COALESCE(MAX(id),0) FROM logs;")
    after_count=$(sqlite3 "$db" "SELECT COUNT(*) FROM logs;")
    echo "id_delta=$((after_id-before_id))"
    echo "count_delta=$((after_count-before_count))"
    ```

    第四步,查看是否有 Codex 进程占着数据库或 WAL:

    ```bash
    lsof -nP \
    ~/.codex/logs_2.sqlite \
    ~/.codex/logs_2.sqlite-wal \
    ~/.codex/logs_2.sqlite-shm 2>/dev/null
    ```

    判断标准:
    - 如果 id_delta 很高,但 count_delta 很小或为 0 ,说明可能在持续插入又修剪旧日志。
    - 如果 logs_2.sqlite-wal 持续变大,或者有老 Codex 进程占着 deleted WAL ,要重点提示。
    - 如果 id_delta 很低、WAL 不持续增长、只有当前 Codex 进程正常打开文件,就倾向于正常。
    - 不要直接给我执行修复操作。需要修复时,只列出方案和风险,等我确认。
  • Grefer 06-25 14:20
    17
    @evan1 我也是,有时候 codex 界面鼠标就卡没了,输入框点不动
  • evan1 06-25 14:24
    18
    @Grefer #17 我上午按文中的方法弄了一下,刚刚还是复现了这个问题。鼠标卡好像不是刷日志导致的。

    只能等 codex 更新了。
  • Grefer 06-25 14:37
    19
    @evan1 #18 那就不清楚了,按照 OP 的方法排查了一下,我也是中招的
  • VibeHex 06-25 15:23
    20
    让 codex 自己修,他自己先修,然后更新后说修好了。重启后告诉我没有复现。
  • skuuhui 06-25 16:08
    21
    把公司电脑搞坏,重新申请一台
  • yu6564172 06-25 16:08
    22
    claude 修改好的,mac 的用出来 1%磨损了
  • watzds 06-25 16:45
    23
    更新成最新版,windows 上又出新问题了,会频繁弹窗沙箱 exe 不存在,先禁用沙箱了😂
* 帖子来源V2EX
返回