Codex 5.5 用着用着变笨？先看本地这几个文件

20260528-codex-local-state-cleanup-cover-final

最近用 Codex 5.5，我有过一种很明显的感觉：同样难度的任务，它有时候很快能抓住问题，有时候绕半天也说不到点子上。

一开始我也会怀疑是不是模型变了，或者服务端状态不稳定。

后来看到社区里有人把这个现象和本地文件膨胀联系起来，我才想起另一个更容易被忽略的方向：本地 .codex 目录。

.codex，也就是 Codex 放本地状态、日志和历史会话的目录。它不只是一个配置文件夹。Codex 用久了以后，里面会持续产生 SQLite 数据库、日志文件和会话记录。

SQLite，也就是一种本地轻量数据库。它常用来保存程序状态。体积正常时你感觉不到它；体积失控、文件损坏或写入辅助文件残留时，启动、恢复历史任务和打开界面都会被拖慢。

所以这篇不想直接下结论说“Codex 变笨了”。

更稳的判断是：当 Codex 体验变差时，先把本地状态文件排查一遍。排除掉本机干扰以后，再去判断是不是网络、服务端、模型或任务提示的问题。

先别急着清空

我最想提醒的是这一点：不要上来就删整个 .codex 目录。

这个目录里可能有会话历史、登录状态、全局设置、项目路径痕迹和本地使用记录。它不是临时缓存那么简单。

更稳的做法是 4 步：

1. 1. 关掉 Codex。
2. 2. 备份。
3. 3. 把异常文件改名。
4. 4. 重启后用同一个任务验证。

20260528-codex-local-state-check-flow

改名比删除稳。

比如把 state_5.sqlite 改成 state_5.sqlite.old。Codex 启动时会重新生成新的状态库。如果结果不对，你还可以把 .old 后缀改回来。

真正要清理 .old 文件，也等用几天确认没问题以后再做。

重点看这几类文件

先看这几个对象：

这里的 ~ 指当前用户主目录。macOS 和 Linux 通常是 /Users/你的用户名 或 /home/你的用户名。Windows 上可以理解成 C:\Users\你的用户名。

不要动 auth.json、config.toml、Token、Cookie 和真实账号相关文件。

这些东西和身份、凭据、工具配置有关。排查性能问题时，不要把它们当成普通缓存处理，也不要截图发到公开平台。

先看体积

如果你用 macOS、Linux 或 Git Bash，可以先查大小。

下面这条命令只查看文件体积，不修改文件：

du -sh ~/.codex/state_5.sqlite ~/.codex/logs_2.sqlite \
  ~/.codex/.codex-global-state.json ~/.codex/log/codex-tui.log \
  ~/.codex/sessions/ 2>/dev/null

如果你在 Windows PowerShell 里操作，先把目录记到变量里：

$codexHome = Join-Path $env:USERPROFILE ".codex"

再看几个重点文件是否存在，以及单个文件大小：

"state_5.sqlite","logs_2.sqlite",".codex-global-state.json","log\codex-tui.log" |
  ForEach-Object {
    $path = Join-Path $codexHome $_
    if (Test-Path $path) {
      Get-Item -LiteralPath $path |
        Select-Object FullName, @{Name="SizeMB"; Expression={ [math]::Round($_.Length / 1MB, 2) }}
    }
  }

sessions/ 是目录，Windows 下可以单独看它里面文件的总大小：

$sessions = Join-Path $codexHome "sessions"
if (Test-Path $sessions) {
  Get-ChildItem -LiteralPath $sessions -Recurse -File |
    Measure-Object -Property Length -Sum
}

你不需要记住哪个数字一定异常。

我的判断很简单：如果一个日志、状态库或会话目录已经大到你一眼觉得离谱，就值得先备份，再改名测试。

我这次也在本机跑了一次只读检查。

这次检查只看文件名和大小，不读取 auth.json、config.toml、Token、Cookie 和会话正文。结果里比较明显的是 logs_2.sqlite，已经接近 1.9GB。

20260528-codex-local-state-size-check

再做备份

改任何东西之前，先关掉 Codex。

macOS、Linux 或 Git Bash 可以这样备份整个目录：

cp -a ~/.codex ~/.codex.backup.$(date +%Y%m%d)

Windows PowerShell 可以这样备份：

$codexHome = Join-Path $env:USERPROFILE ".codex"
$backup = "$codexHome.backup.$(Get-Date -Format yyyyMMdd)"
Copy-Item -LiteralPath $codexHome -Destination $backup -Recurse

