Codex 报 couldn't load its resources：5 个根因与修复（2026）

摘要

报错原文：      "Codex could not start. The extension couldn't load its resources."
实际含义：      webview 没在 30 秒内发回 ready 握手
受影响版本：    26.803.41515（08-07）、26.803.61601（08-10）
修复版本：      26.810.41047 正式版 / 26.5810.41047 预览版（08-13）
当前最新正式版： 26.810.52044（08-15）
安全回退目标：  26.727.40816（07-30）
不同根因数：    5 个（看门狗、网络可达性、认证挂起、浏览器缓存、Copilot 冲突）
无效偏方：      删 auth.json、追查 data:font CSP 警告
上游未解决：    openai/codex#37521（账号身份请求挂起）

如果你的 Codex 侧边栏转了半分钟，然后塌成一块灰色面板写着 “The extension couldn’t load its resources”，这句话在骗你。资源加载得好好的。真正失败的是一次握手，而扩展宿主那边有一只秒表在跑。

这个报错文案是这个 bug 最好的伪装。Codex 不是找不到自己的文件，是没等到一个已经把文件加载完的窗口回话。

下面讲的是 2026 年 8 月这次回归：哪些版本带病、OpenAI 究竟改了什么、以及另外四条会打印出同一句话的故障路径。如果你的问题是命令行找不到而不是编辑器面板，该看的是 codex: command not found 的 7 个修复点。如果是 Windows 上 Codex 桌面端起不来后端，那是另一个报错、另一套修法。

先确认你装的是哪个版本

一条命令就能判定，而且这页后面所有分支都取决于这个答案。 在改任何设置之前先跑它。

code --list-extensions --show-versions | grep openai.chatgpt

版本号第二段带 5 前缀的（比如 26.5810.41047）是同一份代码的预览版通道。如果你在 Marketplace 里开了 pre-release，26.5810.41047 和 26.810.41047 带的是同一个修复。

确认自己撞的确实是这个 bug，看 Codex.log 里的失败特征：

Initialize received
Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

更值得注意的是失败窗口里缺了什么。正常启动会打印三个渲染里程碑，失败的一次一个都到不了：

React root render requested
app routes mounted
ready provider mounted

如果 Initialize received 出现了、三个里程碑一个都没有，说明后端是健康的，前端应用压根没启动起来。这就是本文这个 bug。如果连 Initialize received 都没有，那是另一个问题，上面那张版本表帮不了你。

该升级、回退，还是干脆等？

升级。 对现在才读到这篇的绝大多数人来说，升到 26.810.52044 就是全部答案，而且这个判断没什么悬念。

三选一的规则：

• 升级：只要你在任何 26.803.x 上。修复已经稳定经过三个版本。十个人里有九个到这一步就结束了。
• 回退到 26.727.40816：只有当你已经升过 26.810.41047、面板仍然打不开、并且已经排除了下面的网络和认证根因时才考虑。回退是个真选项，但它不是诊断，而且过一周你还得再来一次。
• 别读了，直接用 CLI：如果你一小时内要交东西。扩展和 CLI 是两个独立的二进制，一个坏了完全说明不了另一个的状态。

停止条件：如果你已经升到 26.810.52044 而面板还是打不开，别再试版本排列组合了。产生这个特定报错的看门狗在那个版本里已经不存在。你现在看到的是根因 2 到 5 里的某一个，重装多少次都碰不到。

为什么 Codex 会说 “couldn’t load its resources”？

因为一个 30 秒计时器到点了，而它打印的那句话是错的。

扩展宿主创建 webview，然后等这个 webview 回发一条 ready 消息。消息没在窗口期内到达，宿主就丢弃 webview、换上一个静态错误页。这个页面之所以甩锅给资源加载，是因为那是 webview 沉默最常见的原因，不是因为它真去检查过。

社区在 GitHub 主线程里追出了真相，那条 issue 六天里累积了 53 条评论才收敛。期间出现过两种互相竞争的诊断，而流传更广的那个是错的，错得还挺有教育意义。

第一种理论指向 webview bundle 里一行把渲染卡在 startup.whenReady() 后面的代码，而且移除它的补丁看上去确实有效。但后来的分析证明这个表达式在 VS Code 构建里根本会短路。下面是受影响版本 app-main-BpHShvzH.js 里的原始那一行：

