【Bug已解决】Codex Desktop 报错 Computer Use 插件不可用的解决方案
1. 问题描述
在 Codex 桌面客户端中打开"设置 → 电脑操控（Computer Use）"功能时，发现该插件完全不可用：
Computer Use 插件不可用 插件列表中找不到 computer-use即使更新到最新版本的 Codex 客户端，这个问题依然存在。
1.1 具体现象
- 插件设置页面中，
computer-use这一项完全不在列表里，而不是"存在但报错" - 尝试卸载重装 Codex App，问题依旧
- 更换了网络环境（比如换了不同的网络节点）也不起作用
- 部分用户反馈用某个特定提示词让 Codex 自己检测并修复插件环境后，问题反而解决了
这个问题在Windows 平台上出现的频率明显高于 macOS，本质并不是"没有安装该插件"，而是客户端内置（bundled）的插件资源没有被正确解包或注册到当前用户的运行环境中。
2. 原因分析
Codex Desktop 的部分高级功能（比如 Computer Use、Chrome 浏览器插件）是以"内置资源包"的形式随主程序一起分发的，理论上不需要用户单独下载安装。但这套内置资源在客户端启动时需要经过一次本地解包、注册到插件市场（marketplace）索引的过程，这个过程可能因为各种原因失败或不完整：
| 原因分类 | 具体表现 |
|---|---|
| 自动更新过程中断 | 更新到一半被打断，导致部分内置资源没有正确写入 |
| 本地插件缓存损坏 | 之前的异常退出导致缓存索引文件处于损坏状态 |
| 市场索引未正确加载 | 插件市场的本地元数据没有正确刷新，导致内置插件"查不到" |
| 多版本残留冲突 | 卸载旧版本时未完全清理，新版本安装后与残留文件冲突 |
用一张流程图梳理该功能的初始化流程：
Codex Desktop 启动 ↓ 检查本地插件市场索引是否包含内置插件（Computer Use / Chrome 扩展） ↓ 索引是否完整、有效？ ├─ 完整 → 插件正常显示并可用 └─ 不完整/损坏 → 插件列表中缺失该项，显示"不可用"3. 解决方案
方案一：让 Codex 自身检测并修复插件环境（社区验证有效的方式）
在 Codex 对话框中直接发送一句明确的诊断提示，让 AI 辅助自动检查并尝试修复本地插件环境：
请检查我的 Codex 客户端本地插件市场索引是否完整， 如果 computer-use 或其他内置插件缺失，帮我定位并修复相关的本地缓存/索引文件。这种方式的原理是让 Agent 结合自己对本地文件系统的读写能力，主动排查并尝试修复索引文件，很多用户反馈这种"让工具自己修自己"的方式效果出乎意料地好。
方案二：完全退出进程后清理本地插件缓存重新启动
# 1. 通过任务管理器彻底结束所有 Codex 相关进程 # 2. 定位并清理本地插件缓存目录（具体路径以官方文档说明为准） Remove-Item -Recurse -Force "$env:APPDATA\Codex\plugins-cache" # 3. 重新启动 Codex Desktop，让它重新初始化插件索引方案三：卸载重装时确保彻底清理残留文件
# 卸载后，手动确认以下目录已被清空，避免残留文件影响新安装 # %APPDATA%\Codex # %LOCALAPPDATA%\Codex # 确认清理干净后，重新下载安装最新版本方案四：检查是否有安全软件拦截了插件解包过程
部分安全软件/企业终端防护策略会拦截程序在首次启动时对某些目录的写入操作，导致内置插件解包失败。可以临时在安全软件中为 Codex 添加信任例外，观察问题是否消失。
方案五：确认当前账号/订阅是否支持该功能
Computer Use 属于相对高级的功能，不同订阅套餐或账号地区可能存在功能开放范围的差异，建议先确认官方文档中该功能对当前账号类型是否明确支持，排除"确实不在开放范围内"这种可能性。
4. 各方案对比总结
| 方案 | 适用场景 | 推荐指数 |
|---|---|---|
| 让 Codex 自查修复 | 首选的快速尝试方式 | ⭐⭐⭐⭐⭐ |
| 清理插件缓存重启 | 明确怀疑是本地缓存损坏 | ⭐⭐⭐⭐ |
| 彻底卸载重装 | 前两个方案无效时的进阶方案 | ⭐⭐⭐⭐ |
| 检查安全软件拦截 | 企业电脑/装有严格安全软件的环境 | ⭐⭐⭐ |
| 确认账号权限范围 | 排除功能本身未开放的可能性 | ⭐⭐⭐ |
5. 常见问题 FAQ
5.1 Chrome 浏览器插件不可用，是同样的原因吗？
是的，Chrome 扩展和 Computer Use 都属于 Codex Desktop 的内置插件体系，遇到"插件列表缺失"或"显示未连接"的问题，排查思路和处理方式基本一致，都可以参考本文的方案。
5.2 macOS 用户几乎不会遇到这个问题，是为什么？
社区反馈中，这个问题在 Windows 平台上出现的比例明显更高，可能与 Windows 平台的文件写入权限模型、安全软件生态更复杂等因素有关，具体底层原因以官方后续说明为准。
5.3 让 Codex 自查修复听起来有点"玄学"，靠谱吗？
这个方式本质上是让 Agent 利用其文件读写和命令执行能力，去检查本地已知的插件相关目录和索引文件是否完整/损坏，属于合理的自动化诊断手段，并不是无根据的"玄学操作"，但结果依赖于当前版本 Agent 对这类本地环境问题的处理能力。
5.4 企业统一部署的电脑，能不能提前避免这个问题？
如果是批量部署场景，建议在标准化的镜像/部署脚本中，提前确认好目标环境的安全软件白名单配置，并在部署完成后统一跑一次功能验证清单，而不是等每个员工各自使用时才发现问题。
5.5 排查清单速查表
□ 1. 尝试让 Codex 自身检测并修复本地插件索引 □ 2. 完全退出进程后清理本地插件缓存目录 □ 3. 卸载重装时确认相关目录已彻底清空 □ 4. 检查安全软件是否拦截了插件解包过程 □ 5. 确认当前账号/订阅是否真正支持该功能6. 总结
Codex Desktop 报Computer Use 插件不可用的本质是客户端内置的插件资源在本地未被正确解包或注册到插件市场索引中，而不是真的缺少安装包。核心处理思路：
- 优先尝试让 Codex 自身检测并修复本地插件环境，这是社区验证过效果不错的快捷方式；
- 如果无效，考虑清理本地插件缓存或彻底卸载重装，排除残留文件的干扰；
- 企业受限电脑注意排查安全软件的拦截，这是容易被忽视的一个环节。
最佳实践建议：遇到"客户端内置功能却显示不可用"这类看起来矛盾的现象时，优先怀疑本地缓存/索引损坏，而不是重复卸载安装包本身，往往能更快找到问题根源。