Windows: confined commands die with 0xC0000142 because the sandbox runner is the Electron (GUI-subsystem) binary

[formal-you]

Summary

On the Windows desktop app (0.2.1-rc.2, Windows 11 26200, AMD64), every command run while the session is in workspace-write fails immediately:

[exit code: 3221225794]      # 0xC0000142 / STATUS_DLL_INIT_FAILED

No stdout, no stderr. cmd /c echo ok behaves the same, and the PTY terminal reports PTY shell exited during startup. Full access (danger-full-access) works without issues.

Root cause

@deepseek-ai/dsh-sandbox-local builds the Windows runner argv as:

[process.execPath, ".../@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js", ...]

In the desktop app, process.execPath is DeepSeek Harness.exe — an Electron GUI-subsystem binary. A GUI-subsystem process is never attached to a console.

The ACL runner then starts the confined target (pwsh, cmd, node) with CreateProcessAsUserW. Since the parent owns no console, the console-subsystem child has to create a fresh console, and the WRITE_RESTRICTED + Low-integrity token cannot do that — the child dies during DLL initialization with STATUS_DLL_INIT_FAILED.

This also explains the neighbouring observations:

• read-only sometimes works: its restricting list carries no write SIDs, so the console-creation path still passes;
• GUI-subsystem children (e.g. notepad) always work, because they never need a console.

Reproduction (same runner, outside the app)

The chain host → subprocess runner → windows-acl runner → target was reproduced directly, only varying process.execPath:

runner binary	mode	child	result
node.exe (console subsystem)	workspace-write	pwsh / cmd / node	0
Electron	read-only	pwsh	0
Electron	workspace-write	pwsh / cmd / node	0xC0000142
Electron	workspace-write	notepad (GUI subsystem)	0
Electron, AllocConsole() before spawn	workspace-write	pwsh	0

The last row is the decisive one: giving the runner a console fixes it immediately, and so does swapping the runner to the bundled node.exe.

Suggested fix (either is enough)

1. In @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js, before spawning: if GetConsoleWindow() is NULL, call AllocConsole() (optionally hiding the window with ShowWindow(..., SW_HIDE)). Verified to fix the failure locally.
2. Stop using process.execPath as the runner program when it resolves to a GUI-subsystem executable; use the bundled console-subsystem node (resources/runtime/primary-runtime/dependencies/node/bin/node.exe). Note that plain node.exe cannot read app.asar, so the runner entry has to come from an unpacked copy or app.asar.unpacked.

Workaround (user side, no patching)

Override sandbox-local in the profile patch layer and route the runner through node.exe:

- id: sandbox
  name: "@deepseek-ai/dsh-sandbox-local"
  config:
    runnerCommand:
      - "C:\\...\\resources\\runtime\\primary-runtime\\dependencies\\node\\bin\\node.exe"
      - "C:\\...\\runner-shim.mjs"
    runnerFailureSignatures:
      - "windows-acl-run"

A shim is required because a custom runnerCommand receives the bwrap profile dialect (--ro-bind / / --dev /dev ... --bind <ws> <ws> -- <argv>), while the Windows ACL runner expects --workspace/--temp/--mode -- <argv>. The shim translates the former into the latter and launches the ACL runner under node.exe.

Two caveats for this path: enforcement is reported as full for custom runners, and the denial dialect (DENIAL_SIGNATURES.runnerCommand = read-only file system / permission denied) does not match the Windows denial text (Access is denied), so sandbox denials render as plain non-zero exits.

中文摘要

桌面版（Electron）会把沙箱 runner 用 process.execPath 启动，也就是 GUI 子系统的 DeepSeek Harness.exe。GUI 进程没有控制台，于是受限令牌下的控制台子进程（pwsh/cmd/node）必须新建控制台，而 Low 完整性 + WRITE_RESTRICTED 令牌不允许，最终以 0xC0000142 在 DLL 初始化阶段死亡。修复只需二选一：runner 启动前 AllocConsole()，或改用随包的 node.exe 作为 runner 宿主。

[formal-you]

Follow-up: the workaround is verified on the desktop app

Applied the runnerCommand workaround on Windows 11 (26200) with the desktop app 0.2.1-rc.2: the profile patch routes the ACL runner through the bundled node.exe, plus a shim that translates the seams bwrap-profile dialect into the ACL runners --workspace/--temp/--mode --argv.

After a restart, with the session back in workspace-write:

step1 location: D:\WorkSpace\Agent研究
step2 inside-write: True
step3 denied: Access to the path 'C:\Users\<user>\sandbox-escape.txt' is denied.
escape file exists: False

