Windows: sandboxed PTY shell (minimal preset) still fails at startup on 0.2.0-rc.1 — ACL runner exits 127 with NULL std handles

[EuniceAllen]

现象

Windows 11 (Build 26200) + DSH 0.2.0-rc.1：Agent 预设 minimal（持久 PTY shell）+ 任意沙箱（read-only / workspace-write）时，每条 pwsh 都返回 Error: PTY shell exited during startup，会话不可用；standard 预设或 danger-full-access 正常。0.1.7-rc.2 上已于 2026-09-25 通过应用内反馈提交，0.2.0-rc.1 复测仍 100% 复现。

根因（代码定位 + 实测）

沙箱下 PTY 后端把 [DeepSeek Harness.exe, …/dsh-sandbox-windows-acl/lib/runner.js, …] 当 ConPTY 子进程，即 GUI 子系统的桌面 exe（ELECTRON_RUN_AS_NODE=1）：

• 产品真实形态下（ConPTY 也由同一个 GUI exe 宿主创建），该子进程 GetStdHandle(-10/-11/-12) = 0/0/0，GetLastError()=6 ERROR_INVALID_HANDLE（而 libuv fd 0/1/2 正常指向 ConPTY）。
• @deepseek-ai/dsh-win32-process lib/index.js → inheritedStandardHandles()（~L551-566）必须用这些句柄填 STARTUPINFO(STARTF_USESTDHANDLES) 再 CreateProcessAsUserW（受限路径 ~L693）→ 第一步就失败，exit 127；同包非受限路径 targetCarrierHandles()（~L572-582）用 uv_get_osfhandle 且工作正常 —— 两条路径取句柄方式不一致就是 bug。
• runner 宿主固定为 [process.execPath, runner.js]（dsh-sandbox-local windowsAclRunnerInvocation() ~L539-553）；app.asar.unpacked 内没有该包，也没有配置 windowsAclRunnerEntry。
• runner 的 stderr 到不了 PTY：dsh-terminal-bash 只从 confine() 取 .argv（~L968-971）并抛通用错误（~L501 / ~L989）；管道型沙箱（dsh-bash-sandbox / dsh-pwsh-sandbox）会消费 runnerFailureRules，PTY 路径不会。
• win32 链只有单档位（PLATFORM_CHAINS.win32 = ["windows-acl"]），不做功能探测，因此不会 fail-closed。

实测（2026-09-28，同一台机器，0.2.0-rc.1）

项	结果
ConPTY → GUI exe 子进程句柄	0 / 0 / 0（对照 console node.exe：504/508/512，type=2）
runner --mode read-only → cmd	exit 127，0 字节输出
runner --mode workspace-write（seam SID）→ cmd	exit 127，0 字节输出
对照：纯 cmd /c echo	exit 0，输出正常

补充：若 ConPTY 改由控制台子系统的 node.exe 创建，GUI 子进程能拿到有效句柄、runner 也能镜像子进程退出码，但受限子进程的 stdout/stderr 仍到不了 PTY（0 字节），那条路同样不可用。

最小复现

父进程必须是 GUI exe（否则不复现；控制台 node.exe 当父进程时走的是上面那条"无输出"路径）：

$env:ELECTRON_RUN_AS_NODE = '1'
& '<install>\DeepSeek Harness.exe' .\pty-repro.cjs 'C:\path\to\workspace'

脚本（A 对照 / B read-only / C workspace-write，read-only 不改任何 ACL）我放在下面回复里，避免正文过长。

建议修法

1. 让沙箱 runner 跑在控制台子系统宿主：把 dsh-sandbox-windows-acl（+ dsh-win32-process / dsh-subprocess / koffi / @koromix/koffi-win32-x64）落盘到 resources/app.asar.unpacked，用自带 resources/runtime/primary-runtime/dependencies/node/bin/node.exe 启动 runner.js。
2. 或至少给 inheritedStandardHandles() 加 uv_get_osfhandle 兜底；注意这只消除 127，GUI 宿主下子进程输出仍到不了 ConPTY，接线也要一起修。
3. PTY 路径同样消费 runnerFailureRules（或至少透出 runner stderr），不要把沙箱启动失败报成 PTY shell exited during startup。
4. 在此之前，对 windows-acl + PTY 做探测/fail-closed，或明确标注 Windows 上 minimal + 沙箱暂不支持。

其他

• 0.2.0-rc.1 新增的 diagnose-windows-sandbox-acl 技能不覆盖此类问题（只处理 ACL 拒绝访问）。
• 与 PowerShell 版本无关：cmd.exe payload 一样 127，失败发生在任何 shell 被拉起之前。
• 临时规避：用 standard 预设或 danger-full-access。
• 相关帖（同报错文案 / 同区域，根因不同）：Web 端 bash 工具在无 /bin/bash 系统上全部失败：PTY shell exited during startup #1913、[Bug] rc.7 breaks the persistent PTY shell on Windows (pid 0), node-pty 1.1.0 → 1.2.0-beta.15 #2851、[Bug Report] Windows: sandbox permanently fails after Storage Sense deletes the session's private temp directory #1406。

EN TL;DR

• On Windows, minimal preset + any sandbox mode (read-only/workspace-write) fails every pwsh call with Error: PTY shell exited during startup; standard or danger-full-access works. Reported in-app on 2026-09-25 against 0.1.7-rc.2 — still 100% reproducible on 0.2.0-rc.1.
• The PTY backend spawns the GUI-subsystem DeepSeek Harness.exe (node mode) as the ConPTY child. In the product's configuration its GetStdHandle(-10/-11/-12) are NULL (0/0/0, ERROR_INVALID_HANDLE), so the ACL runner dies in inheritedStandardHandles() (dsh-win32-process ~L551-566, used by CreateProcessAsUserW) with windows-acl-run: GetStdHandle failed (Win32 0): null stdin handle → exit 127. The same file's unrestricted path uses uv_get_osfhandle and works.
• dsh-terminal-bash only takes .argv from confine() and reports the generic message, swallowing the runner diagnostic that the pipe-based sandboxes do consume.
• Measured 2026-09-28 on 0.2.0-rc.1: runner read-only and workspace-write both exit 127 with 0 bytes of output; plain cmd /c echo under the same ConPTY works.
• Fix: host the runner in a console-subsystem process (ship dsh-sandbox-windows-acl under app.asar.unpacked and launch it with the bundled node.exe), plus an uv_get_osfhandle fallback and surfacing runner failures on the PTY path.
  BUG报告.md
  GitHub发帖-PTY沙箱-0.2.0-rc.1.md
  GitHub发帖-回复1-复现脚本.md
  GitHub发帖正文.md
  Uploading PTY-启动失败-实测结论.md…