企业官网建设流程全解析

你装好了 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 环境里的，而是通过 WSL（Windows 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 桌面端版本，最后用一条明确要求“打开网页”的任务做触发测试。三步下来，基本能判断是环境级问题、版本问题，还是工具触发问题。下面这个表是我修的时候用的判断逻辑，你可以对照着来：

这个表动手前看一眼，能省掉很多无用操作。我自己第一次修的时候就是没分清楚类型，跑去改了一堆配置，结果方向错了，越改越乱。

3. 验证过的修复步骤

3.1 第一步：把 WSL 彻底初始化好

我最开始修的时候，以为 Codex 装好了就万事大吉，完全没意识到 WSL 才是关键。后来发现问题恰恰出在这。Windows 上第一次使用 WSL，需要初始化发行版，默认发行版通常是 Ubuntu。如果你之前从没在命令行里跑过wsl --install，或者装了但从未初始化过，Codex 的沙箱就起不来，computer-use 自然不可用。

具体操作按下面这几步来：

1. 打开 PowerShell 或 Windows Terminal，运行wsl --status，看系统是否提示“默认版本：2”之类的信息。
2. 如果提示没有安装，执行wsl --install。这条命令会自动装好 WSL 相关组件，装完按提示重启一次。
3. 如果已经装了 WSL 但没有任何发行版，执行wsl --install -d Ubuntu，把 Ubuntu 装上。
4. 安装完成后，务必进入 Ubuntu 初始化一次用户账户和密码。这一步容易被跳过，但跳过的后果是环境虽然显示存在，实际却没法正常用。
5. 最后执行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 顺畅跑起来。我自己也是花了整整一个晚上才摸清规律，后面再遇到同类问题基本十分钟就能定位。