Codex客户端卡顿的原因及解决方法

最近长时间适用 Codex 客户端写代码、跑 Agent，电脑莫名变得卡顿。看 CPU 占用并不高，但 SSD 指示灯不停闪烁，磁盘负载居高不下。折腾一番排查，终于定位到根源，问题出在 Codex 自动生成的 SQLite 日志库上。

经过排查，最终发现罪魁祸首就是：

C:\Users\用户名\.codex\logs_2.sqlite

现象

打开 Windows 的资源监视器后发现，Codex 一直在频繁读写一个 SQLite 数据库。

随着使用时间越来越长，这个文件会越来越大。

我之前的文件已经达到：1.4 GB

而且几乎一直在进行磁盘 IO。

我让 Codex 帮我统计了一天的磁盘读写

我直接让 Codex 统计应用一天内的硬盘读写量。

最终结果让我有点意外：

OpenAI.Codex

17.68 GiB

也就是说，仅仅一天时间，Codex 就对磁盘进行了 17.68 GiB 的读写。

如果长期使用，这个数字还会不断增加。

找到真正的问题

进一步查看发现：C:\Users\用户名\.codex\logs_2.sqlite

这个 SQLite 数据库一直在追加日志。

数据库越来越大之后：

• 查询速度下降
• SQLite 文件不断增长
• 持续 WAL 写入
• SSD 不停读写
• Codex 开始变卡

尤其长时间运行 Agent、生成代码、流式输出时更加明显。

第一步：清空 logs_2.sqlite

我直接发送给 Codex：

帮我清空掉 "C:\Users\用户名\.codex\logs_2.sqlite"

清空完成之后：

原来的数据库：1.4 GB

直接恢复到了一个很小的 SQLite 文件。

Codex 的响应速度立刻改善了不少。

如果 SQLite 文件大小没有立即缩小，可以执行 VACUUM，或者直接删除数据库重新生成。

第二步：禁止继续写日志

如果只是清空数据库，后面还是会继续疯狂写入。

于是我给 SQLite 创建了一个 Trigger。

打开 PowerShell：

sqlite3 "C:\Users\用户名\.codex\logs_2.sqlite" "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

这条命令会创建一个 Trigger：

CREATE TRIGGER IF NOT EXISTS block_log_inserts
BEFORE INSERT ON logs
BEGIN
    SELECT RAISE(IGNORE);
END;

它的作用就是：

当程序向 logs 表执行 INSERT 时，SQLite 会直接忽略这次写入。

因此：

• 不再新增日志
• 数据库不会继续膨胀
• 大量磁盘写入得到抑制

如果提示 sqlite3 不是内部命令

Windows 默认没有安装 SQLite。

可以先下载 SQLite Command Line Tool。

或者已经安装 sqlite3 的话，确认已经加入 PATH 环境变量。

然后重新打开 PowerShell 即可。

是否会影响 Codex 使用？

截至目前我的实际使用情况：

• 对话正常
• Agent 正常
• MCP 正常
• 插件正常
• 代码生成正常

唯一变化就是：

日志数据库几乎不再增长。

不过需要注意：

如果后续 Codex 官方修改数据库结构或者依赖日志功能，这种方式可能会受到影响，因此升级客户端后建议重新测试。

总结

如果你的 Codex 出现下面这些情况：

• 客户端越来越卡
• SSD 一直高占用
• .codex 文件夹越来越大
• logs_2.sqlite 超过几百 MB 甚至几个 GB

建议优先检查：C:\Users\用户名\.codex\logs_2.sqlite

可以先清空数据库，再根据自己的需求决定是否使用 Trigger 阻止日志继续写入。

这种通过触发器拦截日志写入属于临时方案，只能解当下的性能痛点。还是期待官方早日加入日志自动轮转、容量上限或者关闭日志的开关，不用我们手动折腾数据库，从根源解决文件持续膨胀带来的卡顿与 SSD 损耗。

以上关于Codex客户端卡顿的原因及解决方法的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。