let e = G || K || N.startup == null ? void 0 : Promise.resolve(N.startup.whenReady());

在 VS Code 构建里，服务对象从来不注册 startup，所以 N.startup == null 为真，整个表达式求值成 void 0，whenReady() 一次都不会被调用。补一个永远不执行的调用，不可能修好任何东西。它之所以看起来有效，是因为打补丁的过程顺带重写并重新生成了整个 asset graph。

第二种理论站住了：负责派发 {type: "ready"} 的就绪上报器在组件树里嵌套在业务初始化下面。任何拖慢应用启动的东西——一次慢的网络调用、一个挂住的认证请求——都会连带拖住这次握手，而看门狗分不清「这个窗口死了」和「这个窗口还在干活」。

第三种理论，开发者控制台里那条 data:font/woff2 的 CSP 警告，是条红鲱鱼。它在正常启动的窗口里同样会出现。有人同时收集了成功和失败两种状态的日志之后给出结论：字体 CSP 警告和其他扩展报的错都不是启动阻塞点。

26.810.41047 到底改了什么？我们把 VSIX 拆了

OpenAI 的关闭留言说这个版本”fixes the startup watchdog issue”，并且你不会再”simply because application initialization takes longer than 30 seconds”就看到那个报错。这句话措辞很精确，值得逐字读。

我们从 Marketplace 下载了两个 VSIX 包（darwin-arm64，分别是 167 MB 和 207 MB），外加回归前那一版做对照，统计扩展宿主 bundle extension/out/extension.js 里的字符串出现次数：

第一列才是有意思的地方，它把整个故事改写了。这些字符串在 7 月那版里一个都不存在。整个错误屏——看门狗和文案一起——是跟着这次回归一同到来的。

所以这个看门狗不是一个长期存在、突然开始误报的机制。它在 2026-07-30 时并不存在，2026-08-07 上线，用六天时间把一类慢启动误标成资源加载失败，然后在 2026-08-13 被移除。计时器和它打印的那句话，生死都在同一周内。

这也解释了为什么回退到 26.727.40816 对那么多人都灵。他们回退到的不是一个「没有这个 bug」的版本，而是一个没有秒表的版本，慢启动只会慢，不会被杀掉再换上一顶帽子。

带着这个结论再读一遍 OpenAI 的措辞：一个近期改动暴露了一个此前被掩盖的既有 bug。新看门狗就是那个近期改动。它照出来的卡死才是既有 bug，而后者至今还在——这正是下一节存在的理由。

修复并没有删掉错误页本身，只是改了措辞：

所以这次修复有两半，而只有一半算「修」。那个 30 秒就放弃、并且甩锅给资源的看门狗没了。诚实版的替代文案留了下来，用在 UI 真的起不来的场合。

这里有个实际后果，比听上去更重要：你搜到这一页所用的那句话，在当前版本里已经不存在了。 如果你在 26.810.x 上看到的是 “could not start its user interface”，那你面对的不是看门狗这个 bug，而是一次真实的卡死，往下几节才是你要去的地方。

顺带一提，webview 入口 app-main 在两个版本里都是 2,679 字节，SHA-256 不同，而那个 startup == null 的短路在两版里都在。webview 握手逻辑没有被重写，只是扩展宿主不再因为它慢而惩罚它。

同一句报错背后的 5 个根因

只有第一个被 8 月这次更新修掉了。另外四个仍然活着，而且它们一直都在。

根因 1 是 8 月这次回归，现已关闭。根因 2 到 5 一直都在。修复之前，这五个会打印出同一句误导性的话——这正是那条 GitHub 线程花了六天才收敛的原因：一群人在拿五个不同的 bug 对笔记，而它们戴着同一个报错面具。

根因 2：网络可达性

这是升级之后最常见的幸存者，OpenAI 关闭 issue 时点名提到了它：检查你的代理和网络设置。

线程里出现了两种不同的失败形态。

VS Code 的代理支持被关掉了。 检查你的 settings.json：

{
  "http.proxySupport": "on"
}

如果这一项是 "off"，扩展就用不了系统代理。有位用户发现这是自己排查其他网络问题时改的，改完就忘了。改回 "on" 之后卡死消失。

