[Баг] Windows: команды в workspace-write падают с 0xC0000142, в полном доступе работают

[chsergei07-ship-it]

Проблема: на Windows в режиме Permission = Workspace Write любая команда агента
завершается кодом 3221225794 (0xC0000142) без вывода. Если переключить Permission
на полный доступ и начать новую сессию — те же команды работают. Это известный баг
песочницы или что-то в конфигурации?

Окружение

• DSH desktop 0.2.1-rc.3, Windows 11 10.0.26300.9711, канал nightly
• PowerShell 7.6.8 (Core), Node v24.22.1, npm 11.19.1

Шаги воспроизведения

1. Settings → General → Permission → Workspace Write
2. Новая сессия
3. Попросить агента выполнить echo test

Фактический результат
[exit code: 3221225794] — 0xC0000142, пустой stdout/stderr.
То же самое для whoami, Get-Location и любой другой команды.

Ожидаемый результат
Команда выполняется в песочнице и возвращает обычный вывод и код.

Контрольный опыт (та же машина, те же бинарники, Permission = полный доступ,
новая сессия):

Команда	Результат
echo test	вывод есть, код 0
node -v / npm -v	v24.22.1 / 11.19.1, код 0
execSync('echo hello')	hello, код 0
stderr и код 3	передаются корректно

Дополнительно

• Тот же код был ещё до установки PowerShell 7, когда pwsh.exe в системе
  отсутствовал — значит дело не в поиске бинарника.
• Не проходит после перезапуска приложения и после перезагрузки ОС.
• В журнале «Приложение» нет записей Application Error / WER для pwsh.exe
  и DeepSeek Harness.exe.
• В workspace-write файловые инструменты (read/write/glob/grep) работают
  и корректно ограничены — падает именно создание процессов.
• Инструмент показывает только голый код, без подсказки, на каком этапе
  упала песочница.

Вероятная причина: процесс создаётся, но умирает при инициализации DLL,
то есть виноват лаунчер песочницы Windows, а не PowerShell.

Просьба: подскажите, известный ли это баг и есть ли обходной путь, кроме
постоянного включения полного доступа.

[chsergei07-ship-it]

Root cause found: workspace-write restricted token's default DACL names a restricting-only SID

Environment

• DSH Desktop 0.2.1-rc.3, profile desktop
• Windows 11 26H2, build 10.0.26300.9711
• Package: @deepseek-ai/dsh-sandbox-windows-acl@0.2.1-rc.3

Symptom

Under workspace-write, every pwsh / cmd command exits with 3221225794 (0xC0000142, STATUS_DLL_INIT_FAILED) and produces no output. danger-full-access works. read-only also works.

Minimal reproduction

Calling AclSandbox directly (no ACL grants, no temp directory) and spawning cmd.exe /c echo is enough:

const sb = new AclSandbox({
  writableDirs: [ws],
  tempDir: null,
  writeSid: workspaceWriteSid(ws), // or another SID
  mode: 'workspace-write',
  manageDacls: false,
})
await sb.init()
const child = sb.spawn({ command: 'cmd.exe', args: ['/c', 'echo', 'x'], stdio: 'piped' })
console.log((await child.wait()).exitCode)

writeSid	Exit code
workspaceWriteSid(ws) (derived capability SID)	3221225794
S-1-1-0 (Everyone)	0
S-1-5-32-545 (Users)	0
current user SID	0
arbitrary SID not in the token (S-1-5-21-…-9999)	3221225794
mode: 'read-only' (no write SID)	0

The same failure occurs when the runner uses stdio: 'inherit', so it is not specific to piped stdio.

Why

AclSandbox.init() does:

findLogonSid(...) // later
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)

