Codex could not start 报错：VS Code 插件按环境排查，哪些已修复

在 VS Code 里点开 Codex 面板，转圈约 30 秒后变成 "Codex could not start / The extension could not start its user interface"。这个页面是插件的统一超时提示，不对应某一个具体 bug：插件给面板里的界面 30 秒时间回报"已就绪"，没等到就换成这个报错页。日志里多数时候能看到后台的 codex app-server 已经正常启动，卡住的只是界面。

所以同一句报错背后有好几种原因，做法也不同。先按这两条判断：

• 你在 WSL 窗口里，问题从 10 月 13 日前后 VS Code 自动更新之后开始：这是 VS Code 1.141.1 的问题，不是 Codex 插件的问题。微软已在 2026 年 10 月 14 日发布的 VS Code 1.141.2 中修复，升级 VS Code 即可。回退 Codex 插件版本在这种情况下没有用。
• 其他情况：打开 Codex.log 和 Webview 开发者工具，按下表找到自己属于哪一支。

下面的原因与修复来自 GitHub 上的问题报告、OpenAI Codex 团队成员在 issue 里的回复，以及 VS Code 仓库的修复提交。这些情况都没有在 Windows + WSL、Dev Container 或 Remote-SSH 上实际复现过；社区办法逐条注明了出处和已知效果，不能当作保证有效的修复。

Codex could not start 的意思：后台已启动，界面 30 秒没回报就绪

Codex 插件分两部分：后台的 codex app-server 负责和模型、账号打交道；侧边栏或编辑器标签里看到的是一个嵌在 VS Code 里的网页界面（Webview）。界面加载完要给插件发一个"就绪"信号，插件只等 30 秒。有用户在 GitHub 上贴出过插件代码里写死的 30 秒计时，以及超时后在 Codex.log 里留下的这一行：

[CodexMcpConnection] Spawning codex app-server
[CodexMcpConnection] Initialize received id=1
[error] [CodexWebviewProvider] Webview renderer did not become ready elapsedMs=30003 extensionVersion=26.1007.21434 reason=renderer_ready_timeout receivedWebviewMessage=false role=sidebar stage=renderer timeoutMs=30000

前两行说明后台已经启动并完成初始化；第三行说明界面在 30 秒里一次都没回话（receivedWebviewMessage=false）。role=sidebar 是侧边栏，role=panel 是编辑器里打开的对话标签。

界面为什么没回话，才是要找的原因：可能是界面的脚本文件根本没加载出来（VS Code 1.141.1 的 WSL 问题），可能是界面在等一个永远不返回的网络请求（代理挂起），也可能是远程环境里的兼容问题。报错页本身不区分这些，Codex.log 和开发者工具才能区分。

8 月看到的是另一句正文 "The extension couldn't load its resources."，那是 26.803.x 版本的同一个超时页，后面单独说。OpenAI 的 Codex 故障排查文档截至 10 月 15 日没有收录这个报错。

先看 Codex.log 和 Webview 开发者工具里的那一行

两处日志各管一段，最好都看。

Codex.log：按 Ctrl+Shift+P（macOS 是 Cmd+Shift+P）打开命令面板，输入 Developer: Open Extension Logs Folder，在打开的文件夹里进入 openai.chatgpt，打开 Codex.log。中文界面里直接输入这个英文命令名也能搜到。Windows 上的完整路径类似 C:\Users\用户名\AppData\Roaming\Code\logs\日期时间\window1\exthost\openai.chatgpt\Codex.log；同样的内容也能在"输出"面板里切到 Codex 频道查看。Remote-SSH 和 WSL 窗口里插件跑在远端，远端日志在 ~/.vscode-server/data/logs/ 下。

看最后一次启动的几行：

• 有 Spawning codex app-server 和 Initialize received id=1，随后 30 秒出现 renderer_ready_timeout：后台正常，问题在界面这一侧，继续看开发者工具。
• 有 Statsig: error while bootstrapping，却始终没有 [chatgpt-account-lookup] completed 和 [startup][renderer] app routes mounted：界面在等账号请求，属于网络和代理这一支。
• 出现 PendingMigrationError: navigator is now a global in nodejs：远程扩展进程的兼容问题，常见于 Remote-SSH 和 Dev Container。

