Windows desktop app: every sandboxed shell command fails with 0xC0000142 (STATUS_DLL_INIT_FAILED)

[1zyao]

Windows desktop app: every sandboxed shell command fails with 0xC0000142 (STATUS_DLL_INIT_FAILED)

Summary

On Windows, the desktop app (Electron) cannot run any confined shell command. Under
workspace-write (and read-only), every pwsh/cmd/git/… invocation spawned through
@deepseek-ai/dsh-sandbox-windows-acl returns empty output with [exit code: 3221225794]
= 0xC0000142 STATUS_DLL_INIT_FAILED. Only danger-full-access works.

Root cause: the ACL sandbox spawns children that must share the host process's console, and
the desktop Host runs under Electron as a GUI process without a console.

Environment

• Windows 11 Pro for Workstations 23H2, build 22631, x64
• DeepSeek Harness desktop 0.1.7-rc.2 (Electron 44.0.0, bundled Node 24.18.1)
• Same failure reproduced with sandbox package 0.2.0-rc.1 (published 2026-09-28)
• Account: built-in Administrator (SID …-500), UAC disabled — but this is not the cause (see isolation below; plain Node works on the same account)
• Workspace on NTFS

Evidence

@deepseek-ai/dsh-sandbox-windows-acl's own README (Verified boundaries / Modes) states:

children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with
STATUS_DLL_INIT_FAILED (0xC0000142); children share the host console …

So the sandboxed child needs the host to own a console. The desktop Host is an Electron
(ELECTRON_RUN_AS_NODE) process, which is a GUI-subsystem process with no console (and Chromium
frees any inherited console). Every confined child therefore dies during DLL init.

Minimal isolation

Same machine, same script, same package — only the host process differs. The script creates an
AclSandbox (workspace-write) and spawns cmd /c echo hello:

import { mkdtempSync } from 'node:fs';
import { tmpdir } from 'node:os';
import { join } from 'node:path';
import { AclSandbox, tempWriteSid, workspaceWriteSid } from '@deepseek-ai/dsh-sandbox-windows-acl';

const workspaceRoot = mkdtempSync(join(tmpdir(), 'dshws-'));
const tempDir = mkdtempSync(join(tmpdir(), 'dshtmp-'));
const sandbox = new AclSandbox({
  writableDirs: [workspaceRoot], tempDir,
  writeSid: workspaceWriteSid(workspaceRoot),
  tempWriteSid: tempWriteSid(tempDir),
  mode: 'workspace-write',
});
await sandbox.init();
const child = sandbox.spawn({ command: 'cmd', args: ['/c', 'echo', 'hello'], cwd: workspaceRoot });
const r = await child.wait();
console.log('exit=', r.exitCode, 'stdout=', JSON.stringify(r.stdout.toString()));

Host process	Has console	Result
node.exe (v24.19.0)	yes	exit=0, "hello\r\n"
DeepSeek Harness.exe with ELECTRON_RUN_AS_NODE=1	no	exit=3221225794
DeepSeek Harness.exe + AllocConsole() before spawn	yes	exit=0, "hello\r\n"

init() always succeeds; only the child dies. The same happens for pwsh, git, cargo, bun.

Web/CLI version is unaffected

In an older web/CLI setup (same machine/account, workspace-write), 283 pwsh calls succeeded
with zero 0xC0000142 — because that Host is node.exe (console subsystem, started from a
terminal). The desktop build is the one that breaks.

Impact

Any Windows user of the desktop app running under workspace-write or read-only gets a dead
shell tool. It is not an account/UAC/filesystem issue (the plain-Node run proves the sandbox and
machine are fine).

Suggested fix

Make the Host own a console before spawning confined children, e.g. call AllocConsole() (after
FreeConsole()) once at Host startup, or spawn confined commands via a ConPTY/pseudo-console.
AllocConsole() in the host was verified to make the sandbox work.

Reproduce

1. Install the desktop app on Windows.
2. Start a session and keep the default workspace-write permission mode.
3. Ask the agent to run any shell command.
4. Observe (no output) / [exit code: 3221225794].