setTokenDefaultDaclGrant merges a full-access ACE for that SID into the restricted token's default DACL. The workspace/temp write SIDs exist only in the token's restricting SID list, not in its normal groups. Objects the child creates without an explicit security descriptor inherit this default DACL. The write-SID ACE satisfies only the restricting (pass-2) check; the normal (pass-1) check has no usable matching SID, so creation is denied. For the loader this happens while creating section objects for DLL mappings, so the process dies with STATUS_DLL_INIT_FAILED.

read-only works because its default DACL trustee is Everyone, which is present in both the normal and restricting lists.

The package comment says this was verified on Windows 11 26200. This host is 26300, so either a Windows behavior change exposed it or the bug was latent.

Suggested fix

Add a SID that is present in both lists — ideally the logon SID that findLogonSid already extracts — to the default DACL, in addition to the write SID. For example, move findLogonSid before the default-DACL step and merge an ACE for it (or use it as the trustee), while keeping the write SID in the restricting list for the workspace grants. Using Everyone as the default-DACL trustee (as read-only does) would also work but is broader.

Until this is fixed, the practical workaround is danger-full-access; read-only runs commands but denies writes.

[devdemo2026-ctrl]

I always got these errors too despite dsh is set to use "Workspace Write":

Edit
Error: invalid escalation: justification is only valid together with sandbox_permissions
Think
The edit tool failed again with the same invalid escalation error, indicating that the justification was used without sandbox_permissions. This is a persistent issue with my usage of the edit tool in this environment.

I must re-run the edit operation, but this time I need to specify sandbox_permissions: "workspace-write" to allow the modification, even if it feels like a minor change.

I will re-issue the edit command exactly as before, ensuring the sandbox_permissions flag is included. This should resolve the immediate technical roadblock.

[Jian-chan]

Adding cross-version and cross-OS data points for the same symptom. No new analysis —
your root cause and suggested fix already cover it.

Environment where it reproduces

DSH Desktop	0.2.1-rc.3 (nightly); also 0.2.1-rc.2 and 0.2.0-rc.2
OS	Windows 10 Enterprise LTSC 2021, 10.0.19044.1620 (x64)
PowerShell	7.4.19 (C:\Program Files\PowerShell\7\pwsh.exe, MSI)
Permission	workspace-write

So this is not specific to Windows 11 26H2 / 26300.9711: the same exit code
3221225794, empty stdout/stderr, and "works under full access" behaviour reproduce on
a Windows 10 build. That SKU is still in Microsoft support (mainstream until
2027-01-12), so it is not an end-of-life consumer build either.

It is long-standing rather than introduced in rc.3

Same failure on 0.2.0-rc.2, 0.2.1-rc.2 and 0.2.1-rc.3. Comparing the packaged
artifacts of @deepseek-ai/dsh-sandbox-windows-acl inside app.asar:

• lib/types-Cl_DXjhk.js — 64309 B, same content-hash chunk name on both 0.2.0-rc.2
  and 0.2.1-rc.3
• README.md — 26397 B on both 0.2.1-rc.2 and 0.2.1-rc.3
• package.json — 1709 B on both 0.2.1-rc.2 and 0.2.1-rc.3

Unchanged sizes and an unchanged content-hash chunk name mean the implementation did
not change across these releases. Combined with the failure predating them, the open
question in your comment ("either a Windows behaviour change exposed it or the bug was
latent") looks answered in favour of latent.

Three more small confirmations on this host

• cwd-independent: fails with the session workspace on D: as well as with
  C:\Users\<user> as the spawn directory.
• The runner does not fail: stderr is empty and the reported exit code is the child's
  termination code. lib/runner.js's own failure contract would print
  windows-acl-run: <detail> and exit 127, which never happens.
• PowerShell version does not appear to matter: 7.4.19 here versus 7.6.8 there.

I have not re-tested read-only on this host (switching the session permission is a UI
action), so the read-only-works result is still single-sourced from your table.

One UX note seconding yours: the tool surfaces only the bare exit code, with no
indication of which stage failed, which is what makes this look like a PowerShell
problem rather than a spawn-time one.