Webview 开发者工具：命令面板里运行 Developer: Open Webview Developer Tools，看 Console 和 Network 两个标签。界面在建立日志通道之前出的错（脚本加载失败、文件返回 401）不会写进 Codex.log，只能在这里看到。WSL 下的 1.141.1 问题就是这样：Codex.log 里只有超时，开发者工具里才有一排 401。

版本号：VS Code 版本在"帮助 > 关于"里。Codex 插件的版本在扩展页的 Codex 详情里，也可以在终端运行：

code --list-extensions --show-versions

远程窗口里插件装在远端，目录名本身带着版本和平台，例如 ~/.vscode-server/extensions/openai.chatgpt-26.1007.21434-linux-x64。截至 10 月 15 日，VS Code 扩展市场上 Codex 插件的稳定版是 26.1007.21434（10 月 9 日发布）；版本号第二段以 5 开头的是预发布版，例如 26.51007.21434。插件几乎每周更新几次，以你自己扩展页里显示的为准。

WSL 窗口 10 月 13 日起报错：VS Code 1.141.1 的问题，升到 1.141.2

如果你同时满足这几条，基本就是这一支：

• 用的是 Windows 上的 VS Code 连 WSL，窗口左下角显示 WSL: Ubuntu-24.04 这类名字，名字里有大写字母；
• VS Code 版本是 1.141.1（10 月 13 日前后自动更新上来的）；
• Webview 开发者工具里，~/.vscode-server/extensions/openai.chatgpt-26.1007.21434-linux-x64/webview/assets/ 下的 JS 和 CSS 文件返回 401；
• 终端里运行 codex login status 显示已登录，在 Windows 本地窗口里 Codex 能正常用。

原因在 VS Code，不在 Codex。根据 VS Code 仓库的修复 PR #341508，1.141.1 里的一处改动（提交 b0240f4c8e，1.141.0 里没有）会把远程窗口名字和资源请求里的名字做大小写严格比较，而浏览器会把资源地址里的名字转成小写。WSL: Ubuntu-24.04 对应的 wsl+Ubuntu-24.04 与 wsl+ubuntu-24.04 对不上，资源请求就被拒绝，返回 401。受影响的是所有插件的 Webview：Markdown 预览、Claude Code 面板也一样空白，Codex 只是其中之一。

微软在 10 月 14 日把修复合入 1.141 的发布分支，问题单 #341396 已标记为已验证。1.141.1 到 1.141.2 之间只有这一个修复和版本号变更。按 GitHub 发布记录，1.141.2 于 10 月 14 日发布，同一天发布的 1.142.0 也包含这个修复。截至 10 月 15 日，Codex 的 issue 里还没有用户回报"升级 1.141.2 后恢复"，但修复针对的正是所有 Webview 的 401。

这一支怎么修：升级 VS Code，不要回退插件

1. 在 Windows 的 VS Code 里打开"帮助 > 检查更新"，升级到 1.141.2 或更高，重启后重新连接 WSL。
2. 再打开 Codex 面板。如果仍然报错，回到开发者工具看是否还有 401：没有 401 了，说明这一支已经解决，剩下的问题属于别的分支，按上面的表格继续查。

openai/codex #53738 里有一位用户 10 月 14 日贴出了测试结果，正好说明为什么回退插件没用：

另一位用户在 #53840 里列出的无效操作还包括：重装插件、重装 WSL 里的 VS Code Server、清理 Webview 缓存、新建 VS Code 配置文件、重启 VS Code 和 WSL。这些都不碰 VS Code 本身的版本，所以都无效。

暂时不能升级 VS Code 时：用小写名字打开 WSL 窗口

1.141.2 发布之前，社区在 #53738 和 #53840 里用过一个绕过办法：从 Windows 的 PowerShell 用全小写的名字打开 WSL 文件夹，窗口名字和资源请求里的名字一致，401 就消失了。

先在 PowerShell 里运行 wsl -l -v 看自己的发行版名称，再把它改成全小写，例如 Ubuntu-24.04 写成 ubuntu-24.04：

code --new-window --remote wsl+ubuntu-24.04 /home/你的用户名/你的项目目录

已经在 WSL 终端里的话，可以让 PowerShell 代为打开当前目录：

powershell.exe -NoProfile -Command "code --new-window --remote wsl+ubuntu-24.04 '$PWD'"

