Desktop 默认沙箱下 shell 无法启动（0xC0000142）

[llwinty]

...
这台机器的默认沙箱下 shell 无法启动（0xC0000142），我是用提权模式读到状态的，后续每条引擎命令都会弹一次批准，家长点一下即可。

22:30
先核实解决沙箱下shell无法启动的问题

22:31
已完成
已完成，用时 10分52秒
结论：已核实，根因定位到 DSH 沙箱本身（不是你的仓库问题）
一句话：DSH 在 Windows 上的 workspace-write 沙箱，被限制的（WRITE_RESTRICTED + Low 完整性）子进程必须继承一个已存在的控制台；而 DSH 用它自带的 Electron 二进制（process.execPath）承载所有子进程/沙箱 runner，Electron 没有控制台。于是受限子进程只能自己新建控制台——这在该令牌下必然失败，进程在 DLL 初始化阶段就以 STATUS_DLL_INIT_FAILED (0xC0000142 = 3221225794) 死掉，没有任何输出。这与你看到的「每条命令都 (no output) / exit code 3221225794」完全一致。

核实过程与证据
我从 app.asar 里取出 DSH 自己的沙箱实现（dsh-sandbox-windows-acl、dsh-win32-process、dsh-subprocess-local、koffi），在你的机器上用同一份代码做了对照实验：

承载沙箱的宿主进程 是否有控制台 read-only 沙箱 workspace-write 沙箱
node.exe（从终端启动） 有 ✅ 正常 ✅ 正常（输出 TARGET-OK）
node.exe + DETACHED_PROCESS 无 — ❌ 0xC0000142
Electron-as-node（DSH 的做法） 无（实测 GetConsoleWindow=0、GetConsoleProcessList=0） ✅ 正常 ❌ 0xC0000142
node.exe + windowsHide:true 有（仅隐藏） ✅ 正常 ✅ 正常
关键点：

变量是「有没有可继承的控制台」，与 windowsHide 无关（dsh-subprocess-local 里的 windowsHide: true 不是元凶）。
read-only 模式在没有控制台时也能跑，所以问题只出在 workspace-write（浏览器/桌面端默认就是这个模式）。
子进程死亡时 runner 不会报自己的错误（runner 自身失败会打印 windows-acl-run: … 并退出 127），所以工具层只剩一个裸退出码——这解释了「无输出」。
承载 runner 的可执行文件在代码里是硬编码的 process.execPath（spawnRunnerInvocation()），没有任何配置项能换成真正的 node.exe；dsh.cmd 命令行入口同样用 Electron。所以 GUI 和 CLI 两种启动方式都会中招。
该失败模式 DSH 自己的文档里也记录为已知边界：「控制台隔离不可用——以 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED (0xC0000142) 死亡；子进程共享宿主控制台」。
版本信息（便于反馈）：DeepSeek Harness 0.2.0-rc.2（Electron 44.0.0 / Node 24.18.1），Windows 11 企业版 build 26200。

[lybym]

补充一份独立复现与修复验证，可以给上面的根因分析补三块目前缺的证据：最小复现、排除项、以及"上游修法在本机确认真能救活沙箱"。

环境：Windows 11（build 26200）、桌面端 DeepSeek Harness 0.2.0-rc.2（Electron 44.0.0 / Node 24.18.1）、会话默认 workspace-write。裸 pwsh 工具调用返回 (no output) / [exit code: 3221225794]；同一命令切 danger-full-access 正常。

1. 最小复现（不经 DSH 包，证明根因不在 ACL/路径/包版本）

用 koffi 直接调用 Win32，复刻沙箱的进程创建：

• OpenProcessToken → 取 logon SID → CreateRestrictedToken(..., 13 /*DISABLE_MAX_PRIVILEGE|LUA_TOKEN|WRITE_RESTRICTED*/, restricting = [logonSID, S-1-1-0])
• STARTUPINFOW.dwFlags = STARTF_USESHOWWINDOW|STARTF_USESTDHANDLES、wShowWindow=0
• CreateProcessAsUserW(..., CREATE_SUSPENDED)，dwCreationFlags 中不含任何控制台标志
• ResumeThread 后等待

CreateProcessAsUserW 每次都返回成功，子进程的退出码才是判据：

承载进程	是否先拥有控制台	受限 pwsh 子进程
node.exe	是	0x0
node.exe	AllocConsole()	0x0
Electron-as-node	否	0xC0000142
Electron-as-node	AllocConsole() + SW_HIDE	0x0 ✅

