Codex 越用越慢？我装了一个小工具，第一次体检就揪出 829 条活跃线程

你以为 AI 助手变慢，是模型不行、网络不稳、电脑太老。

但这次本机排查给了一个更扎心的答案：不是“它突然变笨了”，而是你长期和它协作留下的会话、日志、标题、首条消息，已经在本地堆成了一座小山。

这不是一次玄学优化，而是一次很典型的 Codex 本机体检：先安装一个维护 skill，再只读扫描本地状态，最后根据数据决定下一步是否清理。整个过程没有改配置、没有删除文件、没有碰认证信息，但已经足够判断问题在哪里。

一、真正的问题：不是先清理，而是先量化

很多人遇到 Codex 变慢，会直接做三件事：

1. 删缓存。
2. 重启软件。
3. 重新安装。

这三个动作有时有效，但问题是：你不知道自己删掉了什么，也不知道真正占用在哪里。

这次实操的目标很克制：先安装 keep-codex-fast，只运行它的 report 模式，先把本机 Codex 状态量化出来。

当时用户只说了一句：

帮我安装 keepcodex fast skills

随后又补了一句：

运行一下

所以整个操作链路非常接近普通用户的真实场景：不是写一个复杂脚本，而是把一个可复用的维护工具装好，然后让它给出体检报告。

二、第一坑：GitHub API 和 Python SSL 都不可靠

安装并不是一行命令直接成功。

一开始按常规 skill 安装路径走，先读本地 skill 安装器说明，再尝试用官方列表脚本和 GitHub contents API 做发现。但这台机器上遇到了两个现实问题：

• Python 访问 GitHub 时出现 SSL: CERTIFICATE_VERIFY_FAILED
• GitHub API / contents 路径后来返回 403

这就是很多“教程一行命令”最容易忽略的地方：真实机器上的证书链、代理、API 限流和权限状态，都会让标准路径失效。

最后可用的不是 API，而是更基础的 Git 协议探测：

git ls-remote https://github.com/vibeforge1111/keep-codex-fast.git

这个命令成功返回，至少确认两件事：

• 仓库真实存在；
• 当前网络环境能通过 Git 访问它。

这一步很关键。它把问题从“我猜有这个工具”变成了“我确认这个仓库可访问”。

三、第二坑：安装成功，不代表安装完整

接着尝试用系统 skill 安装脚本做安装：

python3 ~/.codex/skills/.system/skill-installer/scripts/install-skill-from-github.py \
  --repo vibeforge1111/keep-codex-fast \
  --path . \
  --name keep-codex-fast \
  --method git

这一步表面上完成了，但复查文件时发现一个更隐蔽的问题：安装目录里只有根文件，真正要运行的脚本 scripts/keep_codex_fast.py 没有被带下来。

如果这时候直接宣布“安装成功”，后面用户一运行就会失败。

所以这里做了一个非常朴素但有效的验收：安装后看文件结构，而不是只看命令退出码。

find ~/.codex/skills/keep-codex-fast -maxdepth 3 -type f | sort

发现缺文件后，处理方式也很直接：删除这次不完整安装，完整 clone/copy 仓库内容到本地 skill 目录，再移除复制过来的 .git 元数据。最终安装目录中确认包含：

• SKILL.md
• README.md
• scripts/keep_codex_fast.py
• references/handoff-template.md
• tests/smoke_test.py

这一步的经验很实用：安装插件、skill、CLI 工具时，别只看“命令成功”，要看“关键入口文件是否存在”。

四、真正有价值的是体检数据

安装完成后，执行默认 report：

python3 ~/.codex/skills/keep-codex-fast/scripts/keep_codex_fast.py

这次运行是只读模式，报告里明确出现了这些安全标记：

requested_mode report
effective_mode report
mode_safety read_only=true privacy=pseudonymous
done

也就是说，它只是扫描状态，不会直接替你删除本地记录。

然后关键数字出来了：

thread_active_rows 829
thread_title_chars 179446
thread_first_user_message_chars 247797
thread_titles_over_limit 119
thread_first_user_message_over_limit 102
thread_first_user_message_over_10k 3
thread_metadata_repair_candidates 129
old_session_candidates 741
logs_mb 636.3
size_sessions_gb 1.067
size_archived_sessions_gb 0.031
config_prune_candidates 0
worktree_candidates 0
extended_paths 0