注意在 Ubuntu 终端里直接运行 code . 会重新生成带大写字母的名字，问题照旧。发行版就叫 Ubuntu 的，用户在 #53738 里写成 wsl+ubuntu 成功打开。小写名字要和你自己的发行版名称一致，这是按问题原因推出来的，没有逐个发行版验证。升级到 1.141.2 之后，按原理不再需要这个办法。

还有两条退路：

• 把 VS Code 退回 1.141.0。上表第三行就是这样恢复的；但 1.141.2 已经发布，直接升级更省事。
• 不用 WSL 远程窗口，在 Windows 本地窗口里打开设置项 chatgpt.runCodexInWindowsSubsystemForLinux。OpenAI 的 Codex 插件设置文档说明这个设置让 Codex 在 WSL 里运行（仅限 Windows，修改后 VS Code 会重载）。#53840 的报告者用这个方式让 Codex 在 WSL2 里正常执行命令。它不修复 1.141.1 的问题，只是绕开了 WSL 远程窗口。

按修复说明，受影响的是名字里带大写字母的任何远程窗口，不只是 WSL。判断是不是这一支，以开发者工具里有没有 webview/assets/ 的 401 为准。Cursor、Windsurf 用各自的版本号，是否受影响要看它们是否合入了 1.141.1 的那次改动，判断方法同样是看开发者工具里有没有这类 401。

开梯子能好、开了反而卡：代理和 VPN 怎么影响启动

有人开了梯子就好了，也有人恰恰是开着代理才报错，两者并不矛盾。在 #37521 里，一位用户在插件 26.803.41515 上控制网络条件，测出了三种结果：

关键在于请求是"很快失败"还是"一直挂着"。按他对插件代码的分析，界面要等账号信息查完才发"就绪"信号，而这个账号请求没有设超时，挂着就一直等，直到 30 秒的计时把界面换成报错页。直连时如果连接被直接拒绝，界面至少能以降级模式打开；如果连接一直没有回应，结果和代理挂起一样。这一点是按上面的机制推断的，适合解释为什么有人"开梯子就好了"：换成能用的代理后，请求能正常返回。

OpenAI Codex 团队成员 8 月 13 日在 #37458 里说明，修复启动计时的版本不解决这种情况："如果是底层的网络或认证问题让初始化无法完成，更新后很可能仍然如此"，建议先检查代理和 VPN 设置再提交问题报告。挂起的账号请求在 #37521 里单独跟踪，截至 10 月 15 日仍是开放状态；也就是说，上表第三行在新版插件上仍可能出现，表现是报错页或一直转圈。

代理这一支怎么处理

1. 先确认是这一支：Codex.log 里有 Statsig: error while bootstrapping，之后一直没有 [chatgpt-account-lookup] completed 和 [startup][renderer] app routes mounted。
2. 对比两种状态：把代理彻底关掉启动一次，再换一个确定能访问 chatgpt.com 的节点启动一次。关掉代理能以降级模式打开，换节点后正常，说明原来的代理在挂住请求。
3. 检查 VS Code 的代理设置：在设置里搜 http.proxySupport。一位使用 Clash（7890 端口）的用户在 #37458 里说，这个值之前被改成了 off，改回 on 后插件能走系统代理，问题消失。
4. 注意扩展进程不一定读环境变量：#37521 里另一位用户发现，扩展进程发出的请求没有使用 Codex 配置里的 network_proxy，Node 的 fetch 默认也不读取 HTTP_PROXY、HTTPS_PROXY。只在终端里设置代理环境变量，插件可能完全不受影响。按这个机制，让代理软件在系统层面接管流量（例如 TUN 或虚拟网卡模式），不依赖插件是否读取代理设置；这一点在 issue 里没有人验证过。
5. Remote-SSH 和 WSL 的远端：插件跑在远端，走的是远端的网络。远端继承了一个会挂住请求的代理时，#37521 的复现步骤就是这种情况。

另一位用户在 #38088 里测过 8 月的 26.803.41515：开着系统代理时界面要 26.7 秒、30.1 秒，有一次约 3.5 分钟才加载完，不开代理约 9 秒。8 月的修复之后，这种慢但最终能成功的加载不应再被报错页打断；真正挂住不返回的请求仍会卡住。

Remote-SSH 一直加载或报错：社区办法与各自效果

通过 Remote-SSH 连服务器时，Codex 面板一直转圈或 30 秒后报错，而终端里的 codex 能用。这一支在 #26951 里从 2026 年 6 月一直开放到现在，没有官方修复。下面是评论区报告过的办法，每一条都只有一位或几位用户验证过，有的对别人无效：

