[Bug][Windows][附候选修复] 工作区 Low 完整性标签影响正常工具链（#7709 / #9086 / #9560 后续）

[ornithologist-love]

这里提供一个针对已报告 Low 完整性问题的候选修复：在支持原生 PSEC 的机器上优先使用 Microsoft MXC，通过进程隔离策略限制文件操作，避免把真实工程目录及其构建产物标记为 Low。

关联现有的低完整性 Bug 报告：

• #7709：工作区 Low 标签影响用户自行启动的工具链程序。
• #9086：生成的 Windows 二进制继承完整性标签，正常运行时权限受限。
• #9560：安装目录与工作区重叠，DSH 自身二进制受到 Low 标签影响。

已经整理了可以查看和复用的实现，供讨论和评估：

• 候选分支：bugfix/windows-mxc-sandbox
• 相对官方 dsh-v0.2.1-rc.2 基线的完整差异
• 迁移说明

问题：沙箱结束后，正常开发进程仍受 Low 标签影响

现有 ACL 后端为允许 Low 令牌写入工作区，会给真实目录设置可继承的 Low 完整性标签。目录内的新文件和可执行构建产物可能继承它，之后用户从普通终端启动这些程序时仍可能受到影响。相关报告已经覆盖工程内工具、构建产物和 DSH 安装目录：#7709、#9086、#9560。

我们也在本机确认过工程根和工具二进制带有继承的 Low 标签。单纯在退出时恢复权限，可以减少残留，但运行期间仍然改变共享工程目录；在大目录上进行权限传播也有实际成本。

此前的 #9818 和 #11545 讨论的是同步 ACL 传播阻塞宿主。这次希望讨论进程隔离能否减少对真实工作区权限的修改。

为什么重新评估 MXC

仓库的 Windows ACL 方案决策 已经讨论过 MXC，当时关注系统版本要求和 AppContainer/DACL 回退的副作用。这些顾虑仍然需要考虑，特别是旧版 Windows 的覆盖。

目前 Codex 的原生 MXC 后端 直接使用 PSEC/BaseContainer，明确不修改宿主 ACL。微软当前的 processcontainer 说明 也将原生 PSEC 与旧 AppContainer 路径区分开来。是否支持必须实际探测，不能只看 Windows 版本号。

候选实现参考了 Codex 的策略和生命周期处理。它不会把 MXC 的 AppContainer/DACL 回退当作可用的原生后端。

分支实现

• Windows 的选择顺序为 windows-mxc → 现有 windows-acl。仅原生能力不可用时允许选择旧后端；原生探测异常或命令启动失败会报错，不因失败切换后端执行命令。
• 使用固定版本的 @microsoft/mxc-sdk@1.0.1 和随包的官方 wxc-exec.exe。使用原生执行器承接标准 I/O，是因为 SDK 的 Node 流式 API 不支持我们正在使用的 Node 25.7。
• 文件策略映射到原生只读和可写路径。MXC 路径不调用工作区 ACL 授权或 Low 标签写入逻辑，保留 DSH 当前文件策略之外的网络访问语义。
• 原生执行器受 kill-on-close Job 管理。DSH 的 fd 7 控制通道通过带随机凭据的回环连接桥接，目标程序及桥接子进程均在 PSEC 内执行。
• 前台命令结束时回收派生进程。仍报告 partial，没有把硬链接等限制包装成完整隔离保证。

已验证与未验证

在 Windows 11 25H2、build 26200.9711、Node 25.7.0 上，对此 fork 分支执行了 pnpm install --frozen-lockfile 和标准 pnpm run build:artifacts；构建的 7 个阶段全部通过。

通过真实的 LocalSandboxProvider.confine() 和构建后的 runner 手动验证：

• 自动选中 MXC；工作区文件写入成功。
• 对工作区外已有文件的写入和删除均返回 EPERM，文件内容保持原样。
• read-only 模式拒绝工作区写入。
• 工作区 ACL 在执行前后完全一致。
• PTC 控制通道可以双向收发并正常退出。