Confined execution works again and the write boundary is still enforced (the escape write was denied), so this does not silently degrade to unconfined execution.

Side effect: runnerCommand silently unregisters the bundled diagnosis skill

@deepseek-ai/dsh-sandbox-local/lib/index.js:

if (process.platform === "win32" && this.runnerCommand === void 0) ctx.inject(["skills"], (skillsCtx) => {
    registerAclDiagnosisSkill(skillsCtx);
});

As soon as runnerCommand is set, diagnose-windows-sandbox-acl disappears from the skill catalog with no warning. Anyone using the documented escape hatch loses the diagnostic entry point exactly when they are most likely to need it. Two small improvements would help:

• register the skill regardless of runnerCommand (the ACL repair work is backend-independent), or
• emit a notice when a custom runner suppresses a bundled skill.

Related minor observations on the custom-runner path

• enforcement is reported as "full" for a custom runner, while the Windows ACL backend is actually partial;
• DENIAL_SIGNATURES.runnerCommand is ["read-only file system", "permission denied"], which does not match the Windows denial text (Access to the path ... is denied.), so sandbox denials render as plain non-zero exits instead of the [sandbox: file access denied ...] marker.

中文摘要

按上面的 runnerCommand workaround 在桌面版实测：重启后切回 workspace-write，受限命令恢复正常执行，越界写仍被拒绝，隔离未被削弱。但配置 runnerCommand 会让内置的 diagnose-windows-sandbox-acl 技能静默消失（代码见上），建议改为无条件注册，或在自定义 runner 抑制内置技能时给出提示。

[argszero]

Your root cause holds up at source, and your follow-up corrects three things — one of which is a real defect I do not think you have spotted the full shape of. Everything below is checked against master at 687f282e86.

The root cause: confirmed, and the code comment argues against itself

packages/sandbox/sandbox-local/src/index.ts:571-580, windowsAclRunnerInvocation():

// :568 (docstring)
// The prefix stays `[node, runner, ...]` — a future native-exe runner keeps
// the same argv contract and only swaps these entries.
if (existsSync(builtEntry)) return [process.execPath, builtEntry]        // :575
return [process.execPath, '--import', `data:text/javascript,…`, sourceEntry]  // :579

The docstring says the prefix is [node, runner, ...]; the code ships process.execPath, which under the desktop app is the GUI-subsystem DeepSeek Harness.exe. That gap between the prose and the fact is exactly the shape you measured.

I would add one piece of evidence in your favour that the module does not state anywhere: packages/sandbox/sandbox-windows-acl/src/runner.ts:1-45 documents the argv contract, both modes, the temp-SID contract and the failure contract in detail, and says nothing about a console. There is no AllocConsole / GetConsoleWindow call anywhere in that package's sources. So the requirement "the runner must own a console" is real, is fatal when unmet, and appears in neither the code nor its documentation. Your node runner.js … runbook line in sandbox-windows-acl/README.md:113 works only because a console host is assumed.

Your two extra rows are the sharpest part of the report, and the source agrees with the mechanism:

• read-only passing: runner.ts:20-25 says the two modes are identical except that read-only carries no capability SIDs. That is the only difference between your working row and your failing rows.
• notepad passing: a GUI-subsystem child never needs a console, so the console-creation step that kills pwsh/cmd/node never runs.

Your three follow-ups, one at a time

(a) The diagnosis skill disappearing — documented and test-pinned, but your case falsifies the premise it rests on.

This is not a regression. The gate is sandbox-local/src/index.ts:298-303:

// An operator-supplied runner does not use the ACL backend. The registry
// remains optional and may be mounted after this provider.
if (process.platform === 'win32' && this.runnerCommand === undefined) {
  ctx.inject(['skills'], (skillsCtx) => { registerAclDiagnosisSkill(skillsCtx) })
}

It is documented twice — sandbox-local/README.md:45 ("built-in selection and probes are skipped") and README.md:83 ("An operator-supplied runnerCommand does not register it") — and pinned by the last block of sandbox-windows-acl/tests/skill-composition.spec.ts, which loads a custom runner and asserts the skill list is empty. So "silently" is true at runtime and false in the docs.

But the comment's premise is "an operator-supplied runner does not use the ACL backend", and your workaround is the counter-example: a custom runner that is the ACL backend, only hosted in node.exe. That makes your suggestion (a) right but under-stated. The fix is not "register regardless" — for a container-wrapper runner the ACL repair really is irrelevant. The fix is that backend identity is being inferred from runnerCommand when only the operator knows it; the config surface needs a way to say "this custom runner is the windows-acl backend", and the skill should key on that rather than on the absence of an override.

