Codex客户端卡顿的解决方法logs_2.sqlite疯狂读写导致硬盘占用过高SEO关键词Codex客户端卡顿、Codex logs_2.sqlite、Codex日志文件过大、Codex SQLite、Codex硬盘读写、Codex磁盘占用、Codex性能优化、Codex客户端优化文章标签CodexSQLitePowerShellWindowsAI编程性能优化Codex客户端下载地址https://codexdown.cc/最近在高强度使用 Codex 客户端时我发现电脑开始出现明显卡顿即使 CPU 占用并不高SSD 的活动却一直保持在很高的水平。经过排查最终发现罪魁祸首就是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。打开 PowerShellsqlite3C:\Users\用户名\.codex\logs_2.sqliteCREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;这条命令会创建一个 TriggerCREATETRIGGERIFNOTEXISTSblock_log_inserts BEFOREINSERTONlogsBEGINSELECTRAISE(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 阻止日志继续写入。希望官方后续能够增加日志大小限制、自动清理机制或提供关闭日志记录的选项避免数据库无限增长导致性能下降。