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

最近遇到一个比较奇怪的问题。电脑处于闲置状态没有进行代码编译没有复制大型文件也没有运行任何占用磁盘的任务但是硬盘指示灯却一直闪烁。打开任务管理器查看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 使用 WALWrite 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 开发环境中的日常维护工作。总结如果遇到 Codex 后台疯狂写盘可以按照以下思路处理通过资源监视器确认真正写入来源检查.codex数据目录定位异常增长的 SQLite 日志文件备份后优先清理logs_*.sqlite*重启 Codex观察磁盘状态如果 CLI 环境异常再重新安装。AI 正在成为开发者的新基础设施而管理这些智能工具的运行状态也会逐渐成为开发工作的一部分。