(b) enforcement: 'full' — the contract, not a bug, and the cost lands on you.

index.ts:331 hardcodes enforcement: 'full' on the custom-runner branch. That is deliberate: sandbox-local/README.md:45 says "full enforcement is asserted", and :135 says "runnerCommand is an operator assertion — a configured custom runner skips functional probes and is assumed to implement the bwrap-compatible profile honestly". So the overstatement is the documented price of the escape hatch, and it is the operator who pays it. Your reading is fair, but the argument to make upstream is "the assertion should be expressible per runner", not "the value is wrong".

(c) The denial dialect — this one is a real defect, and it is worse than you described.

index.ts:207-215:

const DENIAL_SIGNATURES = {
  bwrap: ['read-only file system'],
  landlock: ['permission denied'],
  seatbelt: ['operation not permitted'],
  // pwsh/.NET: "Access to the path '...' is denied."; cmd: "Access is denied.";
  // Node EACCES: "permission denied"; EPERM: "operation not permitted".
  'windows-acl': ['access is denied', 'access to the path', 'permission denied', 'operation not permitted'],  // :213
  runnerCommand: ['read-only file system', 'permission denied'],                                             // :214
}

The Windows rung's four signatures were enumerated deliberately, with the dialect of each source named in the comment above them. The runnerCommand row then replaces that list with the bwrap/Landlock dialect. So on Windows, taking the documented escape hatch subtracts the two signatures that actually occur (Access is denied., Access to the path … is denied.) and adds one that cannot occur there (read-only file system). Your diagnosis of the rendering is correct, and the cause is not "the list is missing Windows text" — it is that configuring runnerCommand selects a different signature table, not a merge of them. A one-line fix exists: the custom row should be the union, or carry its own config field beside runnerFailureSignatures.

There is a fourth asymmetry you did not name, in the same branch. RUNNER_FAILURE_RULES (index.ts:233-242) has no runnerCommand key — only the four built-in rungs. The custom branch at :333 emits runnerFailureRules: [{ fatalSignatures: this.configuredRunnerFailureSignatures }], with no allowedExitCodes. The built-in windows-acl rule is exit-gated on 127 precisely so that, in the words of the comment at :224-234, "a confined command that merely PRINTS the signature (or a runner cleanup failure reported on a non-zero child exit) is never misclassified as 'the command did not run'". On the custom path that protection is gone: any confined child that echoes windows-acl-run: at any exit status is read as a runner failure rather than as the command's own output. Your shim picks "windows-acl-run" as its signature, which is the right string, but nothing stops a child from producing it.

Suggested fix

Your option 1 (AllocConsole() when GetConsoleWindow() is null, optionally hidden) is the narrower one: it repairs the runner where the defect lives, keeps one runner program, and does not depend on how the desktop bundles its runtime. Your option 2 needs the app.asar.unpacked caveat you already noted, and it changes which binary the seam trusts. The runnerCommand workaround is a legitimate third path, and it is worth noting in the README next to the console requirement — which is currently written down nowhere.

A note on tooling

This failure family is what @argszero/cordis-plugin-sandbox-grant-advisor (npm, 0.27.0) is built for: it watches confined tool results and reports which cause in the family the failure matches, so the operator gets "host image / no console" versus "missing write grant" instead of a bare 0xC0000142. It is advice, not a fix — for this particular shape its remedy list already names the two entry points you verified (a real node host; AllocConsole as the fallback), and a GUI-subsystem host as the cause. Mount it if it saves you a round of triage; the fix still belongs in the runner.

[user070212]

Confirming on a different environment: Windows 10 22H2 (19045), dsh-desktop 0.12.0, running elevated (Administrator, High mandatory level).

Every confined command dies identically: exit code 3221225794, no stdout, no stderr — cmd /c echo ok as well. Switching the session to full access makes the same shell work immediately (pwsh 5.1.19041.6456), so the target binary itself is fine.

Two data points that may widen the report:

1. The Windows Sandbox optional feature (Containers-DisposableClientVM) is Disabled on this machine and the symptom is identical, so the failure does not depend on that feature being installed.
2. Running the app elevated (High mandatory level) does not help — the GUI-subsystem / no-console condition still applies.

The runnerCommand workaround is not reachable here: the only node on this box is harness/.desktop-bin/node.cmd, which is ELECTRON_RUN_AS_NODE=1 wrapped around the same GUI-subsystem exe, so it provides no console either. A genuine console-subsystem node.exe would be required.

