Windows 上修复 Codex Desktop 浏览器与 Computer Use 工具未暴露：一次安全复盘

有一种很迷惑的故障：Browser、Chrome、Computer Use 在插件列表里都能看到，但新任务里没有可调用的运行时工具。表面上像是“插件没安装”，实际上可能是插件文件、运行时、任务启动注入和本地配置之间的状态不一致。

这篇文章只保留可复用的方法，不公开真实设备路径、账户信息、日志全文、文件哈希、备份位置或任何凭据。

先定义“真的修好”

仅看到插件名称还不够。完整验证至少要覆盖四层：

官方桌面包状态正常；
Browser、Chrome、Computer Use 已安装并启用；
本地运行时能够启动，辅助传输能够工作；
新建任务里实际出现对应工具，并完成一次低风险交互验证。

最后一条最容易被忽略。工具集合通常在任务创建时确定，旧任务不会因为后台文件刚刚修好就自动获得新工具。

诊断时看到的故障链

这次问题不是单点故障，而是一条链：

桌面端尝试准备本地运行时时失败；
运行时因此被判定为不可用；
任务启动阶段跳过了相关工具注入；
插件清单仍然存在，于是出现“看得见但用不了”。

日志中有价值的是错误类别，而不是整份日志。类似下面的标记可以帮助定位阶段：

bundled_executable_relocation_failed
node-repl-missing
browser_use_setup_failed
native pipe helper unavailable

公开求助时只贴经过脱敏的相关几行；完整日志可能包含用户名、目录、任务标识和其他环境信息。

修复顺序：从低风险到高风险

1. 只读检查

先确认官方包健康状态、插件清单和本地配置，不写文件，不结束桌面进程。此时要回答的是：

是插件不可见，还是运行时不可用？
是当前任务缺工具，还是所有新任务都缺工具？
最近一次失败发生在包复制、运行时启动，还是任务注入阶段？

2. 修复用户态缓存与稳定指向

如果官方插件版本目录存在，但稳定入口缺失，应优先修复用户目录内的缓存和版本指向。不要把“重新安装插件”当作万能答案，因为插件文件存在时，重复安装并不能修复运行时注入。

3. 清理过期的任务专用管道配置

任务专用的本地管道名称不应长期写死在全局配置里。旧值可能把新任务绑定到已经不存在的传输端点。

安全做法是：

先备份配置；
只定位 node_repl 的环境变量区段；
只删除已确认过期的管道键；
保留其他插件和运行时配置；
默认先做 dry run，明确确认后才写入。

4. 避免修改受保护的系统包

不要把以下操作当作常规修复：

接管 WindowsApps 权限；
直接替换应用包文件；
修改应用签名；
安装来源不明的重打包版本；
从修复任务内部强行结束桌面端。

如果官方包状态异常，优先使用 Windows 设置中的“修复”功能，并在操作后重新检查包状态。

5. 用真实用户环境验证

受限沙盒里出现的进程启动失败，不一定代表真实桌面环境也失败。最终验证应在正常用户环境完成，并使用新任务分别确认 Browser、Chrome 和 Computer Use，而不是用一个表面的成功代替三项证据。

我把脚本做了哪些安全收缩

配套仓库只发布两个小脚本：

只读健康检查；
默认 dry run、只清理过期管道键的最小修复。

它们不会修改 WindowsApps、应用签名、ACL、浏览器资料或认证文件，也不会结束 Codex Desktop。仓库地址：

Codex Desktop Plugin Repair Safety Kit

运行前仍应逐行审阅。系统更新可能改变实现细节，任何自动化脚本都不应被当作永久有效的万能补丁。

安全发布清单

写类似复盘时，我会在发布前逐项检查：

没有邮箱、真实姓名、账户 ID、任务 ID和私人目录；
没有令牌、Cookie、API Key、OAuth 信息或完整配置；
没有可复用的本机哈希、管道名和备份路径；
没有教读者绕过系统签名或权限边界；
示例默认只读，写操作必须显式确认；
错误响应不向公网返回内部异常细节；
Git 历史中也没有曾经提交过的秘密。

结论

这类故障最重要的经验不是某一条命令，而是分层判断：

插件可见性 → 本地运行时 → 任务启动注入 → 新任务实测。

按这个顺序排查，可以减少无效重装，也能避免为了“尽快可用”而扩大修改范围。修复完成的标准始终是新任务里的真实行为，而不是一张插件列表截图。