• 兼容设置：日志里有 PendingMigrationError: navigator is now a global in nodejs 时，在本地和远程设置里都加上 "extensions.supportNodeGlobalNavigator": true。多位用户用它消掉了这条错误；但发帖者本人加上后界面仍然卡住，另一位在 DGX Spark 上的用户也一样。

• 本地设置加两项后完全重启：一位 Windows 连 Ubuntu 的用户 10 月 14 日报告，升级到 VS Code 1.141.2 没有用；在本地用户设置（JSON）里加上下面两项，关掉所有 VS Code 窗口后重新连接，Codex 恢复。他是两项一起加的，说不清哪一项起作用。

  json复制

  {
    "extensions.supportNodeGlobalNavigator": true,
    "http.electronFetch": true
  }

• 清理 VS Code 的网页缓存：一位本地安装（非 Remote-SSH）的用户发现，临时新建的 VS Code 配置文件里 Codex 能打开，于是关掉 VS Code，把 Partitions、Service Worker、Cache 等缓存目录改名备份，重启了大约三次后才稳定加载。

• 关闭一个功能开关：用远端插件自带的 codex 运行 codex features disable remote_plugin，一位用户说立刻恢复；另一位照做后，重载窗口又卡住了。

• 回退插件并关掉自动更新：6 月有用户这样恢复，之后升级回新版也正常。这和插件版本有关时才有用。

还有两个方向值得排除：服务器上的 Codex 账号是否已经登录，没有浏览器的服务器怎么登录见 Codex 服务器无浏览器登录：设备码、SSH 转发、auth.json 怎么选；远端是否残留旧的 codex app-server 进程，一位本地 Linux 用户清掉残留进程和锁文件后有所改善，但问题仍会复发。Windows 本地的残留进程怎么判断，见 Codex Windows 后台进程怎么处理：哪些该保留，哪些可以结束。

以上都无效时，先用终端里的 Codex CLI 干活，把日志补到 #26951。

Dev Container 里报错：重装无效，#40532 尚无官方答复

在 Dev Container 里，#40532 的报告者（插件 26.818.61809，VS Code 1.134.0，Windows 连 Ubuntu 22.04 容器）看到的是同样的 renderer_ready_timeout：后台已初始化，界面卡在启动阶段的一个等待里。重装插件、删掉旧的插件和 VS Code Server 版本都没有用。他通过直接修改插件打包后的脚本让界面恢复，但每次插件更新都会被覆盖，不能当作修复。截至 10 月 15 日，这个 issue 没有 OpenAI 的回复。

在 #26951 里，另一位用户对比了同时运行的两个容器：加了 extensions.supportNodeGlobalNavigator 的那个能打开 Codex，没加的那个超时。远程设置是每个容器单独保存的，所以他建议写进 devcontainer.json，让每次重建容器都带上：

"customizations": {
  "vscode": {
    "settings": {
      "extensions.supportNodeGlobalNavigator": true
    }
  }
}

这是单个用户的对比结果，适合先看日志里有没有 PendingMigrationError，有的话再试。

只有部分 Codex 标签页报错：同时开了多个对话标签

如果你在本地窗口里把 Codex 对话开在编辑器标签里，开了好几个，结果有的能用、有的显示报错页，情况和 #43080 一致。报告者在 Windows 本地的 VS Code 1.136.1、插件 26.901.22334 上开了三个 Codex 对话标签，一个正常加载，另外两个几乎同时超时，日志里是 role=panel 的 renderer_ready_timeout。他没法确定上限是几个，这个 issue 也没有官方答复。

可以先关掉多余的 Codex 标签，只留一个，再在命令面板运行 Developer: Reload Window。这是按报告现象推出的做法，没有被验证过。

旧报错 couldn't load its resources：插件 26.810.41047 已修复

8 月初，插件 26.803.x 上大量出现 "Codex could not start / The extension couldn't load its resources."，日志里是 Webview did not finish starting。当时的问题是启动计时：界面加载只要超过 30 秒，哪怕马上就要加载完，也会被换成报错页。