扩展宿主的环境里没有代理变量。 从一个导出了代理变量的 shell 里启动 VS Code，对部分环境有效：

export https_proxy=http://127.0.0.1:9001
code

在 macOS 和 Linux 上，从桌面图标启动 VS Code 不会继承 shell 的环境变量。如果你的代理配在 .zshrc 里、而 VS Code 是从 Spotlight 起的，扩展宿主根本看不到它。

一个代码编辑器的面板凭什么在渲染之前需要联网？因为启动时要拉账号状态。线程里的一段日志显示，即便用户配的是 API key 而不是 ChatGPT 登录，扩展照样会发这个请求：

WARN codex_core_plugins::manager: failed to warm featured plugin ids cache
error=remote featured plugin request to
https://chatgpt.com/backend-api/plugins/featured?platform=codex
failed with status 401 Unauthorized

这个请求无视你配的是哪家 provider，照打 chatgpt.com。如果你的网络到不了它，初始化就会停在一个旧看门狗最终会杀掉的位置。如果你是在 CLI 而不是面板上遇到 401，Codex CLI 401 的三种根因那篇把它们拆开讲了。

这条路径可以用一行命令自测。在跟出问题的编辑器同一台机器、同一个网络下跑：

curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" \
  "https://chatgpt.com/backend-api/plugins/featured?platform=codex"

结果这样读：

在正常网络下不带认证实测，这个端点约 100 毫秒返回 401，响应体是 25 字节的 {"detail":"Unauthorized"}，与上面扩展日志里引用的那一段逐字一致。日志里的 401 不是认证 bug 的证据，它恰恰证明请求跑完了。要找的失败形态是沉默，不是拒绝。

根因 3：账号身份请求挂起

这个能扛过每一次修复，而且有自己的跟踪 issue：openai/codex#37521，撰稿时仍然开着，带 auth 和 connectivity 标签。

失败形态是：一个账号身份请求发出去，然后就再也没有然后了。没有报错，没有超时，也不回退到离线模式，启动就那么一直等。在 26.810.41047 之前，看门狗最终会把面板换成资源报错页，至少还告诉你出事了。现在面板就只是干坐着。

用户侧没有干净的修法。对一部分人有效的做法：

1. 打开 ChatGPT 桌面端，重新登录一次，然后彻底重启 VS Code
2. 重载窗口两三次（Cmd/Ctrl+Shift+P → Developer: Reload Window）

两个本质上都是变相重新认证，都不可靠。如果反复重载能换来一个能用的面板，请把它当成有保质期的权宜之计，不是修复。

根因 4：浏览器 service worker 缓存

只出现在通过浏览器访问的 VS Code Web 和 code serve-web 会话里。webview 资源被浏览器的 service worker 缓存住，扩展更新之后，缓存的 asset graph 可能仍然引用一批已经改名的文件。

指向这一条而不是其他几条的特征：

• 只在浏览器标签页里复现，同一台机器上的桌面版 VS Code 从不出问题
• 执行 Developer: Reload Window 也没用
• 连到同一台服务器的多个 VS Code Web 窗口表现不一致

修法是在浏览器侧硬清缓存：清掉那个 VS Code Web 源的站点数据，然后重新加载。普通刷新不管用，因为 service worker 会在请求走到网络之前先把陈旧的 graph 端上来。

根因 5：Positron 与 GitHub Copilot

范围很窄但能干净复现，报告环境是 Ubuntu 24.04 上的 Positron 2026.08.0（Code OSS 1.124.0）。Codex 一开始一切正常，直到 GitHub Copilot 被认证为语言模型提供方。启用 Copilot 并重启 Positron 之后，Codex 就起不来了。退出 Copilot 登录再重启，Codex 恢复。

这个从全新的用户配置文件也能复现，所以不是配置日积月累弄坏的。如果你在 Positron 里同时跑这两个，答案就是它，重装多少遍 Codex 都没用。

网上流传的哪些修法其实没用？

三个，而且传得最广的那个会让你用登录状态换一场空。

有三个建议在 GitHub 线程和周边搜索结果里传得很广。知道它们的价值恰恰在于可以跳过它们。

