一、问题背景

近期 GitHub 上有大量用户反馈 Codex CLI 存在日志写入异常的问题。

主要表现：

• logs_2.sqlite
• logs_2.sqlite-wal

持续增长，导致 SSD 写入量明显增加。

需要说明的是：

这并不是 Codex 在读取或写入你的私人文件，也不是恶意操作 SSD，而是 Codex 自己的 SQLite 日志数据库频繁写入造成的。

---

二、查看 Codex 配置目录

PowerShell：

dir $env:USERPROFILE\.codex

主要关注：

logs_2.sqlite
logs_2.sqlite-wal
logs_2.sqlite-shm

例如：

logs_2.sqlite          380252160 Bytes
logs_2.sqlite-wal        4305432 Bytes

---

三、查看所有 SQLite 文件

dir $env:USERPROFILE\.codex\*.sqlite*

输出示例：

goals_1.sqlite
logs_2.sqlite
logs_2.sqlite-shm
logs_2.sqlite-wal
memories_1.sqlite
state_5.sqlite
state_5.sqlite-shm
state_5.sqlite-wal

真正需要关注的是：

logs_2.sqlite
logs_2.sqlite-wal

---

四、查看日志文件

dir $env:USERPROFILE\.codex\logs*

如果输出类似：

logs_2.sqlite
logs_2.sqlite-shm
logs_2.sqlite-wal

说明 Codex 使用 SQLite 保存日志。

---

五、查看是否持续写盘

PowerShell：

while ($true) {
    Get-Item "$env:USERPROFILE\.codex\logs_2.sqlite" |
        Select Length, LastWriteTime

    Start-Sleep 2
}

如果看到：

Length

380252160

380260352

380272640

380284928

不断增长，则说明：

Codex 正在持续写 SQLite 日志。

---

六、查看后台是否存在多个 Codex 进程

Get-Process codex* |
Select Name,Id,CPU,StartTime

如果存在多个：

codex.exe
codex.exe
codex.exe

说明可能存在多个后台实例，也可能增加日志写入量。

---

七、查看 Codex 版本

codex --version

我的版本：

codex-cli 0.142.1

---

八、目前检查结果

本机：

logs_2.sqlite      ≈380MB
logs_2.sqlite-wal  ≈4MB

属于：

• 已开始积累日志
• 但还没有达到 GitHub 上部分用户几 GB～几十 GB 的程度

说明：

目前确实存在日志增长，但暂未达到严重程度。

---

九、如何清理日志

1、关闭 Codex

taskkill /IM codex.exe /F

---

2、删除日志数据库

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

删除内容包括：

logs_2.sqlite
logs_2.sqlite-wal
logs_2.sqlite-shm

下次启动会自动重新创建。

不会影响：

• 登录状态(auth.json)
• 配置(config.toml)
• Session
• 插件
• Cache

---

十、更新 Codex

npm install -g @openai/codex@latest

然后确认：

codex --version

---

十一、哪些文件不要删

保留：

auth.json
config.toml
sessions/
memories/
packages/
plugins/

这些包含：

• 登录信息
• 配置
• 历史 Session
• 插件

不要删除。

---

十二、结论

本次检查结果：

Codex 版本：

0.142.1

日志数据库：

logs_2.sqlite

大小：

≈380MB

目前属于：

• 日志增长存在
• 暂未达到 GitHub 上数 GB～几十 GB 的异常情况

建议：

1. 更新到最新版本
2. 定期检查 logs_2.sqlite
3. 如果日志持续增长，可删除日志数据库重新生成
4. 后续继续关注官方修复日志写盘问题