同一矩阵用真实 @deepseek-ai/dsh-sandbox-windows-acl（AclSandbox.spawn，完整令牌：logon SID + Everyone + workspace/temp write SID + Low 完整性）复跑，结果逐格一致。也就是说：令牌、低完整性标签、工作区路径、restricting SID 列表都不是变量，唯一的变量是"宿主是否有控制台可继承" —— 与 README.zh.md「控制台隔离不可用」那条已记录边界一致。

补充：Electron 侧换任意版本（Electron 35/37/44 的四个不同 Electron 应用）结果相同；vanilla node v22 与 v24 均正常。

2. 排除项（这些常见修法都无效，别再试）

尝试	结果
子进程 CREATE_NEW_CONSOLE (0x10)	0xC0000142
子进程 CREATE_NO_WINDOW (0x08000000)	0xC0000142
子进程 DETACHED_PROCESS (0x08)	0xC0000142
只加 STARTF_USESHOWWINDOW + SW_HIDE（dwFlags 仍为 257）	0xC0000142（当前包已带该组合，只能消除可见窗口，救不回进程）
宿主 CreateNoWindow=$true / -WindowStyle Hidden	无效（仍是"有隐藏控制台"，不改变结论）

不是 Microsoft 二进制签名/进程缓解策略：对 Electron 进程与 vanilla node 进程做 GetProcessMitigationPolicy 全量 dump（策略 0–14、16），SignaturePolicy、ImageLoadPolicy、DynamicCodePolicy、StrictHandleCheck、ChildProcessPolicy 逐项相同且均为 0。

不是包版本回归：从桌面端 app.asar 里取出的 dsh-sandbox-windows-acl 0.2.0-rc.2 与 profile 里的 0.1.7-rc.2 逐行比对，除 chunk 命名与换行外功能等价，runner.js 与 dsh-win32-process 逻辑一致。所以这条不是版本问题，而是宿主形态问题。

3. 修复方向已在本机验证（不只是推测）

"给宿主一个控制台再生成受限子进程"这一条，实测能够彻底恢复：

• Electron-as-node 宿主先 AllocConsole()，再用 ShowWindow(GetConsoleWindow(), SW_HIDE) 隐藏；
• 之后受限 pwsh 子进程退出码 0x0，命令输出正常，沙箱写边界不变。

这与上游 anywhere-labs/dsh-desktop 的提交一致——fix(win): keep confined shells alive when Electron has no console（commit a1caef3，描述为：Electron 无控制台 → Windows 只能用已被削权的令牌去新建 conhost → 子进程在 DLL 初始化阶段死于 0xC0000142；trampoline 在"尚未受限时"分配并隐藏控制台，使受限子进程继承已存在的控制台；DACL、restricting SID 列表、creation flags、失败路径均不变）。

Harness 侧若要独立于桌面外壳兜底，建议仍是上面这条已验证的路径（探测 GetConsoleWindow() 为空则先分配控制台并隐藏），而不是给子进程加控制台相关 creation flags。

4. 一处需要修正的细节

本楼写道「read-only 模式在没有控制台时也能跑」。我这边只复测了 workspace-write，未复测 read-only；而包内文档的表述是"CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction"（未区分模式，README.zh.md「已验证边界」与 lib/index.js 注释同一措辞）。两者不一致，建议以 read-only 复测结果为准，不要在 issue 里把"仅 workspace-write 受影响"当作结论。

[argszero]

Same exit code and same shape as the other threads in this family, and there is a diagnostic for it today: @argszero/cordis-plugin-sandbox-grant-advisor (npm, 0.10.0) observes the tool result, recognizes the 0xC0000142 value — which never arrives as an error, because upstream's runner-failure rules only classify exit 127 as one — and attaches an advisory naming the mode actually in force, the measured producers, and the checks that tell them apart. Mount it in the session's profile and the diagnosis reaches the model in the same step as the failure.

[dsh-community-assistant[bot]]

已收到这条反馈。

[SwordSifu]

补一块本楼明确缺的读数（回应楼上补充里「未复测 read-only，建议以 read-only 复测结果为准」）：read-only 在无控制台宿主下可以跑，workspace-write 才是死的。两次独立读数，同一台机器（DSH 0.2.0-rc.2 桌面版，Windows 11 build 26100，profile desktop）：

1) 真机会话（桌面端，会话预设 read-only，pwsh 工具）

• $PSVersionTable → 7.6.6 / Core；LanguageMode → ConstrainedLanguage（与沙箱文档一致）
• 向工作区外写入 → 被拒（outside-write=DENIED，文件不存在）；工作区外读取正常

2) out-of-band A/B：用从 app.asar 取出的同一份 dsh-sandbox-windows-acl（seam 式 --write-sid/--temp-write-sid 与 agentless 两种调用都试）