[GavinMo1]

The bash stack has the same defect, but it fails silently (exit 0, no output) instead of crashing — and the "bash has no Windows runner" premise looks narrower than it reads.

Environment: DSH Desktop 2.0.18, harness 0.2.1-rc.2, Windows 11 build 26200, workspace-write.

1. Reproduction

Profile desktop, cordis.patch.yml:

- id: pwsh-sandbox
  disabled: true
- id: bash-sandbox
  disabled: false
- id: tool-pwsh
  disabled: true
- id: tool-bash
  disabled: false

That is the complete recipe from 2026-08-01-windows-pwsh-default.md. The bash tool is then callable, and every call returns:

(no output)  [exit code: 0]

echo x > file creates no file; exit 42 reports 0. Both shell tools are affected because they share ctx.shell.

2. Root cause: same argv composition, different failure mode

sandbox-local/src/index.ts:575 emits [process.execPath, builtEntry, ...]. Under the desktop that is the GUI-subsystem binary. The pwsh stack survives because dsh-plugin-desktop/windows-pwsh-sandbox rewrites the argv (adaptWindowsAclExecution) and sets ELECTRON_RUN_AS_NODE=1. The bash stack has no equivalent: bash-sandbox is upstream, the argv goes out unchanged, and the Electron executable starts as a second desktop instance, forwards to the running one, and exits 0.

Measured directly on the same machine:

# un-adapted argv (what the bash stack produces)
".../DSH Desktop.exe" runner.js --workspace <ws> --temp <tmp> --mode workspace-write -- bash -c 'echo hi; exit 42'
# → no output, exit 0, 446 ms

# identical argv, only ELECTRON_RUN_AS_NODE=1 added
ELECTRON_RUN_AS_NODE=1 ".../DSH Desktop.exe" runner.js ... -- bash -c 'echo hi; exit 42'
# → hi, exit 42

So 0xC0000142 is the pwsh-shaped symptom. On the un-adapted bash path there is no child process at all, and the tool layer cannot tell: parseExitStatus (dsh-shell) returns exitCode: 0 when no marker is present, and the tools only append a marker for non-zero exits. "The command never ran" renders identically to "it ran and printed nothing" — which is a worse failure than a crash, because the model treats it as success.

3. Second, independent gap: dsh-bash-local has no bashPath

execute() hardcodes ["bash", "-c", command] and resolves through PATH. On Windows that PATH resolution reaches C:\Windows\System32\bash.exe (the WSL launcher stub) before any user-installed bash, and under the restricted token it dies with Wsl/E_ACCESSDENIED. dsh-pwsh-local has pwshPath for exactly this reason; dsh-bash-local has no counterpart.

4. "bash has no Windows runner" is narrower than it reads

The note says bash-sandbox/tool-bash carry disabled: !!js process.platform === 'win32' because bash has no Windows runner. The community reads that as "MSYS/Cygwin cannot start under the restricted token" — true, the signal pipe cannot be created — and every Windows bash plugin I could find gates itself to danger-full-access as a result.

The premise holds for MSYS-derived runtimes, but not for a bash that does not need a Cygwin runtime. With a non-MSYS bash (niubash/winuxcmd bash.exe) the ACL runner works:

workspace-write: bash -c 'echo hi; exit 42'   → hi, exit 42
read-only      : bash -c 'echo hi'            → hi
workspace-write: write inside workspace       → allowed
workspace-write: write outside workspace      → Permission denied, exit 1

No console trampoline was needed on this path once ELECTRON_RUN_AS_NODE=1 was set; the console requirement discussed above is the pwsh/console-child case.

5. Suggested fix

1. Extract adaptWindowsAclExecution out of windows-pwsh-sandbox and reuse it for the bash sandbox, or ship a windows-bash-sandbox twin. The rewrite is provider-agnostic (process.execPath + the ACL runner), so a shared helper is the smaller change.
2. Give dsh-bash-local a bashPath config beside pwshPath.
3. Fail loud rather than reporting success: a settled handle with no output should not be indistinguishable from a real exit 0 when the runner child never started.

I have a local patch for (1) and (2) running here and am happy to share the diff, or to open a PR against the desktop repository if that is the right home for the adapter.

---

Disclosure: this reproduction, analysis and patch were produced by an AI coding agent — DeepSeek Harness running the deepseek-flash model — with a human operator driving it on their own workstation. The operator applied and verified the change locally.

