最近我在 macOS 上使用 VS Code 里的 Codex 插件时，遇到一个很烦的问题：明明没有做什么重活，风扇却开始转，电池掉得飞快，活动监视器里还能看到一个或两个 Code Helper (Renderer) 长时间占着很高的 CPU。乍一看像是 VS Code 本体抽风，但继续排查后会发现，问题更像是插件侧的 Webview 渲染开销异常。
这篇文章整理一下现象、排查方法，以及目前比较靠谱的解决思路。文末附上社区 issue 和相关分析链接。
问题现象
常见表现一般有这几个：
- 打开 VS Code 后，机器明显发热，风扇转速升高
- 没有编译、没有跑测试，CPU 依然持续居高不下
- 活动监视器里
Code Helper (Renderer)占用异常，有时能到 100% 以上 - 使用 Codex 对话、工具调用或流式输出时，卡顿会更明显
如果你也遇到类似情况，先别急着怪项目太大。这个问题有一个很重要的特征：即使只是打开 Codex 侧边栏，或者让它停在空闲状态，CPU 也可能不正常地高。
怎么确认是不是 Codex 插件导致的
VS Code 官方给了几种很实用的排查办法，建议按下面顺序来：
- 打开
Help > Open Process Explorer
看看高 CPU 的到底是 Renderer、Extension Host，还是别的进程。
- 在终端执行
code --status
这个命令会输出当前 VS Code 的进程状态，适合截图或留档。
- 执行
Developer: Show Running Extensions
看正在运行的扩展里，是否是 Codex 相关扩展最活跃。
- 执行
Help: Start Extension Bisect
如果你不确定是不是 Codex，也可以用 VS Code 自带的二分排查功能。它会自动帮你缩小到具体扩展。
- 直接用
code --disable-extensions启动一次
如果禁用全部扩展后 CPU 立刻恢复正常，那基本就能确定不是 VS Code 核心本身的问题，而是扩展引起的。
社区目前怀疑的根因
这一部分我想说得谨慎一点：下面这些更像是结合社区 issue 和逆向分析得到的推测，不是 OpenAI 官方已经确认的结论。
从社区讨论和后续的 bundle 分析来看，Codex 插件高 CPU 大概率和它的 Webview 前端实现有关，主要集中在下面几类问题：
背景动画持续运行
有分析提到，插件 Webview 里存在持续刷新的动画效果。即使界面不可见，动画循环也可能没有真正停下来，导致渲染线程一直忙。过于激进的轮询
某些工具调用状态更新，疑似存在极短周期的轮询逻辑。如果轮询间隔接近0ms，就会导致频繁重渲染。流式输出期间的 DOM 观察和布局计算过多
当 AI 回复不断流式追加内容时，如果页面里还有全局的MutationObserver、命中测试或布局查询，就很容易把Renderer线程拖高。
把这些因素叠在一起，就会出现一种很典型的现象：空闲时已经不省电，一旦开始对话、调用工具或持续输出，CPU 直接飙升。
我比较推荐的解决办法
如果你只是想先把机器救回来，优先按下面的顺序处理。
1. 先升级 VS Code 和 Codex 插件
这是最优先、也最稳妥的一步。因为这类问题往往出在扩展实现细节里，后续版本有机会直接修掉。
建议至少做这两件事：
- 升到最新版 VS Code
- 升到最新版 Codex 插件
升级后记得执行一次 Developer: Reload Window，不要只关标签页。
2. 临时不用时，直接关闭 Codex 面板或禁用扩展
如果你的工作流不是全天都依赖它，那最有效的临时止血方案其实很朴素：
- 不用 Codex 时直接关闭其侧边栏或聊天面板
- 问题严重时直接
Disable扩展 - 只在需要时重新启用
这听起来不优雅，但比让 Renderer 长时间烧 CPU 更实际。
3. 用 VS Code 自带工具确认是否就是扩展问题
如果你准备提 issue，或者想确认“不是我的错觉”，建议把这几样信息留好：
code --status输出Help > Open Process Explorer截图Developer: Show Running Extensions结果- 必要时录一份 renderer / extension host 的 CPU profile
这样一来，后续无论是自己继续排查，还是反馈给插件维护者，证据都会更完整。
4. 实在着急，就先回退或停用这类 AI 扩展
如果你当前版本稳定复现，而升级也没用，那与其硬扛，不如：
- 暂时回退到之前正常的插件版本
- 改用 Codex CLI
- 或者先用网页端完成高频对话工作
很多时候，真正影响体验的不是“高一点 CPU”，而是它把整台机器拖卡、拖热、拖到续航崩掉。
5. 进阶 workaround：手动修改扩展 bundle
社区里已经有人尝试直接修改扩展打包后的前端文件，比如：
- 下调背景动画的粒子数量和帧率
- 把可疑的
setInterval(0)改成更保守的轮询间隔 - 缩小
MutationObserver的监听范围
这种办法的优点是见效快，缺点也很明显：
- 它不是官方修复
- 扩展一更新就会被覆盖
- 改坏了以后，插件可能直接打不开
所以我的建议是：把它当成临时自救手段，不要当成长期方案。
如果你真的要改，至少先备份原文件，再在改完后执行一次 Developer: Reload Window。
一个比较实用的判断标准
如果你看到的是 Code Helper (Renderer) 很高，而不是 tsserver、ripgrep、Extension Host 在高，那么这类问题通常更像是：
- Webview 页面本身在高频刷新
- 动画、轮询、布局计算过多
- 和你项目代码本身关系没那么大
换句话说，这不是“你的仓库太大”的经典症状，而更像“扩展 UI 自己在忙个不停”。
结论
遇到这类问题时，最怕的是一上来就怀疑项目、怀疑 macOS、怀疑硬件，结果越查越偏。更高效的做法是先把责任边界划清楚：先看 Renderer 和 Extension Host，再用 Extension Bisect 验证扩展影响，最后决定是升级、回退、禁用，还是临时 patch。
至少从目前社区反馈来看，Codex 插件在 macOS 上出现高 CPU 占用，并不是个别现象。如果你的机器在打开 VS Code 后莫名发热、掉电、卡顿，这个方向值得优先排查。