WinBridge Recovery 4.0 Preview 1：把“能修”推进到“能解释为什么坏”

WinBridge Recovery 4.0.0-preview.1 已经进入预发布开发阶段。

这次 4.0 的重点不是换一个版本号，也不是单纯给界面加功能，而是把项目从“发现异常后尝试修复”继续推进到一个更重要的方向：先解释故障发生在哪一层，再决定是否需要修。

当前 4.0 Preview 1 仍然是开发预览，不是最终正式版。对应的 4.0 foundation PR 仍处于 Draft，Windows 实机回归测试完成之前，我不会把它描述成已经稳定发布。

为什么 4.0 先做可靠性

真实用户反馈越来越清楚地说明：Windows 上的 Codex Desktop 插件故障很少只是一个简单的“文件丢了”。

问题可能来自：

Windows 主机和系统版本；
当前安装的 OpenAI.Codex AppX 包；
bundled marketplace；
Browser / Chrome / Computer Use 的版本缓存；
latest 指针；
Native Host；
未完成的恢复事务；
深层资源镜像；
正在占用目录的 Chrome / Edge 等进程；
长路径或 Access Denied。

如果只给用户一个“成功”或者“失败”，其实没有解决最重要的问题：到底从哪里开始不一致？

所以 Preview 1 的第一块基础，是一套新的统一预检层。

新增 WinBridge 4.0 Preflight

4.0 新增：

WinBridge-4.0-Preflight.ps1

它会在正常 Diagnose Only 或 Repair And Launch 之前执行一次只读检查，并生成结构化 JSON 报告。

目前报告会覆盖：

Windows build 与系统架构；
Windows PowerShell 版本；
长路径策略；
Launcher 当前路径长度；
磁盘剩余空间；
OpenAI.Codex AppX identity；
官方 bundled plugin 版本；
当前 marketplace 版本；
cache / latest 状态；
Native Host 状态；
pending recovery transaction；
Chrome / Edge 运行状态；
recovery/runtime 关键路径。

这些信息最终会被压缩成一组更容易理解的层级：

host → package → marketplace → cache → native-host → recovery → runtime

First Divergence：第一次偏离发生在哪里

这是我认为 Preview 1 最重要的变化之一。

4.0 Preflight 不只是罗列状态，它还会记录 first divergent recovery layer。

比如一台机器可能是：

Host 正常
Package 正常
Marketplace 正常
Cache 开始出现版本漂移
latest 指向旧版本
Native Host 随后继续引用旧路径

这种情况下，真正需要关注的起点不是 Native Host，而是更早出现偏离的 cache 层。

未来 WinBridge 的 targeted repair 也会以这种一致性模型为基础，而不是看到多个异常就全部重建。

Windows 10 与 Windows 11 主机识别

Preview 1 也开始明确识别 Windows 10 和 Windows 11。

这里必须说明：识别 Windows 10，不等于承诺 Codex Desktop 在所有 Windows 10 版本上都有官方支持。

WinBridge 可以检查一台 Windows 10 主机，也可以判断机器上是否实际存在官方 OpenAI.Codex 包，但上游产品是否为该系统提供可用官方包，仍然取决于官方实际发布状态。

WinBridge 不会为了“兼容”去伪造一个不存在的官方安装环境。

长路径清理重新实现

最近的真实日志还暴露出一个非常典型的 Windows 问题：资源镜像中可能存在很深的 Node.js / pnpm 依赖树。

旧维护流程使用 Remove-Item -Recurse 删除过期镜像时，在超长路径、深层目录或者目录状态变化的情况下可能失败。

Preview 1 已经把维护阶段的深层删除改为使用支持 extended-length path 的 .NET 文件与目录 API，并处理 \\?\ 长路径。

这次改动的目标并不是“暴力删除更多东西”，而是减少一种不合理的失败：

核心恢复已经成功，却因为最后清理一个过期镜像失败，整个 Launcher 被判成失败。

Locked / Access Denied：改成 Deferred Cleanup

如果准备删除的是已经过期的资源镜像，但它暂时被其他程序锁定，或者系统返回 Access Denied，Preview 1 会尽量把它记录为 Deferred Cleanup。

也就是说：

当前活动资源镜像仍然受到保护；
rollback 保证不会被放宽；
只是过期 retention candidate 暂时删不掉时，不再轻易把整次恢复变成总失败；
日志会保留警告，后续仍可继续定位锁定来源。