[Lubin-Github]

补充验证：workspace-write 与 read-only 在无控制台宿主下的行为差异

感谢 #810 / #10066 / #10362 的详细分析——根因结论（宿主无控制台 → 受限令牌下控制台子进程无法完成 DLL 初始化）与本地独立复现结果一致。本帖补充一组逐位复刻 @deepseek-ai/dsh-sandbox-windows-acl 构造方式的对照数据，其中一条为 #10066 中「read-only 有时能跑」提供了精确边界。

方法

不经过 DSH 进程，直接在独立脚本中按 asar 内源码逐项复刻：

1. OpenProcessToken(GetCurrentProcess(), MAXIMUM_ALLOWED)
2. findLogonSid：扫描 TokenGroups，取带 SE_GROUP_LOGON_ID 的 S-1-5-5-x-y
3. 能力 SID 按真实派生算法生成：
   S-1-4-<SHA256(path)[0..3] % (2^30-1) + 1>-<SHA256(path)[4..7] % (2^30-1) + 1>（temp 变体追加 -1）
4. CreateRestrictedToken(token, 13, ...)，restricting 列表按 mode 选择
5. SetTokenInformation(TokenIntegrityLevel, S-1-16-4096)
6. setTokenDefaultDaclGrant：SetEntriesInAclW 将 temp write SID 以 FILE_ALL_ACCESS 并入 TokenDefaultDacl
7. STARTUPINFO：cb=104、dwFlags=257（USESTDHANDLES|USESHOWWINDOW）、wShowWindow=0（SW_HIDE）
8. 三根独立匿名管道；stdin 读端可继承，父进程立即关闭 stdin 写端
9. CreateProcessAsUserW(token, NULL, cmdline, ..., creationFlags=0, ...)

唯一改变的变量是父进程是否附着一个控制台（FreeConsole() / AllocConsole()）。

结果

目标 pwsh.exe（PowerShell 7），命令 -NoLogo -NoProfile -NonInteractive -Command "Write-Output HELLO; exit 7"：

mode	父进程控制台	结果
read-only	有	exit 7，stdout HELLO
read-only	无	exit 7，stdout HELLO
workspace-write	有	exit 7，stdout HELLO
workspace-write	无	exit 3221225794 (0xC0000142)，stdout 空

结论

失败要求同时满足两个条件：受限于 workspace-write 的 restricting 列表，且父进程无控制台。

• read-only 的 restricting 列表不含能力写 SID，故无控制台时仍可正常启动 —— 这为 Windows: confined commands die with 0xC0000142 because the sandbox runner is the Electron (GUI-subsystem) binary #10066 中「read-only 有时能跑」给出可复现的判定条件。
• workspace-write 在无控制台宿主下稳定失败，与 [Bug] 桌面版 0.2.1-rc.2 / Windows：workspace-write 下所有 shell 命令 0xC0000142（独立复现） #10362 现象一致。

对 #10066 修复建议的补充数据

在无控制台父进程下，对受限子进程的启动标志做了穷举，验证「子进程自带控制台」是否可行：

启动方式	结果
creationFlags = 0	❌ 0xC0000142
creationFlags = CREATE_NO_WINDOW (0x08000000)	❌ 0xC0000142
creationFlags = CREATE_NEW_CONSOLE (0x00000010)	❌ 0xC0000142
父进程先 AllocConsole()，再以 creationFlags = 0 启动	✅ exit 7

即：无法通过子进程侧的控制台标志绕过，必须在 runner 侧先取得控制台（或如 #10066 建议改用控制台子系统的 node.exe）。这与 #10066 的结论方向一致，此处补充了「子进程侧两种标志均无效」的实测依据。

环境（已脱敏）

项	值
DSH	0.2.1.0
OS	Windows 11 x64，10.0.22631
PowerShell	7.6.6（C:\Program Files\PowerShell\7\pwsh.exe）
宿主	桌面版，进程树内无控制台（AttachConsole 返回 ERROR_INVALID_HANDLE）
账户	内置管理员账户，High 完整性（UAC 关闭）
会话策略	workspace-write（失败）/ danger-full-access（正常）

另外一点（与 #10066 的 read-only 描述相关）

若按 #10066 修复方案 2 改用随包 node.exe 作为 runner 宿主，需要注意它在 app.asar.unpacked 下的路径与 asar 边界问题——该 caveat 在 #10066 中已有说明，此处不重复。

---

本数据来自一次独立复现，不依赖 DSH 进程内状态；脚本未提交（仅在本地临时目录运行）。