Codex 后台疯狂写盘？一次 AI 编程助手异常占用 SSD 的排查与修复记录

2026/7/12 4:50:13

最近遇到一个比较奇怪的问题。电脑处于闲置状态，没有进行代码编译，没有复制大型文件，也没有运行任何占用磁盘的任务，但是硬盘指示灯却一直闪烁。

打开任务管理器查看，CPU 使用率正常，内存占用正常，网络流量正常，唯独磁盘写入一直存在。进一步查看磁盘活动来源，一个熟悉的进程名出现了：Codex。

这个平时用于辅助编码、分析项目、生成代码的 AI 编程工具，正在后台持续产生磁盘写入。更关键的是，当时 Codex 并没有执行任何代码生成任务，它只是保持运行状态。

这类问题最容易让人误判，因为表面看起来像：Windows 后台服务异常，某个软件偷偷缓存数据，系统更新正在运行，或者硬盘出现故障。但进一步排查后发现，问题集中在 Codex 的本地数据目录。

第一步：确认真正的写入来源

遇到磁盘异常，第一步不是卸载软件，也不是直接删除文件。正确的排查方式应该是先找到是谁在持续写入。

Windows 下打开：任务管理器 → 性能 → 磁盘，观察磁盘活动情况。如果发现 Codex、Node、Electron 相关进程持续占用磁盘，就继续查看具体文件。点击“打开资源监视器 → 磁盘”，这里可以看到哪个进程正在访问磁盘，正在访问哪些文件，文件路径在哪里。

如果发现大量访问集中在C:\Users\用户名\.codex\，并且目录中的文件大小持续变化，那么基本可以锁定问题来自 Codex 本地数据。

找到异常文件：持续增长的 SQLite 数据库

进入 Codex 数据目录：

cd $HOME\.codex

查看占用最大的文件：

Get-ChildItem -Recurse -File | Sort-Object Length -Descending | Select-Object -First 20

这里提前进入.codex目录非常重要。如果直接从用户目录甚至整个 C 盘搜索，会扫描大量无关文件，速度会明显下降。很多异常情况中，会发现类似文件：logs_2.sqlite、logs_2.sqlite-wal、logs_2.sqlite-shm，或者state_x.sqlite。

为什么 AI 工具会使用 SQLite？因为 SQLite 非常适合作为桌面应用的本地数据库。它不需要额外启动数据库服务，一个文件即可完成数据保存、查询、更新。浏览器历史记录、聊天软件缓存、IDE 插件数据，都大量使用 SQLite。Codex 同样会利用本地数据库保存会话信息、Agent 执行记录、工具调用历史、调试日志、本地运行状态。

正常情况下，这些文件应该缓慢增长。但在部分版本中，如果日志系统出现异常——例如某些内部事件被高频记录，调试日志持续产生，Agent 状态变化频繁触发写入——就可能导致 SQLite 数据库不断产生新的写入。最终表现就是电脑没有执行任务，但磁盘仍然持续活动。

为什么日志数据库会导致 SSD 持续写入？

很多人看到几个 GB 的日志文件，第一个想法是“删掉就好了”。但真正的问题不是文件占用了多少空间，而是它是不是还在不断变化。一个 10 GB 的文件静态存在，对 SSD 影响有限；但一个几十 MB 的数据库如果每秒持续更新，反而可能产生大量实际写入。

原因在于 SSD 的存储机制。SSD 使用 NAND Flash，数据修改时并不是简单覆盖原来的位置，通常需要经历：读取旧数据，修改内容，重新组织存储块，写入新的数据。这个过程会产生 Write Amplification（写入放大），也就是说程序实际修改的数据量，可能小于 SSD 实际完成的写入量。

另外，如果 SQLite 使用 WAL（Write Ahead Logging）模式，数据库修改不会立即覆盖主数据库文件，而是先追加写入xxx.sqlite-wal，同时维护xxx.sqlite-shm文件。这种设计可以提高数据库可靠性和并发性能，但如果应用持续产生大量事务提交，WAL 文件会快速增长。

因此排查磁盘异常时，不要只看“这个文件有多大”，更应该关注“哪个文件正在持续变化”。

解决方案：优先清理异常日志数据库

发现异常后，不建议直接删除整个.codex目录，因为其中可能包含用户配置、登录状态、Agent 运行信息以及其他本地数据。更安全的方法是只处理异常日志数据库。

首先完全退出 Codex。注意不要只关闭窗口，需要确认后台进程已经结束。进入目录：

cd $HOME\.codex

先备份数据库文件：

New-Item -ItemType Directory -Path backup -ForceCopy-Item *.sqlite* backup\

然后清理日志数据库：

Remove-Item logs_*.sqlite*

这里使用sqlite*而不是sqlite，是因为需要同时处理logs_2.sqlite、logs_2.sqlite-wal、logs_2.sqlite-shm这些相关文件。

重新启动 Codex，程序会自动重新创建需要的数据，一般不会影响项目代码、Git 仓库和工作目录。如果后续发现 Codex 无法启动，或者状态异常，再考虑处理state_x.sqlite，而不是一开始全部删除。

进一步分析：查看数据库到底发生了什么

如果希望进一步定位异常原因，可以在删除之前分析数据库。安装sqlite3后，连接数据库：

sqlite3 logs_2.sqlite

查看数据表：

.tables

查看某个日志表数量：

SELECT COUNT(*) FROM 表名;

如果发现某张表记录数量异常增长，就可以进一步判断到底是哪类事件导致日志膨胀。另外，也可以观察logs_2.sqlite-wal文件大小，如果 WAL 文件持续增长而主数据库变化不明显，通常说明大量事务正在写入等待合并。

清理完成后，如何确认问题恢复？

不要只看 Codex 是否能打开，需要观察几个指标。

电脑空闲时，任务管理器中的磁盘活动应该明显降低，不会再出现长时间持续写入。重新检查dir $HOME\.codex，观察logs_*.sqlite大小，正常情况下不会持续快速增长。

如果担心 SSD 寿命，可以查看 CrystalDiskInfo 或 Hard Disk Sentinel，关注 Total Host Writes 这一项。如果长期出现异常增长，可以进一步确认是否受到影响。

从这次故障看 AI 工具正在成为新的开发基础设施

Codex 这次问题，本质上反映了一个新的变化：AI 工具正在从“辅助插件”变成开发环境的一部分。过去开发者关注 IDE 是否流畅，插件是否冲突，编译速度是否正常；现在还需要关注 AI 缓存是否增长，日志是否异常，本地数据库是否膨胀，后台 Agent 是否持续运行。

因为 AI Agent 和传统插件不同，它会长期维护项目上下文、历史任务、工具调用状态，因此也需要像数据库服务和开发环境一样进行管理。

类似的排查方法，同样适用于其他基于 Electron / Node.js 的 AI 工具，例如 AI 编程插件、智能 IDE、本地 Agent 工具。它们通常都会将数据存储在%APPDATA%或者用户目录。因此，定期检查数据目录，关注异常增长文件，合理迁移大型缓存，都会成为未来 AI 开发环境中的日常维护工作。