DeepSeek Harness Windows 沙箱 0xC0000142：桌面端与 dsh web 分诊

一条最普通的 echo ok，在 Windows 桌面版的 workspace-write 下返回 0xC0000142，stdout 和 stderr 一个字都没有——这不是命令写错，是受限子进程在 DLL 初始化阶段就死了。 同一个 DSH、同一台机器，换成 dsh web 启动就正常，这一个对照就能把范围缩到「宿主形态」；社区在 Win11 26200 和 Win10 19045 上都复现过同一个形态（#10483、#10706）。

DeepSeek Harness 分诊：先问三个问题，别急着改配置

三个判据按顺序问：桌面端挂不挂、dsh web 挂不挂、是所有 exe 都挂还是只有 PowerShell 挂。三个答案组合起来，基本就能落到三条成因中的一条。

1. 桌面端新建会话，权限选「工作区内修改」，让 Agent 执行 echo ok，记下退出码。看到 3221225794 或 0xC0000142 就进了这一类。
2. 同一条命令切到「完全权限」（danger-full-access）再跑。能跑通，说明令牌构造、ACL、路径都没问题，故障只在受限路径上。
3. 在同一个工作区改用 dsh web 启动（Node 宿主），切 workspace-write 再跑一次。这一步是整篇的分水岭。
4. 如果手边有 --no-sandbox 之类的启动参数，也试一次；能起说明是 Chromium 的安装目录检查，不在本文范围。

对照结果可以直接查表：

DSH插件 成因一：GUI 宿主没有控制台，受限子进程起不来

桌面端是 Electron GUI 子系统进程，天生没有控制台；受限令牌下子进程又建不出可用的控制台，conhost 初始化失败，进程在 DLL 初始化阶段就退出，所以没有任何输出。

1. 确认宿主类型：任务管理器里看 DeepSeek Harness.exe 的父进程，如果是 explorer.exe，就是 GUI 启动。
2. 用 dsh web 在同一个工作区复跑同一条命令。web 版由 node.exe 启动，从终端继承了真实控制台，整条 runner 链都有控制台。
3. 如果 web 版正常，基本可以确认是「宿主无控制台」，不需要再动 ACL。
4. 社区核对源码时还查了发布包：当前构建的 app.asar 里 ensureWindowsConsoleHost 和 AllocConsole 都是 0 处，说明那个「给 Electron 补控制台」的 trampoline 修复（a1caef3）没有进这个构建。

这也解释了为什么「从终端启动桌面版」同样失败：GUI 子系统进程不会附加父进程的控制台。

DeepSeek Harness 成因二：CREATE_NEW_CONSOLE 是真正的失败点

受限令牌加「需要新建控制台」的组合必挂；能继承已有控制台、或者完全不建控制台，都能正常起。六组宿主/标志对照把这一点钉死了。

社区做过一组 A–F 对照，只改宿主进程和 creationFlags：

两个后续实验值得记：给 runner 加隐藏控制台（AllocConsole + SW_HIDE）后，PowerShell 的内置命令能跑了，但由它再去起外部程序仍然失败；改成 DETACHED_PROCESS 后 cmd 能跑，PowerShell 却连 -Command 都不执行，因为 PowerShell 的 ConsoleHost 需要真实控制台。

所以「加个隐藏控制台就好了」只对了一半：它证明了根因，但没解决句柄继承。

DeepSeek插件 成因三：路径 DACL 带外来包 SID，跑随包脚本

如果每条命令都挂、跟命令内容和 cwd 无关，还要考虑第三种：子进程必须读的某个路径，其 DACL 里带着别的 AppContainer 工具的包 SID，低完整性令牌打不开。

官方包的 README（packages/sandbox/sandbox-windows-acl/README.md）写明了两条已文档化的成因和一条结构性限制：

1. 保活组（登录 SID + Everyone）不在令牌里。
2. 子进程用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建，README 注明控制台隔离不可用。
3. 路径 DACL 带外来包 SID——以前的沙箱工具或旧版 DSH 给工作区、安装树盖过章，就会命中这一条。

针对第三条，包里带了一个诊断加修复脚本，用非受限身份运行：

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' `
  -Path '<workspace-or-install-dir>' `
  -RecoveryDir '<recovery-dir>'

脚本会备份并校验每一处 DACL 改动、在源头删除外来包 ACE、拒绝处理重解析点与托管应用目录，最后打印回滚命令。rc.2（687f282e）的发布包里已经有这个脚本，不用等 rc.3。

DeepSeek Harness 为什么卸载重装没有用

ACL 挂在目录上，不在程序文件里；卸载程序不会去补 ACE，清 AppData 也不会。所以「重装一遍」对这三条成因一条都不生效。

1. 先别重装，按上面的分诊表确认方向。
2. 需要跑修复脚本时，从非受限制的 PowerShell 窗口跑，不要在 DSH 沙箱里的 shell 跑。
3. 脚本必须指定 RecoveryDir，改之前留备份，出问题按它打印的命令回滚。
4. 如果脚本报「nothing to repair」，说明不属于第三条，回到成因一或成因二。
5. 另有一种「重装后应用直接起不来」是卸载器留下的问题，和 shell 的 0xC0000142 是两件事，别混在一起查。

DSH插件 注意事项

下面这些做法会加重问题或掩盖真因，先避开再谈修复。

1. 别让长期方案停在 danger-full-access。它是分诊工具，不是修复。
2. 不要同时改令牌、ACL 和启动标志。一次一个变量，否则复现结果没有意义。
3. --no-sandbox 只当信号用。它能起说明是安装目录访问检查那一层，长期这么跑等于关掉浏览器沙箱。
4. Windows 10 和 Windows 11 都会命中。社区在 19045、22621 上都复现过，别以为是系统版本门槛。
5. 先记版本号和提交。rc.2 与 rc.3 的差别会影响你判断「是不是已经修了」。

如果 dsh web 能跑、桌面端不能，最省事的临时方案就是先用 web 版干活；要留在桌面端，就得等宿主侧补上控制台 trampoline。相关排查见 DeepSeek Harness Windows 子进程报 0xC0000142：受限令牌与宿主定位。