备份目录不要上传到网盘或公开仓库。里面可能有会话片段、路径、账号状态和本机工具配置。

这一步麻烦一点，但能避免后面后悔。

改名，不是直接删

备份以后，再处理怀疑异常的文件。

macOS、Linux 或 Git Bash 示例：

mv ~/.codex/state_5.sqlite ~/.codex/state_5.sqlite.old
mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.old
mv ~/.codex/log/codex-tui.log ~/.codex/log/codex-tui.log.old

Windows PowerShell 示例：

$codexHome = Join-Path $env:USERPROFILE ".codex"
Rename-Item -LiteralPath (Join-Path $codexHome "state_5.sqlite") -NewName "state_5.sqlite.old"
Rename-Item -LiteralPath (Join-Path $codexHome "logs_2.sqlite") -NewName "logs_2.sqlite.old"
Rename-Item -LiteralPath (Join-Path $codexHome "log\codex-tui.log") -NewName "codex-tui.log.old"

如果 .codex-global-state.json 也明显异常，再单独处理它。

不要为了省事写一条通配符命令，把所有 .sqlite、.json 或 sessions/ 一锅端。

sessions/ 我不建议整目录改名。它里面是历史会话。你可以先保留最近会话，只把明确不用的旧会话归档。

WAL 和 SHM 文件也一样。

如果你看到 state_5.sqlite-wal、state_5.sqlite-shm、logs_2.sqlite-wal、logs_2.sqlite-shm 这类文件异常变大，要先确保 Codex 已经完全退出，再和对应的 SQLite 文件一起改名归档。

重启后用旧任务验证

清理动作做完后，不要只看 Codex 能不能打开。

要找一个你之前觉得它很费劲的任务，重新跑一遍。

我一般看 4 件事：

• • 启动是否变快。
• • 历史会话打开是否变快。
• • 同一个任务是否少绕路。
• • 任务结束时是否还能说清改了什么、验了什么、哪些没验。

如果体验恢复正常，就先保留 .old 文件几天。

如果体验变差，或者发现历史会话缺失、配置状态不对，就把 .old 后缀改回去，或者从备份目录恢复。

这就是为什么前面一直说改名，不要直接删。

长期信息别只放在会话里

本地状态文件可以重建，但项目里的长期信息不应该只压在会话里。

比如这些内容，最好写进项目里的纯文本文件：

• • 项目是做什么的。
• • 哪些目录不能动。
• • 构建和测试命令是什么。
• • 哪些文件包含敏感信息。
• • 哪些操作必须先确认。
• • 这类任务做完怎么验收。

如果你主要用 Codex，可以把项目级规则写到 AGENTS.md。AGENTS.md 是 Codex 会读取的项目规则文件，用来告诉它这个仓库怎么工作。

如果你的团队还没有用 AGENTS.md，也可以先用 PROJECT.md 保存项目背景和协作约定。

重点不是文件名。

重点是把长期规则放进仓库里的可读文本，而不是全靠本地 SQLite 状态库和聊天历史。

当然，密钥、账号、客户资料、真实 Cookie 和 Token 不能写进去。长期规则要保存边界，不能保存秘密。

最后

Codex 变慢、变卡、输出不稳定，不一定就是模型降级。

本地状态库、日志和历史会话膨胀，也会影响使用体验。

我现在的处理顺序是：

先看本地文件体积
-> 备份
-> 改名异常文件
-> 重启验证旧任务
-> 稳定几天后再清理旧文件

这套动作不能保证 Codex 一定恢复如初。

但它能先排除一个很现实的干扰项：本机状态已经拖累工具本身。

如果你也觉得 Codex 最近时灵时不灵，先别急着怀疑模型。

先看一眼自己的 .codex 目录。

有时候，问题不在云端，而在你本机那个已经很久没人管的状态文件夹里。

参考资料

• • OpenAI Codex issue #16886：https://github.com/openai/codex/issues/16886
• • OpenAI Codex issue #16158：https://github.com/openai/codex/issues/16158
• • OpenAI Codex issue #21750：https://github.com/openai/codex/issues/21750
• • OpenAI Codex issue #24030：https://github.com/openai/codex/issues/24030
• • OpenAI Codex AGENTS.md 文档：https://developers.openai.com/codex/guides/agents-md

我是一名 数字创作者 · 独立开发者 · 技术博主，专注成长，拓展技术边界，持续突破自我。

如果这篇文章对你有用，欢迎点个 赞，也欢迎在评论区聊聊你的实际问题。

关注 「程序员NEO」，我会持续分享 AI 编程、工程实践和效率提升相关内容。