Codex Desktop在长时间运行后就会导致电脑特别卡

御琪幽然 2026-08-13 11:54 1

各位有遇到这个情况吗?

我也检查了任务管理器,没发现有异常的CPU、内存、硬盘中占用,句柄数也没什么特殊的地方。

但是退出Codex也不会解决卡顿的问题,唯一的解决方案是重启电脑。

难道是有什么内存泄漏的情况?

最新回复 (14)
  • apparition 08-13 11:55
    1

    小问题

    我的 codex 在累积 100k 代码修改之后

    自己闪退了

  • 夜雨 08-13 11:56
    2

    包括不限于好几个node服务、mcp连接不释放等等等;


    codex就是屎山,问题数不胜数。

  • 御琪幽然 楼主 08-13 11:56
    3

    以前就看到有些讨论帖在反馈这个问题,本想着等等看官方优化能不能解决,没想到迄今为止还是有这个毛病,麻了

  • yuuc 08-13 11:57
    4

    我的是一运行就开始卡,鼠标都拖不动那种。

  • 御琪幽然 楼主 08-13 11:57
    5

    刚启动的前几秒确实非常卡,切换对话也会很卡。

  • 御琪幽然 楼主 08-13 11:58
    6

    那很崩溃了。前段时间我遇到过内置浏览器有bug的情况,只要调用内置浏览器codex就会闪退。后来修复了。

  • 御琪幽然 楼主 08-13 11:58
    7

    怕不是codex就是用codex自己开发的,所以才卡成这样

  • Tinnnnnnk 08-13 12:07
    8

    现在我每天打开codex,切换会话都要卡上好几秒甚至十来秒,只能说codex现在就是一个大屎山,卡爆了 ^-^

  • kevin335200 08-13 12:11
    9

    Electron 大屎山,漏内存的,我启动后啥都没干,过了一小时一看用了 2G 多内存了

  • RyanVan 08-13 12:11
    10

    巧了,这几天我也遇到类似问题,最后发现是


    dwm.exe(桌面窗口管理器)运行数小时后窗口合成状态异常


    原因是新版Windows的某个补丁跟英伟达驱动的兼容问题


    可通过管理员终端重启恢复:


    taskkill /F /IM dwm.exe
  • Neptune 08-13 12:22
    11

    codex各种卡,已经烂的分析是哪种卡了,反正自适应

  • utf8coding 08-13 12:23
    12

    因此从opencode 转 codex 又回 opencode 了

  • Waitingfor 08-13 12:32
    13

    1.可以尝试手动删除这3个文件的,退出codex后,再删除,

    然后重启codex,此时这3个文件大小肯定是会猛增的,


    设备:macOS / Linux:


    rm ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm

    或者一行通配搞定:


    rm ~/.codex/logs_2.sqlite*



    设备:Windows(PowerShell):


    Remove-Item "$env:USERPROFILE\.codex\logs_2.sqlite*"

    删除这三个文件


    2.把这段直接发给 AI 让它代跑:


    排查 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘:
    1) SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC; 看 TRACE 是否占大头
    2) 隔 30 秒采两次 SELECT MAX(id) FROM logs; 和 logs_2.sqlite-wal 文件大小,确认是否还在涨
    中招的话:先用 .backup 备份 → 建 BEFORE INSERT ... RAISE(IGNORE) trigger 拦 logs 表 insert →
    PRAGMA wal_checkpoint(TRUNCATE) 回收 WAL → 再采样确认 MAX(id) 和 WAL 都不再增长。

    3.前几次这3个文件大小可能还会增长,你可以和codex反复确认这个问题是否还存在,同时观察文件资源管理器里这3个文件的大小的变化,多发几次,


    排查 ~/.codex/logs_2.sqlite 是否因 TRACE 日志持续高频写盘:
    1) SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC; 看 TRACE 是否占大头
    2) 隔 30 秒采两次 SELECT MAX(id) FROM logs; 和 logs_2.sqlite-wal 文件大小,确认是否还在涨
    中招的话:先用 .backup 备份 → 建 BEFORE INSERT ... RAISE(IGNORE) trigger 拦 logs 表 insert →
    PRAGMA wal_checkpoint(TRUNCATE) 回收 WAL → 再采样确认 MAX(id) 和 WAL 都不再增长。

    直到这3个文件的大小和我一样,

    我还是一直处于截断状态,我现在3个文件的大小:

  • ioot 08-13 12:47
    14

    不一定是内存泄漏,Electron 应用长时间运行更常见的是 renderer/GPU process、缓存、文件 watcher 堆积。


    任务管理器看 CPU/RAM 正常也不代表没问题,Mac 建议看 Activity Monitor 的 Memory Pressure 和 swap。


    另外 Codex 这种 AI IDE 类工具,长时间挂一个大项目 + 大上下文,比普通编辑器更容易出现状态膨胀。试试退出后确认 Helper 进程杀干净,新开 session,排除 node_modules/.next 等目录监听。


    如果每次都是运行几个小时必现,那才值得怀疑泄漏。

* 帖子来源Linux.do
返回