10 月 23 日到 10 月 29 日，六天，Codex CLI 发了三个 stable 版本：v0.164.0、v0.165.0、v0.166.0。

这是 OpenAI「28 Days of Shipping」冲刺的收尾段，节奏是一周一到两个大版本。功能上确实有货：企业 MCP 认证、GCP Vertex AI 内置、GPT-6.1 Terra、OpenTelemetry 接入。

同一段时间里，Windows 用户连着挨了三次，每次都在 stable 发布后 48 小时内爆出来。

v0.164.0：删文件，和一天崩三十次#

v0.164.0 在 10 月 23 日 04:48 UTC 上线。几个小时内，社区出现两个 Windows 侧的 P0 报告。

最要命的是第一个：agent 在执行任务的过程中，把工作区里的文件删了。不是用户批准过的删除操作，是沙箱清理例程的副作用。这个帖子只有三条回复就被分诊了，但它指向的问题很硬：沙箱权限模型在 Windows 上守不守得住。

第二个是 Codex Desktop 自己退出，一天三十次以上。这不是边角场景，是拿它当日常工具就没法用。

同一波里还有别的平台的事故：macOS 的 TUI bootstrap 报 -32603，Linux 在搜索和 resume 任务时内存冲到 47 到 49 GB，直接 OOM。三个平台在 24 小时内一起出问题，这个宽度更像发布前测试有缺口，不太像某个平台自己的老毛病。

后来 v0.165.0-alpha.1.1 补了 Windows MCP 沙箱修复，说明删文件那件事的根追到了沙箱层。

v0.165.0：在 VS Code 里起不来#

v0.165.0 在 10 月 27 日 20:09 UTC 上线。第二天，一个新的 Windows 问题攒到 35 条评论，被标成 blocking。

现象很干脆：Windows 上 VS Code 1.143.1 里从扩展面板启动 Codex，起不来。不报逻辑错误，就是初始化不了。

绕法是别在 IDE 里启动，改从 Windows Terminal 或 PowerShell 直接跑 codex。

这件事有两个成因叠在一起：VS Code 1.143.1 改了扩展宿主 API，Codex CLI 的 Windows 扩展集成在这个版本上没被测过。这种回归，一个基础的 Windows 集成测试矩阵就能拦住。它还是发出去了，说明要么测试套件里没有 VS Code 集成这一项，要么没在对应的 VS Code 版本上跑。

v0.166.0：旧问题没修，新的更狠#

v0.166.0 在 10 月 29 日 19:47 UTC 上线。48 小时内，两个 Windows 问题拿到了大量关注。

一个是上面那个 VS Code 启动失败，过了两个版本还没修，评论涨到 42 条、39 个赞。

另一个是新的，也更麻烦：taskkill.exe 和 conhost.exe 进程失控，把整台机器拖卡死，Windows 10 和 Windows 11 都有报告。两天时间 44 条评论、27 个赞，是冲刺结束后关注度最高的新报告。

同批还有一个 Linux 桌面的小事故：UKUI 加 Wayland 环境里粘贴失效，绕过办法是启动前把环境变量摘掉。

unset WAYLAND_DISPLAY
codex

为什么总是 Windows#

三个原因，跟「开发者不小心」没关系。

Windows 在 Codex 这边是个集成面，不是一等编译目标。 构建和测试的主体在 Linux 上跑。Windows 的二进制照发，沙箱照跑，但接缝特别多：npm 分发渠道、VS Code 扩展 API、Windows 沙箱的进程树管理、Windows 代理认证、还有和 conhost.exe、taskkill.exe 打交道的系统进程层。每一道缝都可能让 Linux 上通过的测试掩盖掉 Windows 上的失败。

这三次事故落在不同的缝上，没有统一根因，共同条件只有一个：Windows 的测试覆盖跟不上发布节奏。

冲刺把预发布窗口压薄了。 v0.165.0 从 alpha 到 stable 大约四天，v0.166.0 大约两天。一个两周才跑得完的测试周期，赶不上三天就毕业的版本。这是权衡，不是失误，冲刺确实换来了竞争力。但冲刺速度和平台可靠性在打架，Windows 在这一轮里承担了不成比例的代价。

