# Codex could not start 报错：VS Code 插件按环境排查，哪些已修复 > Codex could not start：10 月 13 日起 WSL 窗口出现的，升级 VS Code 1.141.2 即可，回退插件无效；其他情况按日志分环境排查。 - URL: https://blog.laozhang.ai/zh/posts/codex-could-not-start-vscode - Published: 2026-10-15 - Updated: 2026-10-15 - Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about) - Topic: 故障排查 - Tags: Codex, VS Code, Codex 插件, WSL, Remote-SSH, 报错排查 --- 在 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 开发者工具，按下表找到自己属于哪一支。 | 你的环境 | 日志或开发者工具里的线索 | 状态（截至 2026 年 10 月 15 日） | 先做什么 | | --- | --- | --- | --- | | WSL 远程窗口，VS Code 1.141.1 | 开发者工具里 `webview/assets/` 下的 JS、CSS 返回 401 | 已修复：VS Code 1.141.2、1.142.0 | 升级 VS Code；回退插件无效 | | 开着代理或 VPN（梯子），或直连 | 有 `Statsig` 报错，始终没有 `[chatgpt-account-lookup] completed` | 未修复，[openai/codex #37521](https://github.com/openai/codex/issues/37521) 仍开放 | 让代理真正可用，或彻底关掉对比 | | Remote-SSH 远程服务器 | 一直转圈或 30 秒报错，常伴有 `PendingMigrationError` | 未修复，[#26951](https://github.com/openai/codex/issues/26951) 仍开放 | 逐项试社区办法，效果因人而异 | | Dev Container | `renderer_ready_timeout`，重装插件无效 | 未修复，[#40532](https://github.com/openai/codex/issues/40532) 无官方答复 | 在容器设置里加兼容项（社区办法） | | 本地窗口同时开了几个 Codex 对话标签 | `role=panel` 超时，只有部分标签能打开 | 未修复，[#43080](https://github.com/openai/codex/issues/43080) 无官方答复 | 关掉多余标签后重载窗口 | | 插件 26.803.x，报错正文是 "couldn't load its resources" | `Webview did not finish starting` | 已修复：插件 26.810.41047 | 更新插件 | 下面的原因与修复来自 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` 里留下的这一行： ```text [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` 是编辑器里打开的对话标签。 ![Codex.log 三行日志的时间线：后台进程启动、后台初始化完成都正常，30 秒后界面超时换成报错页；下方列出脚本没加载、请求挂起、远程兼容三种常见原因](https://blog.laozhang.ai/posts/zh/codex-could-not-start-vscode/img/startup-log-timeline.webp) 界面为什么没回话，才是要找的原因：可能是界面的脚本文件根本没加载出来（VS Code 1.141.1 的 WSL 问题），可能是界面在等一个永远不返回的网络请求（代理挂起），也可能是远程环境里的兼容问题。报错页本身不区分这些，`Codex.log` 和开发者工具才能区分。 8 月看到的是另一句正文 "The extension couldn't load its resources."，那是 26.803.x 版本的同一个超时页，后面单独说。OpenAI 的 [Codex 故障排查文档](https://developers.openai.com/codex/reference/troubleshooting)截至 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 详情里，也可以在终端运行： ```bash 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](https://github.com/microsoft/vscode/pull/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](https://github.com/microsoft/vscode/issues/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](https://github.com/openai/codex/issues/53738) 里有一位用户 10 月 14 日贴出了测试结果，正好说明为什么回退插件没用： | VS Code | Codex 插件（装在 WSL 里） | 结果 | | --- | --- | --- | | 1.141.1 | 26.1007.21434 | 界面启动失败，反复 30 秒超时 | | 1.141.1 | 26.1002.51308 | 回退插件并重载窗口后，同样失败 | | 1.141.0 | 26.1002.51308 | 回退 VS Code 后，Codex 恢复正常 | ![WSL 窗口名字 wsl+Ubuntu-24.04 与浏览器转成小写的 wsl+ubuntu-24.04 在 VS Code 1.141.1 的严格比较下对不上，返回 401；下方三行版本测试显示回退插件仍失败，回退 VS Code 才恢复](https://blog.laozhang.ai/posts/zh/codex-could-not-start-vscode/img/wsl-case-mismatch-401.webp) 另一位用户在 [#53840](https://github.com/openai/codex/issues/53840) 里列出的无效操作还包括：重装插件、重装 WSL 里的 VS Code Server、清理 Webview 缓存、新建 VS Code 配置文件、重启 VS Code 和 WSL。这些都不碰 VS Code 本身的版本，所以都无效。 ### 暂时不能升级 VS Code 时：用小写名字打开 WSL 窗口 1.141.2 发布之前，社区在 [#53738](https://github.com/openai/codex/issues/53738) 和 [#53840](https://github.com/openai/codex/issues/53840) 里用过一个绕过办法：从 Windows 的 PowerShell 用全小写的名字打开 WSL 文件夹，窗口名字和资源请求里的名字一致，401 就消失了。 先在 PowerShell 里运行 `wsl -l -v` 看自己的发行版名称，再把它改成全小写，例如 `Ubuntu-24.04` 写成 `ubuntu-24.04`： ```powershell code --new-window --remote wsl+ubuntu-24.04 /home/你的用户名/你的项目目录 ``` 已经在 WSL 终端里的话，可以让 PowerShell 代为打开当前目录： ```bash 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 插件设置文档](https://developers.openai.com/codex/ide/settings)说明这个设置让 Codex 在 WSL 里运行（仅限 Windows，修改后 VS Code 会重载）。#53840 的报告者用这个方式让 Codex 在 WSL2 里正常执行命令。它不修复 1.141.1 的问题，只是绕开了 WSL 远程窗口。 按修复说明，受影响的是名字里带大写字母的任何远程窗口，不只是 WSL。判断是不是这一支，以开发者工具里有没有 `webview/assets/` 的 401 为准。Cursor、Windsurf 用各自的版本号，是否受影响要看它们是否合入了 1.141.1 的那次改动，判断方法同样是看开发者工具里有没有这类 401。 ## 开梯子能好、开了反而卡：代理和 VPN 怎么影响启动 有人开了梯子就好了，也有人恰恰是开着代理才报错，两者并不矛盾。在 [#37521](https://github.com/openai/codex/issues/37521) 里，一位用户在插件 26.803.41515 上控制网络条件，测出了三种结果： | 网络条件 | Codex 面板的表现 | | --- | --- | | 代理正常工作 | 正常启动 | | 不走代理，请求很快失败 | 账号查询报错，界面以降级（离线）模式打开 | | 代理接受了连接，但请求一直挂着不返回 | 账号查询永远不结束，30 秒后显示报错页 | 关键在于请求是"很快失败"还是"一直挂着"。按他对插件代码的分析，界面要等账号信息查完才发"就绪"信号，而这个账号请求没有设超时，挂着就一直等，直到 30 秒的计时把界面换成报错页。直连时如果连接被直接拒绝，界面至少能以降级模式打开；如果连接一直没有回应，结果和代理挂起一样。这一点是按上面的机制推断的，适合解释为什么有人"开梯子就好了"：换成能用的代理后，请求能正常返回。 OpenAI Codex 团队成员 8 月 13 日在 [#37458](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/38088) 里测过 8 月的 26.803.41515：开着系统代理时界面要 26.7 秒、30.1 秒，有一次约 3.5 分钟才加载完，不开代理约 9 秒。8 月的修复之后，这种慢但最终能成功的加载不应再被报错页打断；真正挂住不返回的请求仍会卡住。 ## Remote-SSH 一直加载或报错：社区办法与各自效果 通过 Remote-SSH 连服务器时，Codex 面板一直转圈或 30 秒后报错，而终端里的 `codex` 能用。这一支在 [#26951](https://github.com/openai/codex/issues/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 怎么选](https://blog.laozhang.ai/zh/posts/codex-headless-login)；远端是否残留旧的 `codex app-server` 进程，一位本地 Linux 用户清掉残留进程和锁文件后有所改善，但问题仍会复发。Windows 本地的残留进程怎么判断，见 [Codex Windows 后台进程怎么处理：哪些该保留，哪些可以结束](https://blog.laozhang.ai/zh/posts/codex-windows-background-processes)。 以上都无效时，先用终端里的 Codex CLI 干活，把日志补到 #26951。 ## Dev Container 里报错：重装无效，#40532 尚无官方答复 在 Dev Container 里，[#40532](https://github.com/openai/codex/issues/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`，让每次重建容器都带上： ```json "customizations": { "vscode": { "settings": { "extensions.supportNodeGlobalNavigator": true } } } ``` 这是单个用户的对比结果，适合先看日志里有没有 `PendingMigrationError`，有的话再试。 ## 只有部分 Codex 标签页报错：同时开了多个对话标签 如果你在本地窗口里把 Codex 对话开在编辑器标签里，开了好几个，结果有的能用、有的显示报错页，情况和 [#43080](https://github.com/openai/codex/issues/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 团队成员的发布说明](https://github.com/openai/codex/issues/37458#issuecomment-5287557175)。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 一次跑通](https://blog.laozhang.ai/zh/posts/codex-cli-install)。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：安装、登录与第一次可审查改动](https://blog.laozhang.ai/zh/posts/codex-cursor-extension-guide)。 ### Codex 面板打开后报 401、429，和这个报错有关吗？ 没有关系。能打开面板说明启动已经完成，之后的 401、429 和断流是请求层面的问题，排查方法见 [Codex 401、429 与 Stream Disconnected：先找出失败的那一层](https://blog.laozhang.ai/zh/posts/codex-exceeded-retry-limit-429)。用 API Key 或第三方模型时的配置和首次验证，见 [Codex VS Code 教程：API Key、第三方模型与首次验证](https://blog.laozhang.ai/zh/posts/codex-vscode-extension-api-key-custom-models)。 ## 参考来源 本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-15。 - [openai/codex #37521](https://github.com/openai/codex/issues/37521) (github.com) - [#26951](https://github.com/openai/codex/issues/26951) (github.com) - [#40532](https://github.com/openai/codex/issues/40532) (github.com) - [#43080](https://github.com/openai/codex/issues/43080) (github.com) - [Codex 故障排查文档](https://developers.openai.com/codex/reference/troubleshooting) (developers.openai.com) - [修复 PR #341508](https://github.com/microsoft/vscode/pull/341508) (github.com) - [问题单 #341396](https://github.com/microsoft/vscode/issues/341396) (github.com) - [openai/codex #53738](https://github.com/openai/codex/issues/53738) (github.com) - [#53840](https://github.com/openai/codex/issues/53840) (github.com) - [Codex 插件设置文档](https://developers.openai.com/codex/ide/settings) (developers.openai.com) - [#37458](https://github.com/openai/codex/issues/37458) (github.com) - [#38088](https://github.com/openai/codex/issues/38088) (github.com)