同一实现还验证过前台退出后回收 detached 派生进程，以及 Windows PowerShell 5.1 / PowerShell 7 的命令执行。两种 PowerShell 在本机都有 InitializeDefaultDrives 启动告警，命令退出码为 0；同机 Codex MXC 也能复现同一告警。

集成载荷以临时状态目录启动 sidecar，3395 ms 收到 ready，页面 HTTP 返回 200。同一载荷中的沙箱提供方也再次验证了自动选择 MXC、工作区写入成功、外部写入返回 EPERM，以及执行前后工作区 ACL 不变。

迁移说明、翻译配对、README 摘要和 Markdown 链接检查均已通过。全量 doc-sync 有一项基线误报：python/sdk/uv.lock:113 的 wheel 文件大小 6344383 恰好匹配已有 Git 提交的短 SHA，被当作提交引用。该锁文件与官方基线完全一致，候选分支没有修改它。

未新增自动化测试，也未运行沙箱测试套件；完整 GUI、ARM64 和其他系统版本的回归尚未完成。

希望讨论的取舍

1. 是否接受在支持 PSEC 的机器上自动优先 MXC，还是先要求显式启用？旧 Windows 是否继续保留现有 ACL 后端？
2. SDK 1.0.1 的支持范围要求 Node 24+。当前候选按这个版本要求验证，DSH 现有 Node 22 支持需要在采纳前另行处理。
3. 前台退出时结束派生进程，符合原生 MXC 的生命周期，但会影响依赖 detached 开发服务器的工作流。这一变化是否符合 DSH 的预期？

已有 Low 标签的修复仍需单独处理：切换到 MXC 不会自动重置用户目录权限。Windows 也会为隔离进程提供私有的 LOCALAPPDATA / TEMP 路径，它们与共享工程目录的权限应分别看待。

这里先提供候选代码和已验证结果，欢迎维护者评估这个方向。

[xiaoxiao714]

补一个对照数据点，可能对定位这条线有帮助。

环境：Windows 10 专业版 22H2（build 19045），PowerShell 5.1（未装 PowerShell 7），管理员会话（High 完整性），会话权限 workspace-write。

现象：让 agent 执行 shell 命令 Get-Date -Format o。

运行时	版本	结果
桌面打包运行时（ELECTRON_RUN_AS_NODE 起 app.asar/dsh/.../bin.js）	0.2.1-rc.3	❌ exit code 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED），无输出
npm @deepseek-ai/dsh（node 24.21）	0.2.1-rc.3	✅ 正常输出时间戳
npm @deepseek-ai/dsh（node 24.21）	0.2.2-alpha.2	✅ 正常输出时间戳

三次都在同一台机器、同一个管理员会话、同一个 workspace-write 下；最小复现不需要 GUI：隔离 DSH_HOME + headless 模板 + DSH_PERMISSION_MODE=workspace-write。npm 版里工作区写入、回读也都正常。

完整性标签：后来检查工作区，三个目录都是

[xiaoxiao714]

而且切回 danger-full-access 之后标签仍在（icacls 可复现）。

想问的：

1. 0xC0000142 是否更像受限令牌 + Low 标签下 powershell.exe 初始化失败，而不是命令本身报错？
2. 为什么只有打包运行时触发、纯 node 不触发——桌面版是否走了不同的 sandbox provisioning 路径？
3. 切到候选的 MXC 实现后，这个 0xC0000142 会不会一起消失？我可以按需提供 icacls/Get-Acl 或 procmon/ETW 记录。

[ornithologist-love]

谢谢补充这组对照。我们目前只验证了 Node 运行时，没有 DSH Electron 桌面版的复现证据，因此暂时无法判断桌面版独有的 0xc0000142 原因。

刚在 Windows 11 build 26200、High 完整性、Node 25.7、PowerShell 5.1 下确认选中原生 MXC，执行相同的 Get-Date -Format o：read-only 和 workspace-write 均正常输出时间戳、退出码为 0，工作区 ACL 和 Medium 标签保持不变。不过仍有 InitializeDefaultDrives 警告。

MXC 候选修复能避开旧后端修改工作区权限的路径，但不会自动清理已有 Low 标签。