你装好了 Codex 桌面版兴致勃勃想让它帮你做个带网页操作的任务结果新建会话一看computer-use 一直显示插件不可用点也点不动重启、重装都没改善。这个问题我在 Windows 11 上踩过前后折腾了一晚上才定位到根因。这篇我把验证过的排查思路和修复步骤完整写出来尽量让卡在同样位置的人少走弯路。后面讲的东西我在自己的机器上实际跑过一遍不是纸上谈兵。1. 先说清楚computer-use 在 Windows 上到底是什么1.1 它不是一个独立插件而是一套“操作浏览器的能力”很多人看到“插件不可用”的第一反应是去扩展商店找一个叫 computer-use 的插件结果搜半天搜不到。这是个很大的误区。Codex 里的 computer-use并不是传统意义的浏览器扩展而是 Codex 这个智能体自带的一项工具能力目的是让智能体能够像人一样打开浏览器、输入网址、点击按钮、读取页面内容再根据看到的信息继续执行后续任务。你可以把它理解成给 AI 配了一套“带眼睛和手”的浏览器。实际触发后Codex 会打开一个受控的浏览器窗口每一步操作几乎都能从页面截图里看到。这时候你让它登录后台、批量填表、抓取某个网页上的数据、点完按钮再截图确认结果它都能按顺序执行下去。没有这个能力的话Codex 就只能在本地文件、命令行这类环境里干活遇到网页交互类任务就哑火了。1.2 在 Windows 上它依赖什么运行问题恰恰出在运行环境上。Codex 桌面版在 Windows 上并不是直接跑在原生 Windows 环境里的而是通过 WSLWindows Subsystem for Linux拉起一个 Linux 沙箱再在沙箱里执行代码、启动浏览器、跑自动化流程。也就是说computer-use 是否可用很大程度上取决于底层的 WSL 和沙箱环境是否正常。macOS 上沙箱直接跑在原生环境里大部分用户开箱即用Windows 上要经过“桌面应用 → WSL → 沙箱 → 浏览器工具”这么一条链路中间任何一环出问题最终表现都可能是一样的computer-use 插件不可用。这也是为什么网上同样的报错有人重装 Codex 就好了有人怎么折腾都不行。本质上他们卡住的环节不一样光靠重装永远解决不了环境层的故障。2. 动手前先自查先分清是哪一类“不可用”2.1 三种常见表现我根据这段时间看到的反馈把“computer-use 不可用”大致分成三类。第一类任务面板里直接出现文字提示“Computer use 不可用”或“插件不可用”一般在新建会话之前的环境检查阶段就会弹出来。这种情况大概率是沙箱环境没有起来优先检查 WSL。第二类入口按钮是灰色点击没有任何反应。这类通常是 Codex 版本太旧或者当前会话类型不支持 computer-use。先更新桌面端再回来看入口状态。第三类界面里看起来一切正常你也建了新会话但让 Codex 去打开网页时它只会分析不会操作甚至直接回答“我无法打开浏览器”。这种情况往往不是环境坏了而是没有正确触发到 computer-use 工具或者当前模型、会话配置不允许它调用这个工具。我见过不少人卡在这白白重装了好几次 Codex。2.2 快速定位思路定位的时候我建议按“环境 → 版本 → 触发”这个顺序排查不要一上来就卸载重装。先跑几条命令看 WSL 状态再检查 Codex 桌面端版本最后用一条明确要求“打开网页”的任务做触发测试。三步下来基本能判断是环境级问题、版本问题还是工具触发问题。下面这个表是我修的时候用的判断逻辑你可以对照着来现象优先排查项常见根因提示插件不可用WSL 状态与版本WSL 未初始化或发行版缺失按钮灰色不可点Codex 版本版本过旧缺少对应入口能对话但不会开网页模型与会话配置computer-use 未被正确触发这个表动手前看一眼能省掉很多无用操作。我自己第一次修的时候就是没分清楚类型跑去改了一堆配置结果方向错了越改越乱。3. 验证过的修复步骤3.1 第一步把 WSL 彻底初始化好我最开始修的时候以为 Codex 装好了就万事大吉完全没意识到 WSL 才是关键。后来发现问题恰恰出在这。Windows 上第一次使用 WSL需要初始化发行版默认发行版通常是 Ubuntu。如果你之前从没在命令行里跑过wsl --install或者装了但从未初始化过Codex 的沙箱就起不来computer-use 自然不可用。具体操作按下面这几步来打开 PowerShell 或 Windows Terminal运行wsl --status看系统是否提示“默认版本2”之类的信息。如果提示没有安装执行wsl --install。这条命令会自动装好 WSL 相关组件装完按提示重启一次。如果已经装了 WSL 但没有任何发行版执行wsl --install -d Ubuntu把 Ubuntu 装上。安装完成后务必进入 Ubuntu 初始化一次用户账户和密码。这一步容易被跳过但跳过的后果是环境虽然显示存在实际却没法正常用。最后执行wsl --update把内核更新到最新再执行wsl --shutdown让 WSL 完全重启。我自己的机器就是执行完这套流程后Codex 重新打开就能正常进入 computer-use 了其他配置一个没动。这里也能反向验证如果你连wsl --status都跑不通那基本不用怀疑 Codex 本身先把 WSL 搞定再说。3.2 第二步检查容器运行时和沙箱状态有一部分 Windows 用户电脑上装了 Docker Desktop尤其是平时做开发的人。Docker Desktop 和 WSL 共用底层内核如果 Docker Desktop 处于停止状态或者它的 WSL 集成把默认发行版弄乱了也会影响 Codex 沙箱的启动。这一步不用做太多复杂操作主要是确认状态如果你装了 Docker Desktop确保它已经启动完成最好等托盘图标变绿再试 Codex。没装 Docker 的直接执行wsl --shutdown等几秒再启动 Codex让沙箱重新初始化。多说一句如果你用 Docker Desktop 只是为了日常跑容器不建议为了 Codex 去改它的 WSL 集成设置。我试过在 Docker 的 WSL 集成里改默认发行版结果把 Codex 的沙箱环境搞得更乱最后恢复默认才正常。这里面的经验就是能不动就不动先确保默认状态是干净的再判断是不是真的需要额外配置。3.3 第三步把 Codex 更新到最新版如果你确认 WSL 一切正常computer-use 还是不可用接下来要看版本。Codex 的更新频率不低computer-use 这种预览功能经常跟着版本调整旧版本很可能根本没有对应入口或者功能被禁用。桌面端一般在设置里能看到版本号和更新入口。我建议直接到官网下载最新安装包覆盖安装省得等自动更新。覆盖安装通常不会丢登录状态但如果你发现更新后要求重新登录直接重新登录就好。如果更新后问题依旧可以尝试清理本地缓存再重装。Codex 的缓存目录一般在用户目录下的.codex文件夹。操作前先把登录状态相关的内容备份一下然后删除或改名整个.codex目录再重新打开 Codex 登录一次。这个方法在我自己的场景里没用到因为更新后就恢复了但在网上看到不少人是靠这步解决的尤其是桌面端反复启动异常的情况。3.4 第四步用一条明确的任务验证触发环境修好之后别急着下结论说“插件不可用”。我见过不少用户其实环境没问题只是命令和会话方式没有触发 computer-use。Codex 的 computer-use 不会在每次对话里无条件调用它会先判断当前任务是不是真的需要操作浏览器。验证方法很简单新建一个会话直接给一条明确的任务比如“请打开 example.com把页面顶部的标题截图给我。”如果它能打开浏览器并完成任务说明 computer-use 实际是可用的之前看到的“不可用”只是环境或触发方式造成的问题。如果它回答“我无法打开网页”或者卡在某个调用错误上再回头检查上面的步骤。如果你是用 API 方式接入还要确认请求里用的模型是否支持 computer-use。部分模型或平台配置下这个工具可能不可用这跟桌面端环境没有关系。遇到这种情况换回支持 computer-use 的模型问题通常会消失。4. 修复过程中经常会一起碰到的报错4.1 auth token is unavailable这个报错在重装或更新之后很常见本质是登录态丢失。Codex 找不到本地保存的认证信息请求就断了。解决办法也很直接重新登录一次。如果重新登录后还是同样的报错大概率是本地缓存目录权限有问题可以把.codex目录下认证相关的缓存文件删掉再重新登录一遍。这个报错表面上和 computer-use 没有直接关系但认证不通过时很多工具能力会被联动禁用。所以排查 computer-use 的时候顺手确认下登录状态没有坏处省得绕一大圈最后发现是认证的问题。4.2 模型不支持的报错我在升级后试过一次请求里填的模型名在 Codex 环境里不被支持直接提示该模型不可用。这类问题跟 computer-use 的功能本身无关纯粹是模型配置不对。你只需要检查当前使用的模型改成 Codex 支持列表里实际存在的模型名再重新发起任务就行。4.3 自定义服务地址导致的请求异常如果你之前配置过自定义的服务地址比如用过第三方模型接入工具之后 Codex 的请求可能会报出类似 local proxy failed 或者请求无法到达服务端的异常。这种时候优先检查配置里填写的地址是否还能正常访问最简单的方法是恢复默认配置再测试。这类工具本身不影响 WSL 和沙箱但它是加在 Codex 和模型服务之间的一层转发。一旦配置失效整个请求链路都会断。所以如果你最近改过这类配置又发现 computer-use 不可用先别急着动 WSL把配置恢复默认或重新填写正确地址问题很可能就消失了。我自己遇到过几次请求链路问题最后都是配置残留导致的。5. 最后说点实操中容易被忽略的小事几个小细节我觉得值得单独拿出来提一下因为这些点不只是修 computer-use 才用得上平时长时间用 Codex 也会遇到。第一WSL 会占不少内存和磁盘空间。如果你用 Codex 桌面版做网页自动化沙箱加浏览器的内存占用会明显上升机器容易变得卡顿。遇到这种卡顿别只怪 Codex先看 WSL 的占用跑一下wsl --shutdown释放资源再重新打开 Codex通常会恢复正常。磁盘方面WSL 的虚拟磁盘文件在长时间使用后会膨胀如果你 C 盘空间吃紧可以检查ext4.vhdx文件的大小必要时做清理或压缩。第二项目路径里尽量不要有中文和空格。虽然现在系统对中文路径的支持已经不错但 Codex 的沙箱在 Windows 上多了一层 WSL 转换路径越复杂越容易出怪问题。我习惯把相关项目放在D:\code这样的纯英文路径下后面少惹很多麻烦。第三如果你换了一台机器发现同样的方法不管用先看系统版本和 WSL 内核版本。我排查过很多“别人行我不行”的案例最后大都是 WSL 内核太久没更新或者系统本身缺了某些组件。Codex 对 Windows 底层环境的依赖比想象中重基础组件版本不同表现就可能完全不同。最后再分享一个可以直接套用的办法遇到折腾半天解决不了的情况先执行wsl --update再执行wsl --shutdown然后重启 Codex。这套组合拳虽然简单但在我验证过的大多数 Windows 问题里都是有效的。这个问题的根子并不复杂难的是刚开始不知道要往 WSL 方向排查。希望这篇能帮你把 Windows 上的 computer-use 顺畅跑起来。我自己也是花了整整一个晚上才摸清规律后面再遇到同类问题基本十分钟就能定位。
你装好了 Codex 桌面版兴致勃勃想让它帮你做个带网页操作的任务结果新建会话一看computer-use 一直显示插件不可用点也点不动重启、重装都没改善。这个问题我在 Windows 11 上踩过前后折腾了一晚上才定位到根因。这篇我把验证过的排查思路和修复步骤完整写出来尽量让卡在同样位置的人少走弯路。后面讲的东西我在自己的机器上实际跑过一遍不是纸上谈兵。1. 先说清楚computer-use 在 Windows 上到底是什么1.1 它不是一个独立插件而是一套“操作浏览器的能力”很多人看到“插件不可用”的第一反应是去扩展商店找一个叫 computer-use 的插件结果搜半天搜不到。这是个很大的误区。Codex 里的 computer-use并不是传统意义的浏览器扩展而是 Codex 这个智能体自带的一项工具能力目的是让智能体能够像人一样打开浏览器、输入网址、点击按钮、读取页面内容再根据看到的信息继续执行后续任务。你可以把它理解成给 AI 配了一套“带眼睛和手”的浏览器。实际触发后Codex 会打开一个受控的浏览器窗口每一步操作几乎都能从页面截图里看到。这时候你让它登录后台、批量填表、抓取某个网页上的数据、点完按钮再截图确认结果它都能按顺序执行下去。没有这个能力的话Codex 就只能在本地文件、命令行这类环境里干活遇到网页交互类任务就哑火了。1.2 在 Windows 上它依赖什么运行问题恰恰出在运行环境上。Codex 桌面版在 Windows 上并不是直接跑在原生 Windows 环境里的而是通过 WSLWindows Subsystem for Linux拉起一个 Linux 沙箱再在沙箱里执行代码、启动浏览器、跑自动化流程。也就是说computer-use 是否可用很大程度上取决于底层的 WSL 和沙箱环境是否正常。macOS 上沙箱直接跑在原生环境里大部分用户开箱即用Windows 上要经过“桌面应用 → WSL → 沙箱 → 浏览器工具”这么一条链路中间任何一环出问题最终表现都可能是一样的computer-use 插件不可用。这也是为什么网上同样的报错有人重装 Codex 就好了有人怎么折腾都不行。本质上他们卡住的环节不一样光靠重装永远解决不了环境层的故障。2. 动手前先自查先分清是哪一类“不可用”2.1 三种常见表现我根据这段时间看到的反馈把“computer-use 不可用”大致分成三类。第一类任务面板里直接出现文字提示“Computer use 不可用”或“插件不可用”一般在新建会话之前的环境检查阶段就会弹出来。这种情况大概率是沙箱环境没有起来优先检查 WSL。第二类入口按钮是灰色点击没有任何反应。这类通常是 Codex 版本太旧或者当前会话类型不支持 computer-use。先更新桌面端再回来看入口状态。第三类界面里看起来一切正常你也建了新会话但让 Codex 去打开网页时它只会分析不会操作甚至直接回答“我无法打开浏览器”。这种情况往往不是环境坏了而是没有正确触发到 computer-use 工具或者当前模型、会话配置不允许它调用这个工具。我见过不少人卡在这白白重装了好几次 Codex。2.2 快速定位思路定位的时候我建议按“环境 → 版本 → 触发”这个顺序排查不要一上来就卸载重装。先跑几条命令看 WSL 状态再检查 Codex 桌面端版本最后用一条明确要求“打开网页”的任务做触发测试。三步下来基本能判断是环境级问题、版本问题还是工具触发问题。下面这个表是我修的时候用的判断逻辑你可以对照着来现象优先排查项常见根因提示插件不可用WSL 状态与版本WSL 未初始化或发行版缺失按钮灰色不可点Codex 版本版本过旧缺少对应入口能对话但不会开网页模型与会话配置computer-use 未被正确触发这个表动手前看一眼能省掉很多无用操作。我自己第一次修的时候就是没分清楚类型跑去改了一堆配置结果方向错了越改越乱。3. 验证过的修复步骤3.1 第一步把 WSL 彻底初始化好我最开始修的时候以为 Codex 装好了就万事大吉完全没意识到 WSL 才是关键。后来发现问题恰恰出在这。Windows 上第一次使用 WSL需要初始化发行版默认发行版通常是 Ubuntu。如果你之前从没在命令行里跑过wsl --install或者装了但从未初始化过Codex 的沙箱就起不来computer-use 自然不可用。具体操作按下面这几步来打开 PowerShell 或 Windows Terminal运行wsl --status看系统是否提示“默认版本2”之类的信息。如果提示没有安装执行wsl --install。这条命令会自动装好 WSL 相关组件装完按提示重启一次。如果已经装了 WSL 但没有任何发行版执行wsl --install -d Ubuntu把 Ubuntu 装上。安装完成后务必进入 Ubuntu 初始化一次用户账户和密码。这一步容易被跳过但跳过的后果是环境虽然显示存在实际却没法正常用。最后执行wsl --update把内核更新到最新再执行wsl --shutdown让 WSL 完全重启。我自己的机器就是执行完这套流程后Codex 重新打开就能正常进入 computer-use 了其他配置一个没动。这里也能反向验证如果你连wsl --status都跑不通那基本不用怀疑 Codex 本身先把 WSL 搞定再说。3.2 第二步检查容器运行时和沙箱状态有一部分 Windows 用户电脑上装了 Docker Desktop尤其是平时做开发的人。Docker Desktop 和 WSL 共用底层内核如果 Docker Desktop 处于停止状态或者它的 WSL 集成把默认发行版弄乱了也会影响 Codex 沙箱的启动。这一步不用做太多复杂操作主要是确认状态如果你装了 Docker Desktop确保它已经启动完成最好等托盘图标变绿再试 Codex。没装 Docker 的直接执行wsl --shutdown等几秒再启动 Codex让沙箱重新初始化。多说一句如果你用 Docker Desktop 只是为了日常跑容器不建议为了 Codex 去改它的 WSL 集成设置。我试过在 Docker 的 WSL 集成里改默认发行版结果把 Codex 的沙箱环境搞得更乱最后恢复默认才正常。这里面的经验就是能不动就不动先确保默认状态是干净的再判断是不是真的需要额外配置。3.3 第三步把 Codex 更新到最新版如果你确认 WSL 一切正常computer-use 还是不可用接下来要看版本。Codex 的更新频率不低computer-use 这种预览功能经常跟着版本调整旧版本很可能根本没有对应入口或者功能被禁用。桌面端一般在设置里能看到版本号和更新入口。我建议直接到官网下载最新安装包覆盖安装省得等自动更新。覆盖安装通常不会丢登录状态但如果你发现更新后要求重新登录直接重新登录就好。如果更新后问题依旧可以尝试清理本地缓存再重装。Codex 的缓存目录一般在用户目录下的.codex文件夹。操作前先把登录状态相关的内容备份一下然后删除或改名整个.codex目录再重新打开 Codex 登录一次。这个方法在我自己的场景里没用到因为更新后就恢复了但在网上看到不少人是靠这步解决的尤其是桌面端反复启动异常的情况。3.4 第四步用一条明确的任务验证触发环境修好之后别急着下结论说“插件不可用”。我见过不少用户其实环境没问题只是命令和会话方式没有触发 computer-use。Codex 的 computer-use 不会在每次对话里无条件调用它会先判断当前任务是不是真的需要操作浏览器。验证方法很简单新建一个会话直接给一条明确的任务比如“请打开 example.com把页面顶部的标题截图给我。”如果它能打开浏览器并完成任务说明 computer-use 实际是可用的之前看到的“不可用”只是环境或触发方式造成的问题。如果它回答“我无法打开网页”或者卡在某个调用错误上再回头检查上面的步骤。如果你是用 API 方式接入还要确认请求里用的模型是否支持 computer-use。部分模型或平台配置下这个工具可能不可用这跟桌面端环境没有关系。遇到这种情况换回支持 computer-use 的模型问题通常会消失。4. 修复过程中经常会一起碰到的报错4.1 auth token is unavailable这个报错在重装或更新之后很常见本质是登录态丢失。Codex 找不到本地保存的认证信息请求就断了。解决办法也很直接重新登录一次。如果重新登录后还是同样的报错大概率是本地缓存目录权限有问题可以把.codex目录下认证相关的缓存文件删掉再重新登录一遍。这个报错表面上和 computer-use 没有直接关系但认证不通过时很多工具能力会被联动禁用。所以排查 computer-use 的时候顺手确认下登录状态没有坏处省得绕一大圈最后发现是认证的问题。4.2 模型不支持的报错我在升级后试过一次请求里填的模型名在 Codex 环境里不被支持直接提示该模型不可用。这类问题跟 computer-use 的功能本身无关纯粹是模型配置不对。你只需要检查当前使用的模型改成 Codex 支持列表里实际存在的模型名再重新发起任务就行。4.3 自定义服务地址导致的请求异常如果你之前配置过自定义的服务地址比如用过第三方模型接入工具之后 Codex 的请求可能会报出类似 local proxy failed 或者请求无法到达服务端的异常。这种时候优先检查配置里填写的地址是否还能正常访问最简单的方法是恢复默认配置再测试。这类工具本身不影响 WSL 和沙箱但它是加在 Codex 和模型服务之间的一层转发。一旦配置失效整个请求链路都会断。所以如果你最近改过这类配置又发现 computer-use 不可用先别急着动 WSL把配置恢复默认或重新填写正确地址问题很可能就消失了。我自己遇到过几次请求链路问题最后都是配置残留导致的。5. 最后说点实操中容易被忽略的小事几个小细节我觉得值得单独拿出来提一下因为这些点不只是修 computer-use 才用得上平时长时间用 Codex 也会遇到。第一WSL 会占不少内存和磁盘空间。如果你用 Codex 桌面版做网页自动化沙箱加浏览器的内存占用会明显上升机器容易变得卡顿。遇到这种卡顿别只怪 Codex先看 WSL 的占用跑一下wsl --shutdown释放资源再重新打开 Codex通常会恢复正常。磁盘方面WSL 的虚拟磁盘文件在长时间使用后会膨胀如果你 C 盘空间吃紧可以检查ext4.vhdx文件的大小必要时做清理或压缩。第二项目路径里尽量不要有中文和空格。虽然现在系统对中文路径的支持已经不错但 Codex 的沙箱在 Windows 上多了一层 WSL 转换路径越复杂越容易出怪问题。我习惯把相关项目放在D:\code这样的纯英文路径下后面少惹很多麻烦。第三如果你换了一台机器发现同样的方法不管用先看系统版本和 WSL 内核版本。我排查过很多“别人行我不行”的案例最后大都是 WSL 内核太久没更新或者系统本身缺了某些组件。Codex 对 Windows 底层环境的依赖比想象中重基础组件版本不同表现就可能完全不同。最后再分享一个可以直接套用的办法遇到折腾半天解决不了的情况先执行wsl --update再执行wsl --shutdown然后重启 Codex。这套组合拳虽然简单但在我验证过的大多数 Windows 问题里都是有效的。这个问题的根子并不复杂难的是刚开始不知道要往 WSL 方向排查。希望这篇能帮你把 Windows 上的 computer-use 顺畅跑起来。我自己也是花了整整一个晚上才摸清规律后面再遇到同类问题基本十分钟就能定位。
