Codex VS Code 插件更新后为何出现高 CPU 占用和设备过热？

Codex VS Code 插件更新后出现持续高 CPU 和设备过热，历史案例显示主要原因不是模型正在“思考”，而是扩展界面、扩展宿主或 Git 元数据相关流程进入高频循环。受影响用户在扩展版本 26.325.31654 上观察到：打开或使用几轮 Codex 会话后，VS Code 辅助进程持续占用 CPU；关闭相关会话或面板后负载立即下降；回退到已知稳定版本后恢复。后续版本又出现过不同的循环信号，因此不能只凭一个错误字符串判断所有高占用。

先定位真正发热的进程

在 macOS 活动监视器或 VS Code 进程资源管理器中观察高占用进程。常见对象包括 Code Helper (Plugin)、Code Helper (Renderer)、Extension Host 和 codex app-server。如果扩展宿主占用明显而 app-server 很低，更接近插件状态或消息循环；若渲染进程高，则要关注 WebView、Diff 展示和工作区路径。

记录空闲时、打开 Codex 面板后、发送消息后、产生文件 Diff 后和关闭面板后的 CPU。用同一时间窗口对比，避免把索引、构建或系统更新误判为 Codex。

立即止损

1. 保存正在编辑的文件。
2. 关闭出现问题的 Codex 会话或侧边栏。
3. 若 CPU 不下降，运行 Developer: Reload Window。
4. 仍未恢复时完全退出 VS Code，并确认相关辅助进程结束。

持续高温时不要为了收集更长日志而让设备长时间满载。几分钟的可复现采样通常比数小时运行更有价值。

保存关键日志

打开“输出”面板并选择 Codex，同时运行 Developer: Open Logs Folder。历史报告中的强信号包括：

• thread-stream-state-changed 警告在短时间内重复。
• open-in-target not supported in extension 高频出现。
• local-environments is not supported in the extension 重复出现。
• worker_rpc_response_error 与 stable-metadata 大量累积。

单条警告不等于根因，关键是单位时间内的重复数量是否与 CPU 上升同步。提交日志前删除项目路径、账号信息、提示内容和其他敏感数据。

建立最小复现矩阵

变量	对照方法	说明
Codex 面板	打开与关闭	判断是否由可见 WebView 触发
会话长度	新会话与多轮会话	判断是否与会话状态累积有关
文件修改	纯问答与产生 Diff	判断是否由 Diff 流程触发
工作区根目录	Git 根与非 Git 父目录	判断元数据解析是否循环
扩展版本	当前版与已知稳定版	验证是否为版本回归

一些报告在三到五轮短消息后稳定复现，另一些在打开非 Git 工作区时触发。两类现象可能共享“缺少退避的重复请求”这一表面特征，但不应混为同一个根因。

优先升级并复测

先记录当前扩展版本，再从官方 Marketplace 安装当前稳定版，同时更新受支持的 VS Code。历史维护记录曾说明多个内部路由问题分批修复，这意味着仅升级到其中一个中间版本可能仍保留另一条循环路径。

升级后完全重启编辑器，按原复现步骤测试，并检查旧错误是否消失、是否出现新的高频日志。issue 被关闭或某位用户报告恢复，都不能代替当前环境的验收。

短期回退的正确用法

若当前版本稳定复现、业务又必须继续，可在扩展条目的更多操作菜单中选择“Install Another Version”，回退到自己已经验证过的较近版本。历史用户曾用 26.318.11754、26.325.21211 或更早构建恢复，但这些只是当时的对照点，不是今天的统一推荐版本。

回退后确认实际加载版本，重复相同测试，并暂时关闭该扩展的自动更新。设置明确的重新升级日期，因为旧版本会缺少功能、兼容性修复和安全更新。

不要修改已安装的扩展代码

讨论中有人直接修改压缩后的 out/extension.js，让不支持的内部路由返回空结果。这种做法会破坏扩展完整性，可能禁用本地环境或打开目标功能，也会在下一次更新时被覆盖。跨版本做文本替换还可能命中错误代码。

除非是在隔离测试机上为维护者验证假设，否则不应把第三方脚本或手工补丁作为生产环境修复。官方升级、受控回退和停用问题功能的风险更可控。

检查工作区是否位于 Git 根目录

后续报告发现，打开不含 .git 的父目录可能让渲染进程围绕稳定元数据持续请求，而直接打开实际 Git 仓库根目录后恢复。可以先用以下命令确认：

git rev-parse --show-toplevel
git status --short

若当前目录并非仓库的一部分，优先打开真正的项目根目录。不要仅为消除 CPU 占用而在任意目录运行 git init，这会改变工具行为并可能把无关文件纳入仓库范围。

排除其他扩展和渲染问题

使用临时 VS Code profile，只安装同一版本 Codex，再复现一次。若临时 profile 正常，逐个恢复其他扩展和用户设置；若同样异常，则版本、工作区和系统环境更可疑。

当其他 WebView 也高 CPU 时，应检查 GPU、显示驱动、Electron 渲染和远程桌面环境。Codex 面板关闭后仍由 Renderer 持续占用，也要同时采集 VS Code 开发者工具性能记录。

如何提交有效报告

1. 列出 VS Code、Codex 扩展、操作系统和芯片架构。
2. 指出具体高占用进程及 CPU 范围。
3. 写出从冷启动到触发的最短步骤。
4. 说明关闭面板、重载窗口和新建会话各自的结果。
5. 提供脱敏日志中重复事件的类型与计数。
6. 附上当前版和已知稳定版的 A/B 测试。

结论

更新后的高 CPU 与过热应按“进程定位、日志循环、触发条件、版本对照”四层排查。历史证据支持扩展内部请求或会话状态循环这一判断，但不同版本还可能涉及 Diff、内部路由和 Git 元数据等不同路径。

最稳妥的处理是先关闭面板止损并保存短日志，升级到当前版本复测；仍可复现时，短期回退自己验证过的版本并提交完整报告。不要长期停留在旧版，也不要把修改扩展包的第三方补丁当作常规解决方案。