Codex 桌面端更新后 Chrome 插件和 Computer Use 不可用，怎么排查和修复

最近在 Windows 版 Codex 桌面端更新后，遇到一个比较典型的问题：插件列表里看起来都还在，但实际使用时 Chrome 插件和 Computer Use 都不可用。

表面现象很容易误判成"插件没装好"或者"权限不够"。但这类问题如果直接重装、改权限、改 sandbox，很容易把现场弄乱。我的处理思路是：先备份，再分层验证，最后只修被证据确认的问题。

一、现象

更新后主要有两类异常：

Chrome 插件不可用

表现为浏览器扩展存在，但 Codex 无法连接到 Chrome 后端，或者关键脚本缺失。
Computer Use 不可用

调用 Computer Use 的初始化入口时失败，核心错误类似：

text 复制代码

Computer Use native pipe path is unavailable

这句话很关键。它说明并不是"没有这个插件"，而是当前 Codex 会话没有拿到 Computer Use 所需的本地管道路径。

换句话说：插件文件可能存在，但桌面端没有把底层 Windows 控制通道注入到当前会话里。

二、先不要急着改 sandbox

很多 Windows 自动化问题会让人第一反应去改权限，比如把 sandbox 从 elevated 改成 unelevated，或者反过来。

但这次不能一开始就这么做。因为真正的错误不是"请求的操作需要提升权限"，也不是典型的 os error 740，而是 native pipe 没有创建或没有注入。

所以我先做了三件事：

备份 Codex 配置和插件状态文件；
检查 bundled 插件缓存是否完整；
用最小调用测试 Chrome 和 Computer Use runtime。

这个顺序很重要。先确认问题在哪一层，再决定是否修改配置。

三、第一层：检查插件缓存是否完整

更新后，一个常见问题是 bundled plugin 的缓存或 latest 指针异常。

表现可能是：

Chrome 插件目录存在，但缺少关键脚本；
latest 指向了临时目录或残缺目录；
Computer Use 没有正确的 latest 指针；
marketplace source 仍指向旧的或临时的 bundled marketplace。

这类问题的修复方向是：

找到当前 Codex 安装包内完整的 bundled plugin 源；
让本地插件缓存重新指向完整版本；
修复 chrome/latest、browser/latest、computer-use/latest；
确认关键入口文件存在。

这里只需要修插件缓存和指针，不需要改模型配置、账号配置或系统权限。

四、第二层：检查 Chrome Native Messaging

Chrome 插件能否工作，不只取决于扩展是否安装，还取决于 Native Messaging Host 是否注册正确。

这次 Chrome 侧的问题包括：

浏览器扩展本身还在；
但 native host 注册缺失或指向异常；
修复插件缓存后，还需要补回用户级注册表里的 Native Messaging Host 映射。

这里有一个坑：如果用管理员上下文写注册表，可能写到另一个 HKCU 视图里。Chrome 实际读取的是当前用户上下文下的 HKCU。

所以修复 Chrome Native Messaging 时，要确保写入的是普通用户上下文可见的那份注册表，而不是只在提权上下文里可见。

修复后，Chrome 侧可以通过两个信号确认恢复：

native host 校验通过；
Codex 能发现 Chrome backend，并能读取当前打开标签页。

五、第三层：Computer Use 为什么仍然不可用

Chrome 修好后，Computer Use 仍然报：

text 复制代码

Computer Use native pipe path is unavailable

继续往下看，Computer Use 的客户端入口依赖两样东西：

nodeRepl.nativePipe.createConnection
SKY_CUA_NATIVE_PIPE_DIRECTORY

如果这两项都没有，Computer Use 客户端脚本即使存在，也无法连接 Windows helper。

也就是说，这时问题已经不在插件目录，而在桌面端是否成功启动并注入 Computer Use native runtime。

六、真正的上游原因：配置文件隐藏字符导致解析失败

继续查桌面端日志后，发现一个更上游的错误：Computer Use native pipe 启动失败，是因为 Codex 配置文件解析失败。

原因很隐蔽：配置文件开头存在 UTF-8 BOM 隐藏字符。

这类问题肉眼看配置文件通常看不出来。第一行可能看起来完全正常，比如：

toml 复制代码

model = "..."

但字节级检查会发现文件开头多了 BOM。某些解析器会把它当成非法字符，导致配置解析失败。配置解析失败后，桌面端就不会正常启动 Computer Use native pipe，最终当前会话里也就拿不到 SKY_CUA_NATIVE_PIPE_DIRECTORY。

修复方式很简单：把配置文件重新保存为 UTF-8 without BOM。

重点是，不要顺手重写整份配置，也不要改无关配置。只去掉 BOM，保持原有内容不变。

七、修复后的验证顺序

修完之后，不要只看"没报错"，要按层验证：

配置文件开头字节正常

确认文件直接以配置正文开头，不再有 BOM。
bundled 插件缓存完整

确认 Chrome、Browser、Computer Use 的 latest 都指向完整目录。
Chrome Native Messaging 正常

确认 Chrome extension、native host、backend 都能连通。
新线程里测试 Computer Use

重新启动 Codex 桌面端或重新加载插件后，新开线程测试：

js 复制代码

await setupComputerUseRuntime({ globals: globalThis });
await sky.list_apps();

判断结果
如果 list_apps() 能返回应用列表，说明 Computer Use native pipe 已经正常注入。

八、可直接发给 Codex 的修复指令

下面这段可以直接发给 Codex，让它按顺序排查和修复。注意：这是脱敏后的通用版本，没有包含任何本机绝对路径、账号或线程信息。

text 复制代码

请帮我排查并尽量修复 Windows 版 Codex 桌面端更新后 Chrome 插件和 Computer Use 插件不可用的问题。

