你在 VS Code 里打开 Codex 侧边栏，看到的不是对话，而是这条提示：
Codex could not start
The extension could not start its user interface.自 2026 年 10 月 24 日起，最常见的原因是 openai.chatgpt 扩展的版本 bug，与你的账号或网络无关。从反馈来看，最有效的办法是回退到 26.1007.21434，并只对这个扩展关闭自动更新。目前还没有发布修复：2026 年 10 月 26 日查询 VS Marketplace 时，最新版本仍是 26.51021.22027。
VS Code 里的 "Codex could not start" 是什么意思？
意思是 Codex 进程已经启动，但界面（侧边栏 webview）在 30 秒内没有就绪。扩展放弃等待并弹出提示。问题出在界面，不在智能体。
确认方法：打开 VS Code 的 Output 面板（View > Output），选择 Codex 频道。在 issue #56691、#56655 和 #56660 中，日志的特征始终一样：后端初始化成功，30 秒后出现错误。
[CodexMcpConnection] Initialize received id=1
[CodexWebviewProvider] Webview renderer did not become ready
elapsedMs=30002 extensionVersion=26.1021.22027
reason=renderer_ready_timeout receivedWebviewMessage=false
role=sidebar stage=renderer timeoutMs=30000如果你的日志里有 renderer_ready_timeout，就是这种情况。如果错误不同，问题也不同，本文的步骤不适用。
哪些版本受影响？
issue 中反馈的是稳定版 26.1021.22027 和预发布版 26.51021.22027，二者都于 2026 年 10 月 23 日发布到 VS Marketplace。更早的 26.1007.21434 和 26.51007.21434 发布于 2026 年 10 月 9 日，对大多数人可用。
| 版本 | 渠道 | 反馈中的情况 |
|---|---|---|
| 26.1007.21434 | 稳定版 | 可用，回退时使用这个版本 |
| 26.51007.21434 | 预发布版 | 可用 |
| 26.1021.22027 | 稳定版 | 失败，出现 renderer_ready_timeout |
| 26.51021.22027 | 预发布版 | 失败，出现 renderer_ready_timeout |
反馈来自 Windows 10 和 11、Intel Mac、Linux、Remote SSH，甚至还有 Antigravity 加 WSL（issue #56617）。涉及 VS Code 的情况，版本是 1.142 和 1.143。
如何回退到可用的版本？
在终端运行下面的命令，然后重启 VS Code。issue #56691 和 #56660 的作者用的就是它，并且在他们的反馈中恢复了界面。
code --install-extension openai.chatgpt@26.1007.21434 --force如果想用界面操作：在 Extensions 标签页中右键点击 Codex，选择 Install Another Version（见 VS Code 文档），然后选择 26.1007.21434。
如何防止 VS Code 又把它更新回去？
不处理的话，自动更新会重新装上有问题的版本。在 Extensions 标签页中右键点击 Codex，取消勾选 Auto Update。这只对这个扩展生效，其他扩展照常更新。等 OpenAI 发布新版本后，再重新打开并检查日志。
注意：带 @版本号 的命令写法来自 issue 中的反馈，并不在 VS Code 扩展文档页面里。如果你的 code 命令不接受，请在界面里使用 Install Another Version。
如果旧版本也失败怎么办？
那就是别的触发原因，issue 中反馈了两条路径。都不是官方方案，只是发帖的人用下来有效。
1. 清除 webview 缓存。一位 Fedora 用户（VS Code 1.143.1）测得 webview 缓存已达 856 MB，包含 29 个扩展版本的文件，清除后无需回退就解决了问题（issue #56660）。在完全关闭 VS Code 的情况下，把 WebStorage 和 Service Worker 文件夹移到备份。Linux 在 ~/.config/Code，Windows 在 %APPDATA%\Code，macOS 在 ~/Library/Application Support/Code。
# Linux（先完全关闭 VS Code）
mv ~/.config/Code/WebStorage ~/.config/Code/WebStorage.bak
mv ~/.config/Code/"Service Worker" ~/.config/Code/"Service Worker.bak"之后第一次启动会慢一些（该反馈中约 24 秒），因为缓存要重新建立。由于是备份，把文件夹移回去就能撤销。
2. 把 VS Code 本身回退到 1.142。一位 Windows 11 用户记录到，在 VS Code 1.143.1 上，连 26.1007.21434 也开始超时，而在 1.142.0 上界面约 2 秒就能打开。另一条反馈在 Linux 上得到同样的结果。这说明 1.143.1 也是原因之一（issue #56655 和 #56691）。
为什么会这样？
OpenAI 尚未确认原因。issue #57026 和 #56655 中的反馈测量到了打包差异：26.1021.22027 的 webview 预加载 3,203 个文件（约 73 MB），而 26.51007.21434 约为 6 个 JavaScript 文件（约 20 MB）。要加载这么多内容，在较慢的机器或缓存很大时就会超过 30 秒的期限。这是用户的推测，不是 Codex 团队的诊断。
Codex 打不开期间能做什么？
如果你现在就要干活，不必等修复。Verboo Code 以 CLI 方式在终端运行，没有会卡死的 VS Code webview，而且 token 不限量。在 OpenAI 发布能正常打开的版本之前，可以先把 Codex 放一边。
