你在 Windows 上让 Codex 读取或控制 Chrome。应用打开了一个 about:blank 窗口,看不到页面,然后返回 Invalid browser service environment。没有任何标签页被读取,也没有任何标签页被控制,而且两条路径都一样:应用自带浏览器和控制已安装的 Chrome。
该错误在 2026-11-05 报告于 openai/codex #59676,环境是 Windows 11 Pro build 26300,AppX 应用 26.1029.9216.0,浏览器插件 26.820.60940。截至 2026-11-08,该 issue 仍未关闭,也没有官方修复。已有的是一套清楚的诊断和一条已被另一份报告验证可行的解锁路径。
"Invalid browser service environment" 是什么意思?
意思是浏览器进程加载的插件代次不认识应用交给它的环境。这是 Codex 运行时与插件之间的版本不匹配,不是权限问题,也不是 Chrome 扩展过期。
在 #59676 的报告里,异常在 browser-service.mjs 的 setup() 函数中抛出,它会拒绝已加载插件代次不认识的环境值。在那台机器上,应用运行时是 26.1029.70936,Chrome 插件是 26.1029.70936,而浏览器插件卡在 26.820.60940,一个八月的构建。
为什么清空插件缓存不管用?
因为缓存是结果,不是原因。应用会从随包附带的 marketplace 快照重新生成插件,而这份快照才是过期的部分。
报告写得很明确:删掉缓存之后,Codex 会重新创建同一个 26.820.60940。只要生效的 marketplace 没更新,清目录只是把错误的代次再装一遍。
怎么确认版本不一致?
两条命令加一次文件确认。第一条列出 Codex 正在考虑的 marketplace,第二条列出实际安装了什么东西。
codex plugin marketplace list --json
codex plugin list --marketplace openai-bundled --json
在第二条命令的输出里找到 browser 这一项,看 version 和 installedPath 两个字段。需要关注的 marketplace 叫 openai-bundled,它不是 Git 源,而是本地快照,所以 codex plugin marketplace upgrade 不会碰它。
真正定案的对比是浏览器插件版本和应用版本。在 #59676 的报告里,插件停在 26.820.60940,而运行时已经是 26.1029.70936。
然后打开 %USERPROFILE%\.codex\config.toml,找到 NODE_REPL_TRUSTED_SERVICES 这一行。它是一个 JSON 值,指向运行时信任的文件,版本就写在路径里:
NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/<you>/.codex/plugins/cache/openai-bundled/browser/26.820.60940/scripts/browser-service.mjs","sky":"@oai/sky/service"}'
注意在这个案例里,路径和已安装的插件是一致的,错误照样发生。也就是说,问题不是路径指向了别的版本,而是装着的插件是一个当前应用不认识的代次。路径里真正值得检查的是它到底存不存在。下表汇总了每种读数的含义。
| 你看到的 | 它的含义 |
|---|---|
codex plugin list 显示 browser 的版本比应用旧 | marketplace 快照过期。正确的插件在安装包里,但没有被生成出来 |
NODE_REPL_TRUSTED_SERVICES 指向的版本在 plugins\cache\openai-bundled\browser 下不存在 | 生成失败。运行时信任的是一个不存在的文件 |
%USERPROFILE%\.codex\plugins\cache\openai-bundled 这个目录根本不存在 | 是 Windows 供应失败,原因不同。见缓存缺失那一节 |
| 版本一致但错误依旧 | 另一种故障。建议带上两个版本和应用日志开 issue |
想要更全面的诊断,codex doctor --json 会以机器可读格式返回各项检查,包括启动时的插件警告。它不会帮你比对版本,但能很快看出插件到底有没有加载。
哪个修复能解锁插件?
截至 2026-11-08 没有官方修复。有的是一个用户在另一份同一机制的 issue 里测试并记录的流程,即 #47443。那里的症状是模块缺失,这里是环境无效。原因是同一个:marketplace 快照落后于已安装的包。
动手前的提醒:这是对缓存目录和 Windows 包文件的纯手工操作。先备份,关掉应用再执行,并且把它当作最后手段。#47443 的记录写明,整个过程中没有改动任何包文件,也没有改动 Windows 的安全设置。
- 关闭 Codex 应用,找到当前快照。路径来自
codex plugin marketplace list --json,通常是%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled。 - 把旧快照改名做备份。不要删除。如果新流程失败,一条命令就能回到原状态。
- 从安装包复制当前的 marketplace。用
Get-AppxPackage *codex* | Select InstallLocation找到包目录,把app\resources\plugins\openai-bundled用xcopy /G复制到一个暂存目录,和原报告一样。替换快照之前,先确认每个相对路径和每个文件大小都和源一致。 - 用受支持的命令重新安装插件。它会把快照版本装进预期缓存,并以 JSON 返回最终版本。
codex plugin add browser@openai-bundled --json
检查输出里的 version 和 installedPath 字段。路径必须和 NODE_REPL_TRUSTED_SERVICES 里的一致。如果命令说插件已经安装,先移除再重新添加:
codex plugin remove browser@openai-bundled --json
codex plugin add browser@openai-bundled --json
打开应用,让智能体执行 await agent.browsers.list()。列表里必须包含你用的浏览器后端。在 #47443 的报告里,等价的 agent.browsers.get("edge") 测试返回了后端文档和已打开的标签页,确认绑定成功。
如果缓存目录根本不存在呢?
那是另一个问题,虽然症状看起来一样。在 #46744 里,config.toml 指向 plugins\cache\openai-bundled\browser\<version>\scripts\browser-service.mjs,而那个目录始终没有被创建。AppX 包里的文件被标记为受保护,应用为生成插件所做的复制失败,只留下不完整的 openai-bundled.staging-* 目录。
这种情况下重装插件不管用,因为插件根本到不了缓存。路径是像上面的流程那样,从安装包手动供应缓存,或者等官方修复。该 issue 还提到 Browser、Computer Use 和图像生成也因为同一个生成失败而不可用。
哪些尝试不值得做?
| 尝试 | 为什么不管用 |
|---|---|
删除 plugins\cache\openai-bundled | 应用会从过期快照重建同一个旧版本 |
| 重启应用或电脑 | 版本在生成时就定了,不是在启动时 |
codex plugin marketplace upgrade | 它只升级 Git marketplace。openai-bundled 是本地快照 |
| 不更新快照直接重装插件 | 装回来的是原来那个代次 |
| 升级应用 | 在 #46744 的报告里,故障在后续版本中依然存在 |
没有应用浏览器时怎么继续干活?
把需要浏览器的任务和不需要的分开。重构、测试、构建、读仓库和写代码都不依赖浏览器插件,在终端里照常工作。对于确实需要浏览器的任务,在终端智能体上接入一个自动化 MCP,可以绕开桌面应用的插件供应路径。
如果你的问题是依赖一个桌面应用总要按错误版本生成的浏览器插件,终端智能体直接省掉了这一步:没有需要生成的插件 marketplace。 Verboo Code 在终端里运行,token 不限量,反复重测修复也不消耗额度。