进程管理层是最脆的一块。 taskkill 和 conhost 失控这件事，性质跟前两个不一样。它已经不在 Codex 的错误范畴里，而是操作系统层面的进程管理被带崩了。这类问题在 CI 里最难复现，对用户最烦：机器卡死的时候，你不知道该怪谁。

Bazel 从源码编译 V8，修了什么#

v0.166.0 顺带换了个构建底座：Bazel 现在从源码编译 V8，不再用预编译好的 blob。changelog 把这条写成提升 Windows 二进制可靠性。

这话对，但范围窄。

之前用预编译 V8 blob，这个 blob 和各平台二进制其余部分可能是不同版本的 MSVC 或 Windows SDK 编出来的，ABI 一旦错位，V8 在 Windows 上的运行时行为就会飘，飘的方式还不确定，离开那个特定的构建环境根本复现不了。改成源码编译，这类错位风险没了，构建也能从源码复现，好调试、好二分。

它没有解决的问题：VS Code 1.143.1 的启动失败还开着，taskkill 失控还开着，UKUI 的粘贴问题只有绕法没有修复，Windows 测试覆盖的缺口更是原封不动。地基修好了不等于房子修好了。

现在 Windows 用户怎么用#

到 11 月 1 日的状态：

问题状态临时办法
VS Code 1.143.1 启动失败未修，42 条评论从 Windows Terminal 或 PowerShell 启动
taskkill / conhost 失控未修，44 条评论重启 Windows Terminal，盯任务管理器
UKUI Wayland 粘贴失效未修启动前 unset WAYLAND_DISPLAY
桌面版反复自退出v0.165.x 起视为已解决升到 v0.166.0
删工作区文件靠沙箱修复处理升到 v0.166.0

我的建议：

  • 锁在 v0.166.0，别追 v0.167.0 的 alpha。冲刺刚结束，alpha 的新风险没人替你兜。
  • 短期从 Windows Terminal 启动，别把 IDE 面板当唯一入口。
  • 在 Windows 上跑长任务的时候，任务管理器留个眼睛给 taskkill.exe 和 conhost.exe。
  • 撞上过删文件的，把重要工作区先纳入 git。清理逻辑出过事，指望它「不会动我的文件」不是个策略。

一点自己的看法#

一个工具连着三次在同一个平台上翻车，真实的代价不在修 bug 本身，在用户对「升级」这件事的预期被改掉了。原来是升级换新功能，现在变成升级前先去 issue 区看一圈。这个预期一旦形成，团队就开始锁版本、推迟升级，工具的功能优势会被部署延迟一点点吃掉。对一个靠版本迭代抢市场的工具来说，这笔账比单个 P0 更贵。

对个人开发者，有两条实操上的分法值得记住。CLI 在 Terminal 里稳，不代表 IDE 集成稳，这两条链路的测试水平经常差一个量级，评估稳定性要分开看。版本固定比追新值钱，尤其当你的 CI 脚本、codex exec 流水线都挂在某个具体版本上的时候，一次「顺手升级」能让你一个上午都在查为什么跑不通。

判断一个 agent 工具成熟到什么程度，功能列表没什么用，看回归的平均存活时间。这次 VS Code 那个启动失败，从 v0.165.0 到 11 月 1 日一直开着，跨了两个版本。这个数字比 roadmap 诚实。

Bazel 编译 V8 是打地基的正确一步。但地基不等于房子，缺的还是 Windows 的冒烟测试、VS Code 版本矩阵，以及一个明确的 Windows 可靠性指标。「三个版本三次回归」到底是冲刺期的偶然，还是长期欠账的常态，就看这几样东西补不补。

参考来源：Three Releases, Three Windows Regressions: Codex CLI’s Persistent Platform Reliability Problem，Daniel Vaughan，2026 年 11 月 1 日发布，11 月 3 日更新。