[Windows] pwsh tool always fails with "PTY shell exited during startup" under workspace-write / read-only

[derec30240]

Summary

On Windows, the pwsh tool is unusable in any sandbox mode except danger-full-access. Every call fails with:

Error: PTY shell exited during startup

Root cause is not PowerShell. sandbox.confine() wraps the shell in a restricted token created with WRITE_RESTRICTED, and PowerShell 7 / Windows PowerShell 5.1 / node.exe all fail DLL initialization (0xC0000142 = STATUS_DLL_INIT_FAILED) under that token. cmd.exe and python.exe are unaffected.

Environment

• @deepseek-ai/dsh-desktop 0.2.1-rc.5 (Electron 44.7.0, Node 24.21.0)
• Windows 11 24H2, build 10.0.26100.9703, x64
• PowerShell 7.6.9 at C:\Program Files\PowerShell\7\pwsh.exe
• Sandbox mode: workspace-write (also reproducible in read-only)

Steps to reproduce

1. Set the session sandbox to workspace-write.
2. Call the pwsh tool with any command, e.g. echo hi.
3. Observe Error: PTY shell exited during startup.
4. Switch to danger-full-access — the same call succeeds immediately.

The failure happens at shell startup, before any command is sent: startupSession() sends ENCODING_PREAMBLE + PWSH_PROMPT_SETUP as the first input and gets waitReason === "session_exit".

Workaround currently in use

The only way to get a working shell on this machine is to keep the session in danger-full-access. That is not a real workaround — danger-full-access disables the sandbox entirely, so the trade is "no shell at all" versus "no sandbox at all". In practice we run the session unsandboxed just to be able to run commands.

We also wasted a long time on this because the error message points somewhere else entirely: we first assumed PowerShell was not installed, then that the pwsh in PATH was a broken Microsoft Store alias, then that ConPTY / conpty.dll was at fault. We installed PowerShell 7 (MSIX, then MSI), removed the Store build, restarted the app several times and rebooted the machine — none of it mattered. The sandboxed spawn was failing the whole time, and the error surfaced as a shell exit.

Root cause

spawnArgv() in the terminal backend only bypasses confinement for danger-full-access:

const argv = [config.shellPath, ...config.shellArgs];
if (policy.mode === "danger-full-access") return argv;
const sandbox = ctx.get("sandbox");
if (sandbox === void 0) throw new Error(`terminal-bash: sandbox mode "${policy.mode}" requires a ctx.sandbox provider in the execution world`);
return (await sandbox.confine(argv, { ...policy, mode: policy.mode }, signal)).argv;

On Windows the only runner is windows-acl (PLATFORM_CHAINS.win32 = ["windows-acl"], selected without a probe; STATIC_ENFORCEMENT["windows-acl"] = "partial"). It spawns the command through a restricted token built in @deepseek-ai/dsh-sandbox-windows-acl:

api.createRestrictedToken(currentToken, 13, 0, null, 0, null, restrictingSids.length / 16, restrictingSids, tokenSlot)

13 = DISABLE_MAX_PRIVILEGE(1) | LUA_TOKEN(4) | WRITE_RESTRICTED(8).

Evidence — minimal P/Invoke reproduction

Standalone script using OpenProcessToken + CreateRestrictedToken + CreateProcessAsUserW (no admin rights needed), spawning pwsh -NoLogo -NoProfile -Command "exit 42":

flags	restricting SIDs	low IL	result
0	—	no	exit 42, OK
1	—	no	exit 42, OK
5	—	no	exit 42, OK
13	—	no	0xC0000142
5	—	yes	exit 42, OK
13	—	yes	0xC0000142
13	Everyone	—	0xC0000142
13	Authenticated Users	—	0xC0000142
13	INTERACTIVE	—	0xC0000142
13	current user SID	—	0xC0000142

Same token (flags=13) applied to different binaries:

binary	result
cmd.exe /c exit 47	exit 47, OK
python.exe -c "sys.exit(46)"	exit 46, OK
node.exe -e "process.exit(45)"	0xC0000142
powershell.exe (Windows PowerShell 5.1)	0xC0000142
pwsh.exe (PowerShell 7.x)	0xC0000142

So the trigger is WRITE_RESTRICTED alone — low integrity level and the choice of restricting SID make no difference.

Possible directions

These are open questions rather than proposals — the first one in particular touches the security model, and I don't have enough context to judge whether it is safe. Treat them as input for whatever direction you'd prefer.

