上个月我在一台 Windows 11 工作机上折腾 Codex，登录、跑普通问答都没问题，结果第一次切到 computer-use 模式，界面直接弹出一行红字：computer-use 插件不可用。我第一反应是 Codex 桌面版坏了，于是卸载重装、换版本，折腾了快两个小时，问题原样躺在那。后来静下心翻日志才发现，报错根本不是 Codex 逻辑层面的问题，而是 Windows 环境缺了几个它默认不会帮我装的运行条件。
这篇就把我验证过的排查链路和修复步骤完整写下来，给同样在 Windows 上栽过跟头的人一个能直接抄的作业。文章适用于 Codex 桌面版和 CLI 版，重点讲 computer-use 插件的不可用报错。如果你是刚在 Windows 上装完 Codex、或者装了之后发现功能残缺，照着走一遍会有收获。
1. 先搞清楚 computer-use 插件在 Windows 上到底依赖什么
很多人拿到“插件不可用”的第一反应是去设置里找插件商店，看看是不是缺了一个开关，实际上理解偏了。这个报错牵扯到的不是“装一个组件”这么简单，而是 Windows 环境对自动化操作的支持链路。
1.1 它不是传统意义上的“插件商店插件”
computer-use 不是像浏览器扩展那样可以从商店单独下载的东西。它是 Codex 内置的自动化操作组件，官方把它封装成一个“插件”式的功能入口，用来调用系统自动化接口、驱动鼠标键盘、读取屏幕内容，然后交给模型做决策。
换句话说，它更像是一把钥匙，Codex 本身有这把钥匙，但 Windows 这把锁必须配合到位才能打开。所以当它报“不可用”时，多半不是钥匙丢了，而是锁孔被环境问题堵住了。这个比喻在后面的排查里会反复用到——你修的不是 Codex，而是它运行所依赖的 Windows 环境。
为什么 Windows 上特别容易出这个问题？因为 macOS 和 Linux 的自动化权限模型和 Windows 完全不同。macOS 有“辅助功能”权限授权，Linux 走 X11/Wayland 接口，Windows 则依赖 PowerShell、COM 组件、以及图形会话权限。Codex 在 Windows 上要实现 computer-use，需要同时拿到终端执行权和图形界面的操作权，任何一环不通，它就给你一个“插件不可用”的统一报错。这也是为什么同样的 Codex 版本在 macOS 上跑得好好的，换到 Windows 就各种问题。
1.2 Windows 上最容易缺的四个运行条件
我把现场看过的问题分类整理了一下，基本能锁定在这几项：
| 检查项 | 常见缺失原因 | 报错时的典型症状 |
|---|---|---|
| WebView2 运行时 | 精简版系统或旧系统未安装 | 桌面版部分面板白屏，插件状态异常 |
| PowerShell 7+，即 pwsh | 只自带 Windows PowerShell 5.1 | computer-use 无法执行自动化脚本 |
| PowerShell 执行策略 | 策略为 Restricted | 插件脚本被拒绝运行 |
| 用户目录或安装路径 | 含中文或空格较多 | 组件 dll 加载失败，抛通用错误 |
你可能觉得奇怪，为什么 Codex 安装的时候不把这些一起搞定？这里有个现实原因：Codex 官方对 Windows 的支持本来就在持续完善过程中，很多组件它默认假设你已经具备。它会在运行时检查关键依赖，检查不通过就直接禁用插件，而不是给你一个很具体的错误码。这就导致很多人以为是自己配置里的某个神秘开关有问题，实际上只是环境没到位。
所以排查的第一步，就是把这些基础条件先过一遍。不要一上来就怀疑配置，更不要一上来就重装系统。
2. 报错现场与初步定位：别急着重装，先看日志
那段时间我在网上搜这个问题，能看到大量相同报错的帖子，但很多答案要么是“重装解决”，要么是“等官方修复”，基本没有可操作的步骤。其实这个报错是有规律可循的，关键在于先定位问题到底出在系统环境层，还是 Codex 配置层。
2.1 我遇到的报错原文与触发场景
我的环境是 Windows 11 工作站、Codex 桌面版（近期版本），之前跑普通对话、代码生成都很正常。问题发生在新建会话后切换 computer-use 模式：界面会多出一栏让 AI 操作电脑的提示，我照正常流程发了一句“打开计算器并告诉我界面情况”，消息发出去不到三秒，发送框按钮变灰，顶部弹出红色提示：computer-use 插件不可用，请检查插件配置。
我反复试了几次，普通对话都是好的，只要一切 computer-use 就不行。这个“其他功能正常、只有插件异常”的现象，很容易让人怀疑是模型权限或账号的问题。但其实可以做一个简单区分：如果账号或模型权限不足，报错信息里通常会包含 plan、model、not allowed 这类字样；如果只是提示“插件不可用”，大部分时候是本地组件或者配置没有加载成功。这一点是我后续排查中验证过的经验，可以当作判断方向的第一把尺子。
当时我差点就按帖子里的建议去重装 Codex 了。但转念一想，如果是配置问题，重装也解决不了，因为用户级的配置会保留在系统里，重装根本清不掉。事实证明这个判断是对的。
2.2 用一条命令和两处日志锁定问题性质
我的排查主线是：先确认 CLI 环境下插件是否可用，再看日志报错指向哪一层。这样能快速区分是桌面版集成问题，还是 Codex 本身在这台机器上就没有完整能力。
第一步，在终端里直接输入命令：
codex computer-use --help如果 CLI 能正常输出帮助信息，说明 Codex 核心还没坏；如果 CLI 也报不可用，那基本可以确定是环境依赖问题，而不是桌面版 UI 的锅。我当时的情况是 CLI 同样报错，所以直接绕过桌面版，开始翻日志。
Codex 的运行日志通常在这两个位置：
- CLI 日志：
%USERPROFILE%\.codex\logs\，文件名一般是按日期生成的.log文件 - 桌面版日志：
%LOCALAPPDATA%\Codex\logs\，也可以在应用的“设置/帮助”里找日志导出入口
日志文件比较大，不要从头翻，直接用文本编辑器搜索关键词。我用的关键词和对应的判断逻辑如下：
| 日志搜索关键词 | 可能指向的问题 |
|---|---|
computer-use | 插件自身加载状态 |
plugin | 插件注册、启用流程 |
denied/failed | 权限或执行被阻止 |
execution policy | PowerShell 执行策略问题 |
pwsh/powershell | 终端运行时缺失 |
DllNotFound | 组件或 VC++ 运行库缺失 |
结果我在日志里看到两处关键记录：一处是找不到pwsh，另一处是脚本执行被策略阻止。看到这两条我基本就明白了——不是 Codex 的问题，是这台 Windows 缺 PowerShell 7 且执行策略太保守。
如果你想更快判断，不用翻日志，直接在 PowerShell 里跑一行命令：
Get-Command pwsh能正确返回路径，说明 pwsh 存在；如果报“找不到命令”，那问题基本锁定。这个命令我后面每次排查环境问题都会先用，几秒钟就能筛掉一大半可能。
3. 已验证的完整修复流程（Windows 11 实测通过）
下面的步骤是我在真实环境里完整走过的顺序，建议按顺序执行，不要跳。每一步都有存在的必要，少一步都可能反复出问题。这套流程在 Windows 11 23H2 和 24H2 两台机器上都验证过，可以放心参考。
3.1 第一步：补齐运行组件和 PowerShell 环境
先装 WebView2 运行时。虽然 Codex 桌面版自带了一部分相关组件，但有些精简版系统把它裁掉了，导致插件检测逻辑误判“不可用”。去微软官方站点下载 Evergreen 版，安装时选择“在此设备上安装”，装完重启一次。
然后装 PowerShell 7。这是 computer-use 在 Windows 上执行自动化任务的核心，很多调用直接走pwsh，而不是系统自带的powershell.exe。有 winget 的话直接跑：
winget install --id Microsoft.PowerShell --source winget如果没有 winget 或者安装失败，可以去 PowerShell 的 GitHub Releases 页面下载.msi安装包，安装时勾选“添加到 PATH”。
装完之后打开一个新的终端窗口，验证一下：
(Get-Command pwsh).Source能出现类似C:\Program Files\PowerShell\7\pwsh.exe的路径就算成功。这里有个小坑：如果在已经打开的终端里执行，PATH 可能还没刷新，必须重开终端才能生效。我第一次装完就吃了这个亏，在旧终端里反复敲命令都提示找不到，还以为装失败了。
3.2 第二步：修改 Codex 配置里的插件开关
环境组件就位后，还要确认配置层面确实启用了 computer-use。Codex 的配置文件一般在用户目录下：
%USERPROFILE%\.codex\config.toml如果没有这个文件，先启动一次 Codex 让它自动生成，或者直接新建。打开后，找到插件相关段落。不同版本对这一块的字段命名略有差异，我见过两种常见写法：
# 写法一：独立插件段 [plugins] [plugins.computer-use] enabled = true# 写法二：功能开关 [features] computer_use = true如果你的配置文件里已经有类似段落，只是值是false，改成true保存；如果整个段落都不存在，直接手动追加。注意，追加前最好备份原文件：
copy %USERPROFILE%\.codex\config.toml %USERPROFILE%\.codex\config.toml.bak因为每个版本对未知字段的容忍度不同，改坏了会影响到 Codex 整体启动。改完配置后，还有一步容易被忽略：检查%USERPROFILE%\.codex目录的权限，确保当前用户有完全控制权。有些系统迁移工具会把用户目录的 ACL 搞乱，导致 Codex 能读配置但写不进去，表现就是“配置改了不生效”。
3.3 第三步：修正执行策略与文件权限
PowerShell 执行策略这一步很重要，我最初就是卡在这里。默认策略如果受限，脚本路径会被直接拦截，日志里只显示插件加载失败，不会提示具体是哪一步。这会让排查的人以为问题出在插件本身。
以管理员身份打开 PowerShell，执行：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser解释一下这个命令的含义：RemoteSigned表示本地脚本可以运行，从互联网下载的脚本需要有签名。对日常开发来说这是比较合理的折中，不建议改成Unrestricted，那会把安全等级拉得太低。-Scope CurrentUser表示只对当前用户生效，不需要动系统级设置，权限也更收敛。
顺便检查一下系统安全软件的拦截记录。Windows 安全中心的“保护历史记录”里如果有 Codex 相关的拦截项，需要手动允许，并把%USERPROFILE%\.codex、%LOCALAPPDATA%\Codex加入白名单。第三方安全软件同理。这一步看着像小题大做，但实际环境里很常见——安装包、脚本、缓存文件都容易被误杀，而误杀后 Codex 并不会给出“文件被安全软件删除”的明确提示，只会笼统地报插件不可用。
3.4 第四步：清缓存重启并做最小功能验证
前三步做完，还不能马上算完。因为 Codex 之前已经在“插件不可用”的状态下运行过，缓存里很可能存了上一次的异常状态，直接重启可能还会读到旧数据。我当时的做法是：
- 完全退出 Codex，包括托盘残留进程；
- 删除目录
%USERPROFILE%\.codex\cache（如果存在）； - 重新打开 Codex，等待它完成初始化。
然后做一次最小功能验证。这里不要上来就让它操作复杂的业务系统，给一个非常简单、没有破坏性的任务：
打开系统自带的计算器，然后用文字告诉我你看到了什么界面。如果这一步能正常完成，说明插件链路已经通了，AI 能看到屏幕并且能够调用系统操作。此时再切回 computer-use 模式，不再出现“插件不可用”，就代表修复成功。如果任务执行到一半中断，多数还是权限弹窗或安全软件拦截，回到 3.3 步检查白名单。
如果最小验证通过了，再渐进式加任务复杂度。比如让它打开记事本输入一段文字，再让它打开浏览器访问一个具体页面。这样每一层都验证一遍，能确定到底是哪一环还没有完全打通。
3.5 折腾到最后仍报错时的两个备选路径
如果到这里仍然不可用，还有两个经过验证的备选方向。
第一个是改用 WSL 跑 Codex CLI。WSL 里的 Linux 环境对 computer-use 的支持更成熟，因为它的自动化接口和系统权限模型更接近开发容器。装好 WSL 后，在里面正常安装 Codex、登录，再把工作目录挂载进去用。缺点是不能像桌面版那样直接操作 Windows 桌面应用，适合以终端操作为主的使用方式。
第二个是退回上一个 Codex 版本。有段时间我在升级到某个新版本后插件突然不可用，退回到旧版本就正常了。这说明官方在 Windows 插件的兼容性上仍然会有回退情况，遇到版本引发的问题不要死磕，直接换稳定版本。
这两个方案不需要一开始就用，先按主线流程走。如果主线流程走完依然报错，再考虑切换环境。
4. 修好之后：Windows 上继续用 Codex 的注意事项
问题解决之后，我复盘了整个过程，发现很多问题其实在安装阶段就能避开。这一节写一些真实使用中的心得体会，可以帮你少走弯路。
4.1 安装阶段就该避开的坑
第一，安装 Codex 时不要改默认安装路径，尤其不要装到带中文的目录里。组件加载容易出问题，报错还很隐蔽，你可能完全想不到是路径字符的问题。第二，安装时如果遇到“安装未完成”之类的情况，先去看安全软件的拦截记录，把被删除的文件还原，再重新安装，而不是反复双击安装包。第三，第一次启动后先去“设置”里看有没有版本更新，有就更新到最新版再使用，很多早期版本对 Windows 的支持是不完整的。
另外，如果你用的是绿色版或便携版 Codex，遇到插件问题会更多。这类版本绕过了安装器的环境检测，系统缺什么它不会帮你补，只能在运行时报错。能用安装版就尽量用安装版。
如果你准备用 Codex 做长期开发，建议把%USERPROFILE%\.codex这个目录做一份备份。这里面有你的配置、登录信息、模型偏好设置，重装系统后可以直接恢复，不需要重新配置半天。
4.2 computer-use 在实际操作中的能力边界
修复之后我实际用了两周，确实方便，但必须知道它的能力边界。computer-use 依赖屏幕画面做决策，如果显示器设置了缩放比例，或者软件做了高分屏适配，AI 看到的坐标和实际点击位置可能对不上，点错按钮是常有的事。所以让它操作重要界面之前，最好先把显示缩放调成 100%，或者选一个简单的窗口环境。
这里有一个真实例子：我让 computer-use 帮我操作一个内部管理系统，系统做了 125% 缩放，模型每次定位左侧菜单都会偏几个像素，最后点到了相邻功能。把系统显示缩放调成 100% 之后，同样的操作就正常了。
还有一点，computer-use 在 Windows 锁屏状态下无法工作，它需要实时的桌面会话。我一开始以为挂机让它跑就行，结果回来一看任务早中断了。用的时候要把系统睡眠和锁屏都关掉，不然长任务随时会断。电源设置里把“睡眠”改成“从不”，屏幕可以关，但系统不能睡。
更需要注意的是，不要让 computer-use 去执行涉及支付、登录、删除等敏感操作。它在设计上会读取屏幕全部信息，包括你可能不想让它看到的内容，在公共场合或共享屏幕上使用要特别小心。这不是危言耸听，我实际用的时候，它会抓取整个屏幕上所有窗口的画面，聊天记录、密码管理器弹窗这些都会进入模型上下文。
4.3 容易误判的“假修复”：重启后又失效
最后说一个我踩过的坑。第一轮修复完成后，当天用着一切正常，第二天重启电脑后又回到“插件不可用”。当时差点以为修复流程是骗人的，排查后发现两个原因：一是环境变量没有持久化，PowerShell 更新的 PATH 在某些环境下没能写入系统级 PATH；二是安全软件在重启后重新锁定了缓存目录。
解决办法是：把每步验证命令写成一个 PowerShell 脚本，放到启动目录或者手动执行：
# codex-env-check.ps1 Get-Command pwsh | Out-Null Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force每次开机后跑一次，确认环境就绪再打开 Codex。这样看起来多一步，但能彻底避免“重启失效”的问题。修好之后我又用了半个月，再也没出现过一次插件报错。
最后说一点个人体会。这次排查让我养成一个习惯：遇到 Codex 或者其他开发工具的异常，先翻日志，再重装。很多人一报错就卸载重装，浪费时间不说，还容易把有用的本地配置一起冲掉。如果你在 Windows 上正好卡在 computer-use 插件不可用这个问题上，按第 3 章的顺序走一遍，五分钟内大概率能解决。我自己现在重装完系统后的第一件事，就是先把 PowerShell 7、WebView2 运行时和执行策略这三样装好配好，再装 Codex，之后再也没出现过这个报错。这个顺序，比任何插件开关都管用。