runner 宿主	read-only	workspace-write
node.exe	✅	✅
Electron（DeepSeek Harness.exe + ELECTRON_RUN_AS_NODE=1）	✅	❌ 0xC0000142

→ 同一个无控制台宿主，read-only 通、workspace-write 死。也就是说「宿主没有可继承的控制台」恐怕不是充分条件，workspace-write 那条路径上还有别的变量（temp 授权 / restricting SID 列表 / 创建标志）值得对照——这一格读数可以给上游定位时当参照。

另两条独立证据：

• 与 shell 身份无关：把被包程序换成 cmd.exe 与 Windows PowerShell 5.1，在 Electron 宿主的 workspace-write 下同样 0xC0000142（不是 pwsh 7 或某个 shell 的特有行为）。
• read-only 下 MSYS2 是另一种失败：Git for Windows 的 bash 在 read-only 受限令牌下以 cygheap_user::init: NtSetInformationToken 退出（退出码同为 3221225794，但 stderr 可区分），同一轮 pwsh 正常——即「受限令牌 + 无控制台」至少有两条不同的失败路径。
• runner 自身的失败规则只匹配 windows-acl-run: + 退出 127，所以这类子进程死亡只会以裸退出码到达工具层（(no output) / [exit code: 3221225794]），与楼主观察一致。

（备注：本机 Windows 的 Issues 是关闭的，所以按现有讨论补证据而非新开帖。）

[domorCN]

补充：控制台必须补在上游独立进程，在 runner 内部补无效（附实测数据 + creation flags）

感谢 @llwinty 与 @lybym 的定位。我在同类环境（Windows 11 build 26200 / 桌面端 0.2.0-rc.2 / Electron 44.0.0 / Node 24.18.1 / workspace-write）下实测了这条修复，并得到一个对复现者有用、但容易被误读的结果：我第一次尝试失败了，原因不在"补控制台"这个方向，而在补在了错误的进程。特此说明，以免其他人按错误的位置实现后误判该方案无效。

1. 环境

项	值
OS	Windows 11 专业版 10.0.26200
账户	内置管理员（RID 500），High 完整性 S-1-16-12288
DSH	桌面端 0.2.0-rc.2，Electron 44.0.0，Node 24.18.1
构建	dshBuildCommit = 04f392c9ddd144fa426da2045178797da6db6c11
会话模式	workspace-write
沙箱后端	@deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2
症状	pwsh 工具 → (no output) / [exit code: 3221225794]（0xC0000142）

2. 先确认前提：DSH 全部进程确实没有控制台

对活着的 DSH 进程逐一用 AttachConsole(pid) 探测：

PID 2356   NO-CONSOLE hwnd=0
PID 2416   NO-CONSOLE hwnd=0
PID 3584   NO-CONSOLE hwnd=0
PID 9704   NO-CONSOLE hwnd=0
PID 18524  NO-CONSOLE hwnd=0

再用与 DSH 相同的方式（Electron-as-node + 管道 stdio + windowsHide:true）拉起 runner，观测其进程内部状态：

parent pid=26860 console=10426338          <- 父进程有控制台
PRELOAD pid=37184 GetConsoleWindow=null
        consoleProcesses=0                  <- runner: 完全没有控制台

"runner 无控制台"这一条件成立，楼主的分析在此处得到独立复现。

3. 实测 A（失败）：在 runner 内部补控制台 —— 无效

在 asar 内 @deepseek-ai/dsh-subprocess-local/lib/runner.js 顶部注入（该包 "type":"module"，故必须走 ESM 写法）：

import { createRequire as __dshCreateRequire } from "node:module";
try{globalThis.__dshRunnerPath=import.meta.url;
    __dshCreateRequire(import.meta.url)("<shim>.cjs")}catch{}

垫片在 runner 内执行 GetConsoleWindow() → AllocConsole() → ShowWindow(SW_HIDE)。

观察项	结果
注入代码存在于运行中的 asar	✅ 字节偏移 58883283
应用正常启动（未退回 default_app.asar）	✅
注入每次都被执行	✅ 每次 pwsh 调用均产生一条日志
AllocConsole() 返回值	✅ true，GetConsoleWindow() 返回有效句柄
受限子进程结果	❌ 仍然 0xC0000142，无输出

runner: AllocConsole=true window=3874036 -> ...
runner: AllocConsole=true window=3939572 -> ...
runner: AllocConsole=true window=4005108 -> ...

解读（重要）：这不说明"补控制台"方向无效。它说明在已经运行的 runner 进程内部、于 ESM 求值时补控制台，无法满足受限子进程的继承条件。