1. Is WRITE_RESTRICTED still needed for this spawn? Spawning with flags = 5 (dropping only WRITE_RESTRICTED) works, and the capability-SID DACL grants plus the low integrity label are still applied on top. If those two are considered sufficient by themselves, this would resolve the failure. If WRITE_RESTRICTED is load-bearing here, then perhaps it could be scoped to commands that don't need to initialise a large runtime — though I don't have enough context on the threat model to judge whether that is safe.
2. Would it be worth probing the Windows runner in probeRunner? Today win32 has a single candidate that is never probed, so a broken configuration is selected unconditionally. A real probe (spawn cmd /c exit 0 and a pwsh -NoProfile -Command exit 0 smoke test) would surface this as a clean SandboxUnavailableError instead of a misleading shell error.
3. Could a 0xC0000142 from the confined spawn degrade gracefully, instead of being reported as a shell exit?

Error mapping note

A failed spawn surfaces as waitReason === "session_exit" → throw new Error("PTY shell exited during startup"), which hides the actual STATUS_DLL_INIT_FAILED. Distinguishing "the process could not start" from "the shell exited" would make this far faster to diagnose.

[PedroCostinha]

Hi! The minimal token-flag reproduction provides strong evidence that the failure happens before PowerShell processes any commands.

I would recommend treating this as a sandbox compatibility issue, not as a PowerShell installation problem.

Before changing the restricted-token flags, I would add an automated Windows test matrix covering:

• PowerShell 5.1 and 7
• Node.js and a minimal native executable
• Read-only and workspace-write policies
• Allowed workspace writes and denied external writes

The test should verify both successful process initialization and enforcement of the intended restrictions.

Removing WRITE_RESTRICTED may resolve startup failures, but it should not be treated as safe without proving that the remaining controls provide equivalent protection.

Until a validated fix exists, the UI should report a sandbox initialization failure rather than misleading users with a generic PTY shell error.

[derec30240]

补充：这类 PTY 启动失败可能是两层故障叠在一起（2026-11-05 新环境复现）

重装系统后换了一个全新工作目录，同一条 Get-Location 报了一个原帖里没出现的错：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\...\default-workspace)

Win32 5 = ERROR_ACCESS_DENIED。icacls 看该目录，ACE 全部来自继承，当前用户最宽的权限只是 NT AUTHORITY\Authenticated Users:(I)(M)。Modify 包含写数据和写属性，但不含 WRITE_DAC / WRITE_OWNER——所以 dsh 准备给沙箱受限 SID 追加 ACE 的那一步必然失败。

也就是说，在「pwsh 起不来」前面还有一道门：dsh 要修改工作目录的 DACL，而当前用户对这个目录没有「修改权限」的权限。

给目录补一条显式 Full 之后（管理员 PowerShell）：

icacls "<工作目录>" /grant "<用户>:(OI)(CI)F" /T /C

（PowerShell 下权限串必须整体加引号，否则 (OI) 会被当子表达式执行，报「无法将 OI 项识别为 cmdlet」。cmd 下没有这个问题。）

授权生效后，grantWrite 那步通过，再跑同样的命令，报错立刻退回原帖描述的那一层：

Error: PTY shell exited during startup

也就是 CreateRestrictedToken 带了 WRITE_RESTRICTED（flags = 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED）→ pwsh 在 DLL 初始化阶段以 0xC0000142 退出 → 被上层报成 PTY 退出。

两点建议

1. grantWrite 失败时希望能直接报出「需要授予 WRITE_DAC / 建议显式授予 Full」的提示，而不是让它掩盖成后面的 PTY 失败。用户很容易误判为自己没装好 PowerShell——我这次就绕了好几圈才分清是两层。
2. 非 full-access 档位下 CreateRestrictedToken 是否必须带 WRITE_RESTRICTED，值得再看一眼。去掉这一位（flags 13 → 5，只保留 DISABLE_MAX_PRIVILEGE | LUA_TOKEN）在我的推测里应该能让 pwsh / node 正常启动，同时 DACL 上的 deny ACE 仍然挡得住越界写入。这一条我没有实测——因为不愿修改安装目录里的 app.asar，所以只作为建议提出，等官方判断。

环境：Windows 11 24H2（10.0.26100.9703），dsh 0.2.1-rc.5，pwsh 7.6.9（GitHub MSI 版，非商店版别名）。

[Dietr1ch]

I'm seeing the same error on a Linux system that does not sport /bin/bash, but I see this project hardcodes it as the default in many places.

I'd like to see a better error instead that detailed the shell used and raised the underlying errors.

Maybe the standard /bin/sh POSIX shell should be the hard-coded default, but $SHELL should be respected if set.

[SpookyWaste]

Follow-up: the PTY child that dies is the sandbox runner, not the shell