删掉 ~/.codex/auth.json。 转发次数最多的一个。它听上去合理，因为扩展确实会卡在跟认证相关的工作上，而且第一个贴出来的人报告有效。但后来试的人什么也没等到，还有人报告一换 workspace 报错就回来了。你付出的是自己的会话，换回来的是一次抛硬币。看门狗的触发条件是握手超时，删一个凭证文件不会让 webview 渲染得更快。

追查 data:font/woff2 那条 CSP 警告。 最初的 issue 报告里附了一行控制台日志，显示 Chrome 的 CSP 拦掉了一个内联 base64 字体，读起来像铁证。它不是。这条警告在启动完全正常的窗口里同样会出现，线程后期的诊断工作确认了它不是阻塞点。

把 startup.whenReady() 从 webview bundle 里 patch 掉。 这个比前两个更值得尊重，因为提出者做了真功夫，而且它确实帮到了一些人。但机制是错的，前面引用的那行原始代码已经说明问题：N.startup == null 在 VS Code 构建里为真，whenReady() 在那里是死代码。补丁是靠重新生成 asset graph 的副作用起效的。如果你打过这个补丁，升级之后请撤掉。扩展目录里手改过的 bundle 在下次自动更新时会被静默覆盖；而且如果改写过程中破坏了非 ASCII 字符——某个 PowerShell 实现就因为 Windows ANSI 代码页踩过这个坑——你换来的不是能用的面板，而是一个语法错误。

版本时间线：26.803 这次回归

从第一份报告到修复上线六天，横跨六个构建。

这条时间线上有个细节值得单独拎出来：这个 issue 挂的标签是 windows-os，最初的报告也确实来自 Windows。但线程里收集到的确认覆盖了 macOS、Debian 13、通过 Remote-SSH 连的 Ubuntu、WSL2，以及 Firefox 里的 VS Code Web。如果你因为自己不在 Windows 上就跳过了这个 bug，是那个标签误导了你。

怎么回退到指定版本

如果你现在就需要 26.727.40816，别用扩展面板。齿轮菜单里的「Install Another Version」正是原 issue 提交者失败的那条路，报错是 Error while downloading VSIX: Canceled。命令行更可靠，一行搞定：

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

在 macOS + VS Code 1.132.0 上实测通过。它会自动解析对应平台的包，成功时回报装上的版本：

Installing extension 'openai.chatgpt' v26.727.40816...
Extension 'openai.chatgpt' v26.727.40816 was successfully installed.

然后记得单独关掉这个扩展的自动更新，否则一天之内后台更新就会把你的回退撤销。在扩展面板里右键 Codex，取消勾选 Auto Update。

要重新往前走，装的时候不带版本后缀即可：

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

日志到底在哪

整条 GitHub 线程反复提到的 Codex.log 是按窗口分的，而且埋在一层时间戳目录下面——这也是为什么那么多报告者宁可贴面板截图也不贴日志：

每次 VS Code 会话都会新建一个时间戳目录，所以按修改时间排序取最新的那个。更快的路子是输出面板：Cmd/Ctrl+Shift+U，然后在下拉里选 Codex。

对于根本没走到扩展宿主的故障——尤其是根因 4——扩展日志里不会有任何有用的细节。这时用命令面板里的 Developer: Open Webview Developer Tools，在 Console 标签里勾上 Preserve log，然后重载窗口。那里的第一条红色报错才是值得读的。线程最后正是靠这套流程定位到一个渲染侧的语法错误，光读 Codex.log 永远也读不出来。

编辑器面板起不来的时候，怎么继续干活？

用 CLI。它是独立的二进制，上面五个根因没有一个碰得到它。

上面每一个根因都活在 VS Code 的 webview 这一层，没有一个触及 agent 本身。这是很多人一边重装扩展一边忽略掉的部分：面板只是一个客户端，而且它不是唯一的那个。

Codex CLI 是独立的二进制，有独立的进程模型：

codex --version
# codex-cli 0.147.0

只要它有响应，无论侧边栏在干什么，你手上都有一个能用的 Codex。反过来也成立——这也是为什么上面那张版本表值得在开始排查之前就跑一遍：面板坏了和 CLI 坏了，几乎从来不是同一起事故。