这和“忽略错误”不是一回事，而是把核心修复结果和维护性清理结果分开表达。

Preflight 目前只是辅助层

4.0 Preview 1 没有直接推翻现有成熟恢复核心。

Preflight 当前是 advisory：负责提前观察、记录和解释状态。

真正执行写入前，现有 recovery core 仍然会进行自己的安全检查，并保持最终权威判断。

这是有意的。

新的诊断模型应该先经过真实 Windows 10 / Windows 11 环境、真实锁文件、真实长路径和真实用户日志验证，再逐步把更多 4.0 逻辑下沉进核心，而不是为了追版本号一次性重写所有稳定代码。

版本构建流程也进入 4.0 Preview

当前预览构建已经开始统一使用：

用户可见版本：4.0.0-preview.1
Assembly / File Version：4.0.0.0
Updater 数字比较版本：4.0.0

Launcher、Updater、Installer 和 Uninstaller 在构建时通过临时 version-stamped source 完成版本标记，而不是为了改版本号永久重写大块已经检入的 C# 源文件。

Installer payload 也已经包含新的 4.0 Preflight helper。

还没有完成的 4.0 工作

Preview 1 是 foundation，不是终点。

接下来仍然有几块关键能力要继续做：

精确找到谁在锁目录

现在可以区分 locked / access denied，并延迟清理，但下一步希望进一步拿到：

PID；
executable；
process name；
command line。

最终让日志不只说“目录被占用”，而是尽可能告诉用户：具体是谁在占用。

完整插件一致性矩阵

后续会继续把 Browser、Chrome、Computer Use 的：

version；
hash；
path；
marketplace；
cache；
latest；
Native Host

放进更完整的 per-plugin consistency matrix。

Targeted Repair

目标不是“检测到异常以后全修一遍”，而是只处理真正偏离的那一层。

如果只是 Browser 的 latest 指针错误，就不应该顺手重建完全正常的其他组件。

Official-first Native Host reconciliation

Native Host 仍然会继续加强，但原则不变：尽量以当前机器已经安装的官方包为事实来源，不自己创造第三方运行时状态。

Atomic staging 阶段的 Access Denied

Preview 1 首先加强的是诊断和 post-run / retention cleanup。

如果 Access Denied 直接发生在新的 resource mirror atomic staging 阶段，它仍然需要单独做更精确的根因处理。

4.0 仍然不会跨越这些边界

WinBridge Recovery 4.0 不会因为诊断能力增强就改变安全边界。

它不会：

接管 C:\Program Files\WindowsApps；
修改 WindowsApps 所有权；
绕过 Windows、浏览器或企业安全策略；
绕过账号 entitlement；
从互联网下载第三方插件冒充官方组件；
携带账号密码、Cookie、Token 或 API Key；
因为一项清理失败就删除仍在使用的活动资源镜像。

WinBridge 仍然只围绕目标电脑现有的官方 Codex Desktop 安装状态做诊断与恢复。

Preview 1 发布前还要验证什么

在这条 4.0 foundation 分支进入正式 merge / release 之前，至少还需要完成：

在干净的 Windows PowerShell 5.1 环境构建 Launcher、Installer 和 Uninstaller；
Windows 11 上运行 SELF-TEST.cmd 和 DIAGNOSE-ONLY.cmd；
至少一台 Windows 10 主机执行新 Preflight，确认能够准确描述 host/package 可用性；
构造超长深层资源镜像，确认维护清理不再受旧路径限制；
重现 locked mirror，确认只产生 deferred cleanup，而且不会删除 active mirror 或削弱 rollback。

完成这些之前，我仍然会把它叫作 Preview，而不是 4.0 正式版。

从“修复按钮”到“可解释恢复”

WinBridge 最初解决的是一个很具体的问题：Codex Desktop 更新、重启或资源状态变化以后，Browser、Chrome、Computer Use 的本地状态可能出现不一致。

但真实问题越多，我越确定一个恢复工具最重要的能力不只是“点一下修”。

它应该能回答：

我检查了什么？
第一个异常在哪里？
为什么要修改这一层？
哪些东西没有问题，所以我没有碰？
哪些属于上游、系统或策略问题，因此 WinBridge 不应该绕过？

这就是 4.0 Preview 1 正在搭的基础。

WinBridge Recovery 是独立开发的非商业社区项目，与 OpenAI 无隶属、赞助或认可关系。第三方名称仅用于说明兼容对象。