2026 年 7 月 20 日，我曾经记录过一次 VS Code 中 Codex 面板持续加载、灰屏和白屏的问题。
当时已经确认 Codex CLI 可以正常使用，但 VS Code 中的 Codex Webview 无法正常加载。我先后尝试了清理缓存、重新安装扩展、回退 Codex 扩展版本等方式，问题依然存在，最终决定暂时停止排查，改用 Codex CLI 继续工作。
完整排查过程已经写在上一篇文章中：
《VS Code 中 Codex 面板持续加载与灰屏：从 Webview 资源错误排查到临时改用 CLI》（站内文章 19684）
到了 2026 年 7 月 29 日，我将 VS Code 从 1.129.1 升级到了 1.130.0。
重新打开 VS Code 后，之前无法正常使用的 Codex 面板竟然直接恢复了。
更值得注意的是：
此时我甚至还没有把 Codex 扩展更新到最新版本，当前使用的仍然是之前排查故障时回退的一周前版本。
这个结果让之前的问题范围变得更加清晰了。
一、7 月 20 日的问题暂时没有继续深挖
上一篇文章已经完整记录过之前的排查过程，因此这里不再重复展开。
当时最重要的几个结论是：
- Codex CLI 正常；
- VS Code 中 Codex 面板异常；
- 开发人员工具中出现过 Webview 资源加载失败；
- 清理多种 VS Code 缓存无效；
- 重新安装 Codex 扩展无效；
- 回退到之前正常使用过的旧版 Codex 扩展仍然无效。
因此，当时我没有继续去研究 Electron、Chromium、Webview 或 Linux 桌面环境，而是直接通过 Codex CLI 继续开发。
我的想法是，既然工作没有真正被阻塞，就先等 VS Code 或 Codex 后续更新以后再重新测试。
九天后，这个测试机会来了。
二、将 VS Code 从 1.129.1 升级到 1.130.0
7 月 29 日，我下载了新的 VS Code Debian 安装包：
code_1.130.0-1784734578_amd64.deb
电脑上原来安装的是 VS Code 1.129.1。
进入下载目录：
cd ~/下载
然后执行：
sudo apt install ./code_1.130.0-1784734578_amd64.deb
APT 正确识别出这是对现有 code 软件包进行升级：
注意，选中 'code' 而非 './code_1.130.0-1784734578_amd64.deb'
将被升级：
code
摘要：
升级：1，安装：0，卸载：0，不升级：81
随后完成覆盖升级：
准备解压 .../code_1.130.0-1784734578_amd64.deb ...
正在解压 code (1.130.0-1784734578) 并覆盖 (1.129.1-1784303641) ...
正在设置 code (1.130.0-1784734578) ...
也就是：
VS Code 1.129.1 → VS Code 1.130.0
整个升级过程没有出现错误。
三、重新打开 VS Code，Codex 已经恢复正常
升级完成以后，我重新打开 VS Code。
这一次进入 Codex 面板以后，之前的持续加载、灰色空白页面和白色空白页面都没有再次出现。
Codex 的历史任务可以正常显示，输入区域也已经恢复。
也就是说，在这台电脑上，实际状态已经从：
VS Code 1.129.1：Codex 面板异常
变成了：
VS Code 1.130.0：Codex 面板正常
而在这之间，我并没有重新进行之前那套复杂的缓存清理操作。
四、更关键的是：Codex 扩展还是之前回退的旧版本
恢复以后，我又查看了一下 Codex 扩展的版本。
结果发现一个很有意思的细节。
目前扩展市场已经提供更新的：
26.721.41059
但我当前实际安装的仍然是：
26.715.61943
也就是版本列表中显示的：
1 周前（当前）
这一点比单纯的“升级以后好了”更加有参考价值。
因为 7 月 20 日排查问题时，我曾经专门把 Codex 扩展回退到这个较早版本，希望通过旧版本恢复正常。
但当时：
VS Code 1.129.1 + 旧版 Codex 扩展，依然无法正常加载。
现在却变成：
VS Code 1.130.0 + 同样的旧版 Codex 扩展，可以正常加载。
换句话说，这一次 Codex 恢复正常，并不是因为我同时升级了 Codex 扩展。
截至截图时，我根本还没有安装最新 Codex 扩展。
真正明确发生的版本变化，是 VS Code 本体从 1.129.1 升级到了 1.130.0。
五、这进一步降低了 Codex 扩展版本本身是根因的可能性
上一篇排查时，我还无法完全排除 Codex 扩展自身的问题。
因为当时发生的是：
Codex 面板突然异常，而我又恰好在使用一个不断更新的 VS Code 扩展。
所以第一反应自然会怀疑扩展版本。
但后来已经发现，把扩展回退到一周前、此前实际正常使用过的版本，也没有效果。
而这一次又出现了新的证据：
Codex 扩展保持旧版本不变，仅升级 VS Code 本体以后，问题就消失了。
因此，现在看来，之前的问题仅由某个 Codex 扩展版本导致的可能性已经进一步降低。
相对更值得怀疑的方向包括：
- VS Code 1.129.1 本身；
- VS Code 所使用的 Electron / Chromium 运行环境；
- VS Code Webview 的资源加载机制；
- VS Code 1.129.1 与 Codex 扩展之间的某种兼容性问题。
不过，我仍然不会直接得出“VS Code 1.129.1 存在确定 Bug”这样的结论。
六、暂时不能证明根因就是 VS Code 1.129.1
目前我能确认的只是实际现象。
原来的组合是：
VS Code 1.129.1 + Codex 26.715.61943 → Codex 异常
现在的组合是：
VS Code 1.130.0 + Codex 26.715.61943 → Codex 正常
这是一个相当有价值的对照。
但是，要严格证明根因，还需要至少重新：
- 把 VS Code 降级到 1.129.1；
- 确认 Codex 是否再次灰屏；
- 再升级到 1.130.0；
- 确认问题是否再次消失。
如果还要继续定位具体代码原因，则需要进一步研究 VS Code 1.129.1 与 1.130.0 之间关于 Webview、Electron 或 Chromium 的变化。
但我没有准备继续这样做。
因为现在 Codex 已经恢复正常。
为了证明一个已经不影响使用的问题，再主动把正常环境降级回故障状态，实际价值并不高。
所以目前更准确的结论是：
在 Codex 扩展版本保持不变的情况下，将 VS Code 从 1.129.1 升级到 1.130.0 后，之前的 Codex 持续加载、灰屏和白屏问题消失了。这进一步说明问题很可能与 VS Code 本体、Webview 运行环境或两者之间的兼容性有关，但目前还无法确定唯一根因。
七、之前选择停止排查，现在看来是正确的
7 月 20 日的时候，我其实已经花了不少时间处理这个问题。
如果当时一定要求把问题追到最底层，后面可能还需要继续研究：
VS Code、Electron、Chromium、Webview、Service Worker、Linux 桌面环境以及 Codex 扩展之间的关系。
但与此同时，Codex CLI 一直可以正常使用。
所以我最终选择：
停止排查 VS Code 面板 → 使用 Codex CLI → 继续推进项目 → 等待后续软件更新。
事实证明，这个决定至少没有影响后面的开发工作。
过去这几天，我仍然可以在终端中使用 Codex 继续处理 wordpress-ai-excerpt-backfill、WordPress 历史文章迁移等项目。
九天以后，正常升级了一次 VS Code，问题自己消失了。
有些开发工具问题确实没有必要在第一次遇到的时候就必须追到根因。
只要存在可靠的替代方案，让工作继续推进通常更加重要。
八、以后再遇到类似问题，我会先检查 VS Code 本体版本
经过这次实际验证以后，如果以后再次遇到：
Codex CLI 正常，但 VS Code 中 Codex 持续加载、灰屏或白屏
我会把检查 VS Code 更新放到比较靠前的位置。
特别是在确认：
- Codex CLI 正常；
- 账号正常；
- 扩展已经正确安装；
- 问题集中在 VS Code Webview；
以后，与其立即进行大量缓存清理或者反复切换扩展版本，可以先看看 VS Code 本体有没有新的稳定版本。
至少这一次，最终真正起作用的变化不是更新 Codex 扩展，而是：
VS Code 1.129.1 → 1.130.0
当然，这并不意味着以后所有 Codex 灰屏问题都可以通过升级 VS Code 解决。
如果升级以后问题仍然存在，再根据开发人员工具中的 Console、Network 和 Webview 错误继续分析即可。
九、Codex CLI 仍然会继续保留
现在 VS Code 中的 Codex 已经恢复，我会重新优先使用 VS Code 中的 Codex 面板。
原因很简单：在需要查看项目代码、阅读较长执行结果以及复制内容到 ChatGPT 继续分析时，图形界面还是更加方便。
不过，经过这次故障以后，Codex CLI 已经证明自己是一个很可靠的备用入口。
所以以后我会保留两种使用方式：
VS Code Codex 作为主要入口，Codex CLI 作为备用以及终端场景下的入口。
即使以后 VS Code 面板再次因为某个版本问题暂时不可用，只要 CLI 正常，就不需要让开发工作停下来。
十、总结
7 月 20 日，VS Code 中的 Codex 突然出现持续加载、灰屏和白屏。
经过排查以后，我已经确认 Codex CLI 正常，也尝试过清理缓存、重新安装扩展和回退 Codex 版本，但始终没有解决。
于是暂时停止排查，改用 CLI。
到了 7 月 29 日，我将：
VS Code 1.129.1 升级到 VS Code 1.130.0。
重新启动以后，Codex 面板恢复正常。
而进一步检查又发现：
Codex 扩展其实还是之前回退的一周前版本 26.715.61943，最新的 26.721.41059 甚至还没有安装。
因此，这一次实际验证比单纯“升级之后好了”更有意义。
在 Codex 扩展不变的情况下：
VS Code 1.129.1 时异常，VS Code 1.130.0 时恢复正常。
虽然这仍然不足以证明具体根因，但已经进一步把怀疑方向指向 VS Code 本体、Webview 运行环境或者 VS Code 与 Codex 扩展之间的兼容性。
现在既然已经恢复，我也不准备再降级复现。
对于我来说，这次问题最有价值的经验反而是：
当开发工具出现比较底层的兼容性故障，但又存在可靠替代方案时，可以先保证工作继续进行。等上游软件更新以后再回来验证，有时一次正常升级，就比继续几个小时甚至几天的本地排查更有效。
7 月 20 日，我暂时放弃了 VS Code 中的 Codex。
7 月 29 日，我没有修改 Codex 扩展，只是升级了 VS Code。
然后，Codex 就恢复了。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复