时间线还暴露了第二个缺口。修复在 2026-08-13 到达 VS Code Marketplace，但 OpenAI 同时说明，Windows 包暂时没有发布到 Open VSX，卡在一个从 2026 年 3 月挂到现在的包体积上限问题上。那些从 Open VSX 而不是 Marketplace 拉扩展的编辑器——包括好几个 VS Code 衍生版——给 Windows 用户端上来的可能仍然是修复之前的构建。如果你用的正是这类编辑器、版本表显示 26.803.x 而又没有更新可用，原因就在这里。

两个缺口形状是一样的：你能不能用上模型，取决于一家厂商的客户端、一家厂商的发版节奏、一家厂商的分发仓库。而 Codex CLI 说的是 OpenAI 兼容的 HTTP，把它指向另一个端点只要两个环境变量：

export OPENAI_BASE_URL=https://api.ofox.run/v1
export OPENAI_API_KEY=your_key
codex

这能让终端这条路在扩展趴窝期间照常工作——无论坏掉的是扩展、是仓库，还是一次分区域灰度。config.toml 多 Provider 配置那篇讲了不想用环境变量时的配置文件写法；如果你想要一个不取决于「这周发的是哪个版本的插件」的兜底，ofox 用一把 key 提供当前 Codex 可用的模型。

怎么验证修复真的生效了？

先看版本号，想要证据而不是版本号的话再去 grep bundle。 三个检查，按信息量从低到高排列。

看版本。 用本文开头那张表。26.810.x 及以后都带修复。

查字符串。 如果你想直接确认手上这个构建里看门狗确实没了，而不是相信一个版本号，报错文案就存在扩展宿主的 bundle 里：

grep -c "couldn't load its resources" \
  ~/.vscode/extensions/openai.chatgpt-*/out/extension.js

每个已安装的副本会输出一行，形如 <路径>:<次数>。计数为 0 表示那个副本是干净的，非零就是受影响的构建。

这里有个容易踩的坑：VS Code 更新或卸载扩展时未必会删掉旧目录，所以这个通配符可能一次匹配到好几个版本，把你早就不用的构建也一并报出来。要从路径里读版本号，别只看那个数字。 在一台既测过回退又测过升级的机器上，这条命令会返回两行：

/Users/you/.vscode/extensions/openai.chatgpt-26.810.41047/out/extension.js:0
/Users/you/.vscode/extensions/openai.chatgpt-26.727.40816-darwin-arm64/out/extension.js:0

两个都干净，但理由不同：一个是修复之后的版本，另一个压根早于看门狗存在。另外注意，从 Marketplace 装的包目录名里带平台后缀，手动装 VSIX 的不带，所以两种形态并排出现是正常的，不是安装损坏的迹象。

看日志。 冷启动之后打开 Codex 输出通道，找诊断那节列出的三个渲染里程碑：React root render requested、app routes mounted、ready provider mounted。三个都在，说明 webview 完整启动了，剩下的无论多慢都是另一回事。

具体到扩展本身，VS Code Marketplace 页面会显示当前版本和发布日期，那里的版本历史是确认「有没有比手上更新的构建」最快的途径。注意 Marketplace 分发的是平台专属包，所以 win32-x64 和 darwin-arm64 的最新版本可能差几个小时。

如果根本不是扩展的问题呢？

有两个相邻故障在屏幕上长得几乎一样，但它们不是这个 bug。

如果 Codex 在编辑器里根本看不到，或者你的 shell 找不到那个二进制，那是 PATH 和安装问题，看 codex: command not found 的 7 个修复点。如果是 Windows 上 Codex 桌面端报 app-server manifest 相关、消息里提到 resourcesPath 的错，那是原生宿主注册问题，是个确实不同的 bug，看 Codex 启动不了 app server。“resources” 这个词同时出现在两条报错里纯属巧合，已经让不少人白花了几个小时。

如果面板启动正常、只是模型选择器里找不到自定义模型，那启动路径上什么都没坏，那是桌面端的一个配置问题。

参考信息来源

• https://github.com/openai/codex/issues/37458
• https://github.com/openai/codex/issues/37521
• https://github.com/EclipseFdn/open-vsx.org/issues/8724
• https://marketplace.visualstudio.com/items?itemName=openai.chatgpt