Codex 日志数据库持续写盘或体积过大，应该怎样处理
先退出 Codex 并确认相关进程停止，再备份日志文件。只有在确定文件属于日志或可重建状态数据，并且没有活动进程占用时，才进行重命名或清理。不要在 Codex 正在运行时直接删除 SQLite、WAL 或 SHM 文件。
更新时间：2026-06-26
适用对象：Codex 用户 / Windows
常见表现
- logs_2.sqlite 体积持续增长
- logs_2.sqlite-wal 持续写入
- 磁盘占用明显
- Codex 无法继续对话
- 管理沙盒或设置页面异常
- config.toml 同时出现无法保存
第一步：记录现场
PowerShell：
Get-ChildItem "$env:USERPROFILE\.codex\logs_2.sqlite*" |
Select-Object Name,Length,LastWriteTime
连续观察：
1..6 | ForEach-Object {
Get-ChildItem "$env:USERPROFILE\.codex\logs_2.sqlite*" |
Select-Object Name,Length,LastWriteTime
Start-Sleep -Seconds 10
}
第二步：正常退出 Codex
- 保存正在进行的工作
- 退出 Codex App
- 关闭 IDE 扩展窗口
- 关闭相关终端
- 检查是否仍有 Codex 进程
检查进程：
Get-Process | Where-Object { $_.ProcessName -match "codex" }
第三步：备份
$src = "$env:USERPROFILE\.codex"
$backup = "$env:USERPROFILE\.codex-backup-$(Get-Date -Format yyyyMMdd-HHmmss)"
Copy-Item $src $backup -Recurse
如果目录过大，至少备份 config.toml、auth.json（注意保护）、history.jsonl 和需要保留的会话文件。
第四步：优先重命名
确认 Codex 已停止后：
Rename-Item "$env:USERPROFILE\.codex\logs_2.sqlite" "logs_2.sqlite.old"
如果存在 logs_2.sqlite-wal 和 logs_2.sqlite-shm，也一起保留为 .old。重新启动 Codex，观察是否创建新日志文件并恢复正常。
第五步：结果判断
如果恢复正常：旧日志数据库可能已经异常膨胀、锁定或损坏。
如果问题仍存在：继续检查 Codex 版本、磁盘空间、目录权限、杀毒软件、同步软件和应用自身错误。
不建议的做法
- 运行中删除 SQLite 文件
- 只删除 WAL 不处理主数据库
- 直接删除整个 .codex 目录
- 公开 auth.json
- 使用数据库修复命令修改未知 schema
- 在没有备份时强制结束多个进程
补充检查
磁盘空间：
Get-PSDrive C
目录权限：
icacls "$env:USERPROFILE\.codex"
日志文件名称和内部实现可能随 Codex 版本变化。本文依据一次 Windows 本地故障处理经验整理。操作前应备份，优先采用可回滚的重命名方案。
FAQ
- Q：可以直接删除 logs_2.sqlite 吗？
A：不建议。优先重命名为 .old，确认 Codex 正常后再删除。 - Q：删除后 Codex 无法启动怎么办？
A：将 .old 文件恢复原名，重新排查。 - Q：日志文件为什么会异常膨胀？
A：可能原因包括：数据库锁定、持续写入错误、杀毒软件或同步软件冲突。