DeepSeek Harness Windows 0xC0000142: desktop vs dsh web

A plain echo ok returns 0xC0000142 under workspace-write in the Windows desktop app, with not a single byte on stdout or stderr — the command is not wrong; the restricted child process died during DLL initialization. On the same DSH and the same machine, launching through dsh web works, and that single comparison narrows the field to the host shape. The community reproduced the same pattern on both Windows 11 26200 and Windows 10 19045 (#10483, #10706).

DeepSeek Harness: Triage: ask three questions before touching config

Ask the three questions in order: does the desktop app fail, does dsh web fail, and is it every exe or only PowerShell? The combination of answers usually lands on one of three causes.

1. In the desktop app, create a session, choose "write in workspace", and have the agent run echo ok; record the exit code. Seeing 3221225794 or 0xC0000142 puts you in this family.
2. Rerun the same command under "full access" (danger-full-access). If it works, token construction, ACLs, and paths are fine and the fault is only on the restricted path.
3. Launch the same workspace through dsh web (the Node host), switch to workspace-write, and run it again. This step is the dividing line for the whole article.
4. If you have a launch flag like --no-sandbox, try it once; if that starts, you are looking at Chromium's install-directory check, which is out of scope here.

Read the comparison results straight off the table:

DSH plugin: Cause 1: the GUI host has no console, so the restricted child cannot start

The desktop app is an Electron GUI subsystem process and has no console by nature; under a restricted token the child cannot create a usable console either, conhost initialization fails, and the process exits during DLL initialization — hence zero output.

1. Confirm the host type: in Task Manager, look at the parent of DeepSeek Harness.exe; if it is explorer.exe, the app was started as a GUI.
2. Rerun the same command in the same workspace through dsh web. The web build is started by node.exe and inherits a real console from the terminal, so the whole runner chain has one.
3. If the web build works, the "host has no console" explanation is confirmed and you do not need to touch ACLs.
4. When the community checked the source, they also inspected the release package: the current build's app.asar contains zero occurrences of ensureWindowsConsoleHost and AllocConsole, meaning the trampoline fix that gives Electron a console (a1caef3) did not make it into this build.

This also explains why "starting the desktop app from a terminal" fails the same way: a GUI subsystem process does not attach to the parent's console.

DeepSeek Harness: Cause 2: CREATE_NEW_CONSOLE is the actual failure point

A restricted token plus "needs a new console" always fails; inheriting an existing console, or creating none at all, starts normally. Six host/flag combinations pinned this down.

The community ran an A–F comparison that changed only the host process and creationFlags:

Two follow-up experiments are worth remembering: after adding a hidden console to the runner (AllocConsole + SW_HIDE), PowerShell built-ins ran, but external programs launched from it still failed; switching to DETACHED_PROCESS let cmd run, yet PowerShell would not even execute -Command, because its ConsoleHost needs a real console.

So "just add a hidden console" is only half right: it proves the root cause but does not fix handle inheritance.

DSH Plugin: Cause 3: path DACL carries a foreign package SID — run the bundled script

If every command fails regardless of content or cwd, consider the third cause: a path the child must read has a DACL containing another AppContainer tool's package SID, which the low-integrity token cannot open.

The official package README (packages/sandbox/sandbox-windows-acl/README.md) documents two causes and one structural limitation:

1. The keep-alive group (logon SID + Everyone) is missing from the token.
2. The child is created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE, and the README notes console isolation is unavailable.
3. The path DACL carries a foreign package SID — earlier sandbox tools or an older DSH may have stamped the workspace or install tree, which triggers this one.

For the third case the package ships a diagnostic and repair script, run as a non-restricted identity:

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

The script backs up and verifies every DACL change, removes foreign package ACEs at the source, refuses reparse points and managed app directories, and finally prints a rollback command. The rc.2 (687f282e) release package already includes this script, so you do not need to wait for rc.3.

DeepSeek Harness: Why uninstalling and reinstalling does not help

ACLs live on directories, not in program files; the uninstaller will not add ACEs and clearing AppData will not either. So "reinstall once" does nothing for any of the three causes.

1. Do not reinstall yet; confirm the direction with the triage table above.
2. When you need the repair script, run it from a non-restricted PowerShell window, not from a shell inside the DSH sandbox.
3. The script requires RecoveryDir; keep the backup and roll back with the command it prints if something goes wrong.
4. If the script reports "nothing to repair", you are not in cause 3 — go back to cause 1 or 2.
5. A separate "app will not start after reinstall" problem is left behind by the uninstaller and is not the same as the shell's 0xC0000142; do not debug them together.

DSH plugin: Cautions

Do not turn a triage result into a permanent configuration.

1. Do not let danger-full-access become the long-term answer. It is a triage tool, not a fix.
2. Do not change tokens, ACLs, and launch flags at the same time. One variable at a time, or reproductions mean nothing.
3. Use --no-sandbox only as a signal. If it starts, you are in the install-directory access-check layer; running that way long-term disables the browser sandbox.
4. Windows 10 and Windows 11 both hit it. The community reproduced it on 19045 and 22621, so do not treat it as an OS-version threshold.
5. Record the version number and commit first. Differences between rc.2 and rc.3 affect whether you can tell if it is already fixed.

If dsh web works and the desktop app does not, the easiest temporary option is to keep working in the web build; staying on desktop means waiting for the host side to add the console trampoline.See DSH plugin: Windows subprocess fails with 0xC0000142 for the related case.