周一早上，在床上一蹬腿，把腿拉伤了。于是欢天喜地地跟导员请了假，想着终于可以安静地写一上午项目了，而且寝室里还只有我一个人。

结果因为手贱，大半天时间全花在修复 Codex 上了，代码是一点没写……

原因只是因为看到了这个：

一、为什么会切换到 WSL

因为已经用厌了虚拟机，手上的质控项目一直是在 WSL 环境下开发的。

虽然项目的工作路径放在 WSL 环境里，但每次使用 Codex 时，它都无法完全继承 WSL 中的开发环境。

具体表现在环境变量上。

比如运行测试时，程序需要从环境变量中读取真实的数据库连接串，但每次让 Codex 跑测试时，它都没有连接到真实数据库。

一系列因素，再加上刚起床时脑子还有点懵，看到这个选项后，以为可以直接让 Codex 在 WSL 中运行，于是毅然决然地点了下去。

现在回想起来，真想穿越回去抽死那个手贱的自己。

二、重启后 Codex 直接打不开了

点击之后，需要重启 Codex 才能生效。

结果重启之后，Codex 直接打不开了。

原因其实很简单：

Agent 的运行环境被设置到了 WSL 下，但 WSL 中并没有安装 Codex CLI。Codex 检测不到对应路径，自然就无法正常打开。

说白了，还是太想当然了，以为点击这个选项后就可以直接在 WSL 下运行，事先也没有做好功课。

三、尝试修改 .codex-global-state.json

接着，把 .codex-global-state.json 这个文件的后缀改成了 .old。

当时认为，这个文件可能保存了 Codex 的部分启动配置，因此想着在重启之后，Codex 应该可以自动生成新的默认配置。

但这样做之后，问题依然没有解决。

虽然 Codex 确实重新生成了一个新文件，但估计路径配置可能仍然指向 WSL，也有可能问题本身并不完全出在这个配置文件上。

四、通过 Windows 环境变量恢复启动

之后，把 Windows 下的环境变量 CODEX_CLI_PATH 设置为 Codex 可执行文件的路径，Codex 就可以正常打开了。

五、项目列表突然消失

打开 Codex 后，发现之前的 Project 列表在左边全都找不到了，只剩下 Chat 下面还有一些记录。

当时以为之前的历史记录全都没了，特别绝望。

尝试使用历史搜索后，发现仍然可以搜索到之前的历史记录。

既然数据还存在，但左边的项目列表没有出现，就猜测可能是项目路径和历史会话之间的索引映射出了问题。

重新添加原来的工作路径后，之前的项目列表和历史记录就全部重新出现了。

虚惊一场……

六、插件和 Skill 全部无法使用

但紧接着，又发现了新的问题：

插件和 Skill 全都无法使用。

Computer Use 功能也无法正常使用。

七、尝试重建 Computer Use 相关缓存

先是自己捣鼓了一下，把下面三个文件夹改成了 .old 后缀：

computer-use
computer-use-turn-ended
node_repl

再重启 Codex，让它重新生成这些目录。

这一次 Codex 的说法和之前不一样了，说明旧的运行缓存可能确实影响了初始化流程。

但问题依然没有解决，插件和 Computer Use 还是无法正常使用。

八、检查插件文件

之后打开了 plugins 文件夹，检查后发现里面的 JSON 文件并没有明显问题，而且插件也确实已经下载了。

实在没招，只能去 B 站找相关视频。

视频里说，把 plugins 文件夹删除后重启 Codex 就可以了。

为了稳妥，仍然只是给它改了一个 .old 后缀。

重启之后，新的 plugins 文件夹确实重新生成了，但与之前相比，里面少了 chrome 和 computer-use 两个文件夹。

这说明插件缓存虽然重新生成了，但 Chrome 和 Computer Use 插件需要重新下载。

问题就在于，此时打开插件和 Skill 页面，仍然会显示前面那两张图片中的报错。

九、让 Codex 修复自己

随后，在视频评论区看到有人说，可以把思考强度拉满，让 Codex 自己去修复。

这里额外加了一条“禁止自行重启”的要求，因为有些人在评论区说，Codex 在修复过程中把自己给删了。

Codex 跑了四十分钟，最后失败了，中途还遇到了无法压缩上下文的问题。

十、准备重装，但赌徒心理发作

做到这里，已经有点没招了，想着要不直接卸载重装算了。

但前面已经耗费了那么多时间，赌徒心理又不太想这么做。

于是继续在网上翻解决方案。

十一、通过 Skill 修复成功

后来找到了这个 Skill：

https://github.com/chen0416ccc-cpu/codex-windows-fast-patch-skill

把网址发给 Codex，同时加上了“不要卸载自己”的要求。

之后它又跑了四十分钟，神奇的是，这次真的修好了。

十二、这个 Skill 大概做了什么

出于好奇，大致看了一下这个 Skill。

简单来说，这次 Computer Use 的修复过程，大概经历了以下几个步骤。

首先，它修正了 config.toml 中的功能开关，让底层 JavaScript 执行接口重新启用。

接着，它修复了 Computer Use 插件缓存中的 latest 版本指向。

随后，又处理了 @oai/sky 运行时和 Helper 路径。

也就是说，它先让客户端使用正确版本的插件，再保证客户端脚本和 Windows 控制 Helper 都能够正常运行。

最后，它又修复了缓存和 Native Host 路径，主要是为了防止 Codex 重启后再次被旧路径影响。

大致流程可以概括为：

修正 config.toml 功能开关
        ↓
修复插件缓存中的 latest 指向
        ↓
处理 @oai/sky 运行时
        ↓
修复 Windows Helper 路径
        ↓
修复缓存和 Native Host 路径

最后还会经过一些验证,验证通过了应该就没问题了。

最后的最后总结一下, 只能说自己对于这类agent工具还是太不熟悉了,还要多学,多看资料。