这组数据比“感觉有点慢”有价值得多。

它至少说明了四件事。

第一，活跃线程数已经到 829。这意味着本机协作历史非常密集，线程状态本身就是需要管理的对象。

第二，标题和首条用户消息累计字符数很高，分别到了 179446 和 247797。如果 UI、索引、搜索或上下文恢复会读取这些元数据，过长内容就可能拖慢体验。

第三，旧 session 候选有 741，日志达到 636.3 MB，sessions 目录约 1.067 GB。这不是“系统垃圾”，而是长期协作留下的生产记录。

第四，config_prune_candidates、worktree_candidates、extended_paths 都是 0。这很重要，说明当下不是所有地方都乱了，真正值得关注的是 sessions、logs 和线程元数据。

五、中途还有一个非阻塞错误

报告过程中还有一个小插曲：Node 进程子报告遇到了 UTF-8 decode error：

'utf-8' codec can't decode bytes ... invalid continuation byte

但它没有阻塞主报告完成。

这个细节适合单独拎出来讲，因为它代表一种更成熟的自动化设计：子模块失败，不应该让主流程完全瘫痪。尤其是维护类工具，最重要的是先给出核心诊断，再提示哪些子项没跑完。

普通用户看到这种错误，最容易以为“工具坏了”。但这次的判断是：主报告已经完成，核心指标可信；Node 子报告失败只是后续可以修的独立问题。

六、这次没有直接清理，反而是正确选择

看到 old_session_candidates 741 和 logs_mb 636.3，第一反应很容易是：那就删吧。

但这次没有直接删除。

原因很简单：这些 session 可能包含未总结的上下文、未沉淀的工作记录、还没交付完的线程。维护类操作应该遵守一个顺序：

1. 先只读扫描；
2. 再确认候选范围；
3. 需要时先生成 handoff；
4. 用户明确同意后再 apply；
5. 最后复跑报告验证变化。

这不是保守，而是对个人工作流负责。

AI 协作工具和浏览器缓存不一样。浏览器缓存删掉最多重新加载，Codex session 删错了，可能丢的是一段真实工作上下文。

七、普通用户可以复用的检查清单

如果你也觉得 Codex 用久了变慢，可以按这个顺序来，不要一上来就删文件。

1. 先确认工具来源

git ls-remote https://github.com/vibeforge1111/keep-codex-fast.git

能访问仓库，再进入安装步骤。

2. 安装后检查关键文件

find ~/.codex/skills/keep-codex-fast -maxdepth 3 -type f | sort

重点看有没有：

• SKILL.md
• scripts/keep_codex_fast.py
• README.md

3. 第一次只跑 report

python3 ~/.codex/skills/keep-codex-fast/scripts/keep_codex_fast.py

看到 read_only=true 再继续看报告，不要急着 apply。

4. 优先看这些指标

thread_active_rows
old_session_candidates
logs_mb
size_sessions_gb
thread_metadata_repair_candidates
thread_first_user_message_over_10k

这些指标能帮你判断问题是日志、历史 session、线程元数据，还是别的目录。

5. 清理前先问一个问题

这些历史记录里，有没有最近还要继续接力的工作？

如果有，先做 handoff 或导出摘要，再进入清理动作。

八、这次实操给我的判断

这次案例最有价值的地方，不是装了一个 skill，也不是发现 636.3 MB 日志。

真正的价值是：它把“Codex 好像变慢了”这句模糊抱怨，变成了一张可讨论的本机体检表。

有了这张表，你就不会乱删：

• 线程多，就治理线程；
• 日志大，就处理日志；
• session 多，就先归档再清理；
• 配置没问题，就别动配置；
• worktree 没候选，就别瞎删项目目录。

我越来越觉得，AI 工具的长期使用能力，不取决于你会不会写提示词，而取决于你有没有把它当成一个需要维护的工作系统。

提示词解决一次对话。

维护习惯，决定这个系统能不能陪你跑一年。