We reproduced this on DSH Desktop 0.2.2-rc.1 (Electron 44.7.0 / Node 24.21.0, Windows 11 x64, workspace-write). One clarification that may matter for triage: the failure happens before the shell starts, so it is not PowerShell-specific — any confined shell fails on this host. It is also a different layer from the WRITE_RESTRICTED / 0xC0000142 result above; we see both.

The process that exits is the ACL runner. With confinement, spawnArgv() hands the PTY the windows-acl runner, whose program is process.execPath (sandbox-local, windowsAclRunnerInvocation()): [process.execPath, <...>/dsh-sandbox-windows-acl/lib/runner.js, --workspace ..., --temp ..., --mode ..., --write-sid ..., --temp-write-sid ..., --, <shell>, <args>]. On the Desktop, process.execPath is DeepSeek Harness.exe, a GUI-subsystem executable.

What we measured (probes run outside the sandbox, because ConPTY allocation itself fails with EPERM inside a confined session; node-pty taken from the Desktop's own app.asar):

1. Replaying that exact argv under a pseudoconsole: the child exits after ~0.1 s with no output. startupSession() maps that to waitReason === "session_exit" → PTY shell exited during startup.
2. Replicating the runner's main() step by step (logging to a file, since the child's stderr is unusable): imports ok, win32/koffi bindings ok, SetConsoleCtrlHandler(null, 1) → 1, AclSandbox constructed and init() ok, then AclSandbox.spawn() throws Win32Error: GetStdHandle failed (Win32 0): null stdin handle (dsh-win32-process, inheritedStandardHandles). The runner then exits 127 (RUNNER_FAILURE_EXIT) and the shell is never created.
3. In that runner process GetStdHandle for stdin/stdout/stderr returns NULL, and CreateFileW("CONIN$") / CreateFileW("CONOUT$") fail with ERROR_FILE_NOT_FOUND (6): the process is not attached to the pseudoconsole at all.
4. Controls: the same runner invocation over pipes works (which is why the one-shot bash tool is unaffected), and the same ConPTY chain works when the runner program is a console-subsystem node.exe — the shell then starts, emits the OSC marker and stays alive.

Reading of the results. Under ConPTY only console-subsystem children are attached to the pseudoconsole and receive its standard handles; a GUI-subsystem child (the Electron executable) gets none, so the runner cannot inherit or create the shell's stdio and fails before spawning it. This explains why pwsh, bash, cmd or python would all fail identically, why conpty.dll vs system conhost makes no difference, and why the cause is masked: the runner has no stderr handle, so its own windows-acl-run: ... diagnostic never reaches the PTY and the backend only sees "the process exited".

[derec30240]

Thanks — this is consistent with what we observe, and we can add evidence from a
different failure mode on the same spawn path.

Environment: DSH Desktop 0.2.1-rc.5, Windows 11 24H2 (10.0.26100.9703), so this is
not specific to 0.2.2-rc.1. Worth noting that the shell dsh actually picks up here is
Windows PowerShell 5.1 (5.1.26100.7920), not pwsh 7 — the thread title says pwsh, but
the reported symptom is not about which PowerShell is installed.

Before we could reach the runner-failure stage at all, the same spawn failed one step
earlier, in the ACL grant:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)

The workspace had only inherited ACEs — no explicit entry for the user, the widest
being Authenticated Users:(I)(M) — and Modify does not include WRITE_DAC/WRITE_OWNER,
so grantWrite was denied. After icacls "<workspace>" /grant "<user>:(OI)(CI)F", the
same session and the same working directory started failing with

PTY shell exited during startup

instead. Two things follow from that sequence:

1. The spawn path performs at least two distinct steps before any shell exists — a DACL
   grant on the workspace, then the confined runner. As each stage is repaired, the
   failure moves one step further down the chain, which is consistent with your finding
   that the shell is never created at all.
2. Both stages collapse into the same user-facing string, so repairing the earlier one
   looks like "nothing changed" from outside. That is the failure-masking pattern Pedro
   described, but it is worth recording that the mislabelling is not only cosmetic: it
   hid an entire preceding fault class.

On the runner exit code: 127 (RUNNER_FAILURE_EXIT) is itself a usable discriminator.
Even with no stderr channel at all, if startupSession() surfaced the exit code, the
backend could distinguish "the runner died before spawning the shell" from "the shell
started and exited". That signal already exists and is discarded one layer above the
code that needs it — it would be a cheap partial answer to the "report sandbox
initialization failure" item.

One direction that may be worth testing (we measured the failure, not this fix): the
program handed to the PTY probably should not be a GUI-subsystem process.execPath.
Either ship a console-subsystem helper for the runner, or have the runner attach to the
console explicitly before creating the child.