OpenAI 在 8 月 13 日发布的 26.810.41047（预发布版 26.5810.41047）修复了这个问题，见 #37458 中 Codex 团队成员的发布说明。8 月时回退到 26.727.x 能解决，就是因为问题出在 26.803.x 这个版本上。现在的稳定版早已超过 26.810，如果你还停在 26.803.x，直接更新插件即可；更新后仍然卡住，报错正文会变成 "could not start its user interface"，按上面的分支继续查。

回退 Codex 插件版本：什么时候有用，怎么回退

回退插件只在问题出在插件某个版本上时有用，比如 8 月的 26.803.x，或者某次更新后才出现、且换回上一版就好的情况。VS Code 1.141.1 的 WSL 问题出在 VS Code，回退插件无效；Dev Container 那一支，重装和清掉旧版本也都没用。回退之前，先用上面的日志和开发者工具排除这两支。

确实要回退时：

1. 在扩展页打开 Codex，点"卸载"旁边的下拉箭头，选"安装特定版本"（较新的界面叫"安装另一个版本"），选上一个版本，按提示重载窗口。也可以用命令，例如：

   bash复制

   code --install-extension openai.chatgpt@26.1002.51308 --force

2. 在 Codex 详情页的齿轮菜单里取消"自动更新"，否则下次重启又会被更新回去。

3. WSL、Remote-SSH 窗口里，插件装在远端，回退要在远程窗口里操作，装上的是 linux-x64 之类的远端版本。

4. 用 code --list-extensions --show-versions 或远端扩展目录名确认版本真的换了，再重新测试。

问题解决后，记得择机把自动更新打开，不然会错过后续修复。

修好之前用 Codex CLI，并把证据带到对应 issue

在 #53738、#53840 和 #26951 这些报告里，面板打不开时终端里的 codex 命令照常能用，WSL 和 Remote-SSH 都是如此。等修复期间可以直接在 VS Code 的终端里运行 Codex CLI；还没装的话，见 Codex CLI 安装与配置：Windows、macOS、Linux 一次跑通。CLI 和插件共用登录和网络，所以如果你属于代理那一支，CLI 也可能受影响，这一点要分开看。

要在 GitHub 上跟进，先找到对应的 issue（见开头的表格），在评论里补这些信息，比只说"我也是"更有用：

• VS Code 版本（"帮助 > 关于"里的整段信息）和 Codex 插件版本，注明是稳定版还是预发布版、哪个平台（例如 linux-x64）；
• 环境：本地窗口、WSL（窗口左下角的名字）、Remote-SSH、Dev Container；
• Codex.log 里从 Activating Codex extension 到 renderer_ready_timeout 的几行；
• Webview 开发者工具 Console 和 Network 里的报错，比如 401 的文件路径；
• 已经试过、无效的做法。

贴之前去掉账号、主机名、项目路径和令牌。

Codex 插件无法启动的常见问题

终端里的 Codex CLI 能用，VS Code 插件就是打不开，为什么？

CLI 和插件面板走的是两条路：CLI 直接在终端运行，插件面板要靠 VS Code 的 Webview 加载界面，还要等账号请求返回。1.141.1 的 401 只影响 Webview，所以 CLI 正常；代理挂住账号请求、远程扩展进程的兼容问题也都发生在插件这一侧。CLI 能用说明登录和后台大体没问题，排查重点放在界面和网络上。

更新了 Codex 插件，还是显示 Codex could not start，怎么办？

更新插件只解决插件自身版本的问题，比如 8 月的 26.803.x。WSL 窗口在 VS Code 1.141.1 上要升级的是 VS Code；代理挂住请求时，OpenAI 已说明更新插件后很可能仍然卡住。先看 Codex.log 和开发者工具，确认属于哪一支。

Cursor 里的 Codex 插件也报 Codex could not start，做法一样吗？

报错页和日志看法一样，代理、多标签这些分支同样适用。VS Code 1.141.1 那一支取决于编辑器是否带有那次改动，Cursor 有自己的版本号，以开发者工具里有没有 webview/assets/ 的 401 为准。Cursor 中插件的安装和登录见 在 Cursor 中使用 Codex：安装、登录与第一次可审查改动。

Codex 面板打开后报 401、429，和这个报错有关吗？

没有关系。能打开面板说明启动已经完成，之后的 401、429 和断流是请求层面的问题，排查方法见 Codex 401、429 与 Stream Disconnected：先找出失败的那一层。用 API Key 或第三方模型时的配置和首次验证，见 Codex VS Code 教程：API Key、第三方模型与首次验证。