对照上游 anywhere-labs/dsh-desktop a1caef3 的做法，两者是不同的实现：

	上游 trampoline	本次实测 A
执行位置	独立进程，位于 executable 与 runner 之间	runner 内部，ESM 求值时
相对 runner 的时机	runner 尚未加载	runner 已开始初始化
调用时状态	干净的控制台进程，尚未受限	已在运行的 Electron node-mode 进程
结果	受限 pwsh 退出码 0x0	仍 0xC0000142

上游提交说明（第 19 行）明确要求：trampoline 在仍未受限时分配控制台，且之后才导入上游 runner module。本次实测 A 恰恰违反了这两点，因此失败是预期的。

建议：实现或复现时不要采用"在 runner 内部注入"的形式；控制台必须由上游独立进程在受限子进程创建之前建立并使其可继承。

4. 实测 B：creation flags 不是原因（已排除）

从 @deepseek-ai/dsh-win32-process/lib/index.js 提取的真实调用：

// 受限进程（workspace-write 路径）
spawnJobProcess(..., (si, pi) =>
  createRestrictedProcess(api, options, commandLine, 4, si, pi));
//                                               ^ dwCreationFlags = 4
//                                                 = CREATE_SUSPENDED

// 目标进程
api.createProcessW(options.applicationName, commandLine, null, null, 1,
                   1028, environment, options.cwd, startupInfo, processInfo);
//                  ^ 1028 = CREATE_SUSPENDED(4) | CREATE_UNICODE_ENVIRONMENT(1024)

不含 CREATE_NO_WINDOW(0x08000000)、不含 CREATE_NEW_CONSOLE(0x10)、不含 DETACHED_PROCESS(0x08)。
DSH 在这一点上是正确的，与其 README.zh.md「控制台隔离不可用……保留控制台继承」的表述一致。这与上游 trampoline 方案"creation flags 保持不变"的结论一致。

5. 已排除：PowerShell 版本 / 文件权限

• 非 PowerShell 问题：非沙箱（danger-full-access）下同一 pwsh 正常返回 7.6.6；沙箱内连 cmd.exe /c echo test 也死于同一退出码。故障发生在任何 shell 代码执行之前。
• 非 ACL 问题：以非沙箱方式运行 DSH 自带的 diagnose-windows-sandbox-acl.ps1，裁决 VERDICT=NOT_THIS_CLASS、FIXED=0。工作区及其全部祖先 WRITE_DAC=True、WRITE_OWNER=True，LOW_LABEL=True，DSH 自身的写授权 SID（S-1-4-169927480-981221986）已在位。

6. 一个需要解释的差异：read-only 通、workspace-write 死

公开讨论中的读数表明：同一套无控制台宿主下，read-only 可以工作，只有 workspace-write 失败。我在本机只复测了 workspace-write，与之一致。

上游提交 a1caef3 的措辞也承认这一点尚未完全收敛：

在受影响的 Windows 环境中，受限 console child 被迫自行创建 console 时会在 DLL 初始化阶段以 0xC0000142 失败；即使某些环境能由 Windows 成功创建该 console，其行为仍与拥有 console 的 CLI 路径不同。

并且该提交把"原生 Windows ACL confinement 与打包 app.asar 路径"列为仍需目标机验证的事项。

建议：若能补充 read-only 与 workspace-write 在同一机器上的 A/B 读数，可帮助确认修复是否覆盖两种模式。两者共用同一宿主形态，差异只在 Low 完整性标签与 WRITE_RESTRICTED 的 restricting SID 列表。

7. 附：本次调查中确认的两条工具链事实（对复现者有用）

• dsh-subprocess-local 的 package.json 是 "type":"module"，其 lib/runner.js 是 ESM。任何注入若使用 require / __filename，会被自身的 try{}catch{} 静默吞掉，表现为"注入看似装好但完全无效"。
• koffi 位于 asar 内部，普通 Node 无法解析（MODULE_NOT_FOUND）。复现需在 Electron-as-node 环境下用 createRequire(<runner路径>)('koffi')；本机验证结果为 koffi 3.1.1。

8. 相关议题

同一现象在其它仓库也有记录，或可互相参照：

• anywhere-labs/dsh-desktop#991 — [Bug] Windows: sandboxed pwsh dies with 0xC0000142 whenever no process in the sandbox chain owns a console (DSH Desktop GUI launch path)
• deepseek-harness#7292 — [Bug][Windows] workspace-write sandbox: every spawned console app dies with 0xC0000142 and raises a modal Windows error dialog on each tool call