视频来源：Bilibili 原视频

你有没有遇到过这种情况：明明没开浏览器，活动监视器里却挤满了 Chrome，风扇狂转，电脑烫手。我遇到了，肇事者是 Codex。如果你用的是 Cursor 或者 Claude Code，也别急着关掉这篇——这个坑的机制，它们一样踩。下面是我从事故现场一路查到根因、再到彻底根治的完整记录。

事故现场

事情发生在 7 月 12 号晚上。我让 Codex 排查一个很小的问题：网络差的时候，页面加载的样式不好看。

它干活是真勤快。为了模拟各种网络场景，36 分钟里前后开了 16 个无头浏览器，问题也真修好了。但任务结束之后，这 16 个浏览器，一个都没关。

结果就是：

• 8 个 Renderer 进程，每个吃掉约 96% 的 CPU，各自独占一个核
• 11 核的机器，load average 冲到 88
• 交换内存用掉 21.8GB

整台电脑，卡到怀疑人生。

三层根因

把日志翻出来之后，我发现这不是一次意外，是三层问题叠在一起的必然结果。

第一层：守护进程没有下班时间。Codex 用的 playwright 命令行工具（@playwright/cli），每开一个会话就留下一个常驻的 cliDaemon，外加一个独立的 Chrome。这个 daemon 没有空闲超时，只在收到 SIGTERM/SIGINT 时才退出。Codex 会话一结束，它就孤儿化（父进程 PID 变成 1），永远赖着。

第二层：关浏览器的规矩，在说明书搬运的路上弄丢了。微软原版的技能说明书里，close 这个词出现了 12 次；而 Codex 实际使用的搬运版说明书里，出现了 0 次。清理契约在分发链上丢失——这是我觉得全案最有意思的一层。

第三层：放大器。这些浏览器启动时带着 --disable-background-timer-throttling 参数（后台也不降频），加上残留页面还卡在报错死循环里。所以它们不只占着内存，还在原地全速空转。

不是我一个人：官方仓库翻一遍

这是不是我的环境问题？我去 openai/codex 官方仓库翻了一遍 issue（以下编号都逐条核验过）——还真不是：

• #14548（3 月 13 日）：整条问题链最早的主 issue，"Codex spawning too many mcp instances and never kills them"。后来多个 issue 被官方关成它的 duplicate，但它本身挂了 4 个月，至今 open，评论区没有一条官方成员回应。
• #16256：目前最极端的浏览器案例——单个 browser MCP 下累积了 571 个 Chrome 子进程，16GB 内存加 8GB zram 全部吃满。
• #12491：标题就写着 1300+ 僵尸进程、37GB 内存泄漏，正文实测 1319 个——那还是一台 64GB 的机器。
• #28352：和我遇到的一模一样，会话关掉之后无头浏览器赖在后台。

要说明的是：官方在 4 月修过一次相关问题（#16895），但有用户实测又复发了（#17832，修复后仍累积 213 对孤儿进程）。所以到今天为止，这个坑还在。

另外说句公道话，这不是 Codex 独有的毛病——Claude Code、agent-browser 的仓库里也有同类 issue，这是"agent + 浏览器工具"这个组合的共性缺陷。Codex 是本次的主角，因为它是我本机的肇事者，而且官方仓库的证据最密集。

30 秒复现

想亲眼看看的话，三条命令：

# ① 开一个会话（等价于 Codex 干活时在背后做的事）；命令立即返回
npx @playwright/cli -s=repro open about:blank

# ② 查进程：daemon 的父进程 PID=1，出生即孤儿，关终端、关 Codex 都不退出
ps -axo pid,ppid,command | grep -E 'cliDaemon|Chrome'

# ③ 一键清理，进程立刻归零
npx @playwright/cli close-all

第二步的输出里，你还能直接看到 --disable-background-timer-throttling 这个启动参数。

实测有效的三件事

三件事里最重要的是第三件。前两件都在"希望 AI 讲卫生"，只有定时清扫是把主动权拿回自己手里。

结论

Codex 用完浏览器不关，不是个案，也不是玄学。它是三件事叠出来的必然结果：常驻进程没有超时，清理规矩在搬运中丢失，而 AI 只对任务负责，不对你的电脑负责。

好消息是，用户这边一条清理命令、一条规矩、一个定时任务，就能根治。

如果你的电脑最近也莫名发烫，现在就去终端敲一句 close-all，看看后台是不是也躺着一堆没下班的浏览器。