要求：
1. 先备份 Codex 配置和插件相关状态文件，包括：
   - %USERPROFILE%\.codex\config.toml
   - %USERPROFILE%\.codex\.codex-global-state.json
   - %USERPROFILE%\.codex\chrome-native-hosts.json
   - 其他你判断与插件缓存、marketplace、native host 有关的配置文件

2. 检查 bundled plugin 是否完整：
   - 确认 openai-bundled marketplace 是否存在
   - 确认 chrome@openai-bundled、browser@openai-bundled、computer-use@openai-bundled 是否 installed 且 enabled
   - 检查插件 cache 中 chrome/latest、browser/latest、computer-use/latest 是否指向完整目录
   - 确认关键文件存在，例如：
     - chrome 的 scripts/browser-client.mjs
     - computer-use 的 scripts/computer-use-client.mjs

3. 如果发现 latest 指针或 marketplace source 指向残缺目录、临时目录或旧目录：
   - 在备份后修复 source/latest 指针
   - 优先使用当前 Codex 安装包内的完整 bundled plugin 源
   - 不要修改无关配置

4. 检查 Chrome Native Messaging：
   - 确认 Chrome 扩展已安装并启用
   - 确认 Native Messaging Host manifest 存在
   - 确认 HKCU 下当前用户可见的 Native Messaging Host 注册表项正确
   - 注意不要只写入管理员上下文可见的 HKCU

5. 检查 Computer Use runtime：
   - 读取 computer-use skill
   - 用 Node REPL 检查：
     - nodeRepl.requestMeta 中的 sandbox
     - nodeRepl.env.SKY_CUA_NATIVE_PIPE_DIRECTORY 是否存在
     - nodeRepl.nativePipe 是否存在
     - nodeRepl.nativePipe.createConnection 是否存在
   - 从 computer-use-client.mjs 调用 setupComputerUseRuntime({ globals: globalThis })
   - 尝试 sky.list_apps()

6. 如果 Computer Use 报：
   Computer Use native pipe path is unavailable
   请继续检查 Codex 桌面端日志，重点看：
   - computer-use native pipe startup failed
   - config.toml 解析失败
   - UTF-8 BOM 或其他隐藏字符导致配置解析失败

7. 如果 config.toml 开头存在 UTF-8 BOM：
   - 只去掉 BOM
   - 保持配置内容不变
   - 保存为 UTF-8 without BOM
   - 不要顺手重写无关配置

8. 只有当出现明确的 os error 740 / 请求的操作需要提升权限 时，才判断是否需要调整 [windows] sandbox。
   不要一开始就盲目修改 sandbox。

9. 修复后请重新验证：
   - Chrome backend 是否可发现
   - Chrome openTabs() 是否能正常返回
   - Computer Use 是否注入 SKY_CUA_NATIVE_PIPE_DIRECTORY
   - nodeRepl.nativePipe.createConnection 是否存在
   - setupComputerUseRuntime 是否成功
   - sky.list_apps() 是否成功

10. 最后请用中文总结：
   - 根因是什么
   - 修改了哪些文件或配置
   - 哪些验证通过
   - 还有哪些未解决项

快速指令：

text 复制代码

只做只读诊断，不要修改任何文件或配置。
请测试当前 Codex 桌面端新线程里 Computer Use 是否可用：读取 computer-use skill 后，
用 Node REPL 检查 nodeRepl.requestMeta 中的 sandbox、nodeRepl.env.SKY_CUA_NATIVE_PIPE_DIRECTORY、
是否存在 nativePipe/createConnection，
然后从 C:\Users\Administrator\.codex\plugins\cache\openai-bundled\computer-use\26.527.31326\scripts\computer-use-client.mjs 调用 setupComputerUseRuntime({ globals: globalThis }) 并尝试 sky.list_apps()。
最后用简短中文报告：sandbox、SKY_CUA_NATIVE_PIPE_DIRECTORY 是否存在、bootstrap/list_apps 成功或报错。

九、几个经验教训

第一，不要把"插件可见"当成"插件可用"。

Codex 桌面端这类插件通常有三层：插件文件、运行时桥接、本地 helper。任意一层断了，表现都会像"插件不可用"。

第二，不要一上来改 sandbox。

只有出现明确的权限错误，比如需要提升权限，才考虑 sandbox。否则应先查 pipe、runtime 和配置解析。

第三，Windows 下修注册表要注意上下文。

管理员上下文和普通用户上下文看到的 HKCU 可能不是同一个效果。Chrome Native Messaging 通常需要当前用户可见的注册表项。

第四，隐藏字符问题要用字节级检查。

BOM、不可见控制字符、错误编码，都可能让配置看起来没问题，实际解析失败。

第五，Computer Use 不建议用其他键鼠模拟方式绕过。

如果官方 Computer Use runtime 没起来，应该修 native pipe，而不是用 PowerShell SendKeys 或其他方式"假装可用"。那会绕过插件的安全、中断和确认机制。

十、最终结论

这次问题不是单一原因，而是一条链：

更新后 bundled 插件缓存和 latest 指针异常；
Chrome Native Messaging Host 注册缺失或不可见；
Computer Use 插件文件恢复后，native pipe 仍未注入；
最终定位到配置文件开头的 UTF-8 BOM 导致桌面端解析配置失败；
去掉 BOM 并重新加载桌面端后，Computer Use 才具备恢复条件。

排查这类问题时，最有效的方法不是重装，也不是盲改权限，而是逐层拆开：

text 复制代码

插件文件是否完整
-> 插件入口脚本是否存在
-> 浏览器/native host 是否连通
-> Computer Use native pipe 是否启动
-> 会话里是否注入 pipe path
-> 配置解析和桌面端日志是否正常

按这个顺序查，基本可以避免反复重启和盲目修改配置。

复制代码