DSH Desktop 0.2.0-rc.2（Windows）受限 shell 缺陷报告

[pede-w]

项	内容
报告日期	2026-10-12
产品	DeepSeek Harness Desktop
版本	桌面包内置 @deepseek-ai/dsh-*@0.2.0-rc.2；更新通道 nightly
操作系统	Windows 10.0.26200（Win11 26200，64 位，SSD NTFS）
Shell	PowerShell 7（C:\Program Files\PowerShell\7\pwsh.exe）
严重级别	高（受限模式下 shell 完全不可用，且无满足原始诉求的规避路径）
复现率	100%（同一会话内每次必现；跨会话、跨新建目录、跨盘符均必现）
影响模式	workspace-write（受限）全部失败；read-only（受限）正常

---

1. 摘要

在 Windows 上，当会话的文件策略为 workspace-write 时，任何一条 shell 命令都会在进程初始化阶段立即失败：

exit code 3221225794  (0xC0000142, STATUS_DLL_INIT_FAILED)
stdout: 空
stderr: 空

• 同一条命令在 danger-full-access 下正常；
• 把沙箱降为 read-only 时，受限 shell 反而能正常工作（exit 0，正常输出）。

因此问题不是“受限令牌机制不可用”，而是专属于 workspace-write 的沙箱供给路径（ACL 授权、完整性标签、TMP 与 TEMP 重写）执行之后，受限子进程无法完成早期 DLL 初始化。

该现象在以下条件下均稳定复现：工作区与安装目录位于非系统盘（D:）、位于系统盘（C:）、工作区为全新空目录、临时目录与工作区重叠或分离、临时目录长名或 8.3 短名、父进程有控制台、第三方 HIPS 安全软件全防护开启、存在旧版本残留。以上变量已逐项排除（见第 5 节）。

---

2. 环境（已打码）

项	值
用户与主机	XXX\XXX
DSH 安装目录	D:\Program Files\DS（非系统盘）
DSH 主目录	C:\Users\XXX\.dsh（DSH_HOME，系统盘）
当前 profile	C:\Users\XXX\.dsh\profiles\desktop（DSH_PROFILE=desktop）
工作区	D:\XXX\XXX（非系统盘，NTFS；普通目录，非 junction，非 subst，非网络盘）
会话策略	permissions.sandbox = workspace-write，approval = ask
安全软件	火绒安全软件（HIPS）在测试期间全程运行：服务 HipsDaemon 与内核驱动 sysdiag.sys、hrdevmon.sys、hrwfpdrv.sys 均为 Running
其它	本机另有一份旧版源码编译安装的残留（根包 @deepseek-ai/dsh-root@0.1.3-alpha.1），安装 0.2.0 桌面版时未卸载

---

3. 现象与期望

3.1 现象

• 会话 sandbox=workspace-write 下，任何 shell 调用（含 Write-Output "ok" 这类零副作用命令）：
  • 立即结束，无任何输出（stdout 与 stderr 均为空）；
  • 退出码恒为 3221225794 或 0xC0000142（STATUS_DLL_INIT_FAILED）；
  • 前台执行与后台任务执行结果一致。
• 把该次调用放宽为 danger-full-access 后，同一命令立即正常（输出 hello）。
• 把沙箱模式改为 read-only 后，受限 shell 正常（输出 SANDBOX-OK，exit 0）。

3.2 期望

1. workspace-write 下 shell 可用，且写入被限制在工作区与私有临时目录内；
2. 若沙箱无法建立，应 fail-closed 并给出可读的失败原因，而不是把裸 0xC0000142 暴露给用户；
3. 至少应给出可操作的提示（例如当前系统上受限 shell 不可用，可切换到完全权限或改用 read-only）。

---

4. 关键定位证据

4.1 实际进程链（在放宽模式下抓取）

pwsh.exe  ←  DeepSeek Harness.exe  ←  DeepSeek Harness.exe  ←  explorer.exe
                │
                └─ argv: "...\app.asar\dsh\node_modules\@deepseek-ai\dsh-subprocess-local\lib\runner.js"
                         -- "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command "..."

结论要点：

• 受限模式下真正被启动的是打包在 app.asar 内的 subprocess runner（@deepseek-ai/dsh-subprocess-local@0.2.0-rc.2）与 @deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2、@deepseek-ai/dsh-pwsh-sandbox@0.2.0-rc.2；与旧版残留、与安装盘符无关。
• 失败时没有 runner 自身失败的特征输出（按包文档，runner 侧失败会向 stderr 打印 windows-acl-run: <detail> 并以 127 退出），说明 runner 已成功启动，是它下面的受限子进程在 DLL 初始化阶段死亡。
• Windows 应用程序日志中近 3 小时内没有任何 pwsh 相关崩溃记录，说明 pwsh 很可能从未执行到用户代码。

4.2 最小复现（不经过 harness，直接调用打包的 runner）

set ELECTRON_RUN_AS_NODE=1
"D:\Program Files\DS\DeepSeek Harness.exe" --expose-internals ^
  "D:\Program Files\DS\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js" ^
  --workspace "C:\Users\XXX\dsh-sbx-ws" --temp "C:\Users\XXX\dsh-sbx-temp" --mode workspace-write -- ^
  "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command "Write-Output SANDBOX-OK"

说明：桌面程序是 GUI 子系统进程，从终端调用时不会阻塞，也拿不到输出，需用 Start-Process -Wait 一类方式等待并重定向 stdout 与 stderr（完整脚本见附录 A）。

4.3 对照结果（同一父进程、同一 runner、同一时间窗）

模式	工作区	临时目录	退出码	stdout
workspace-write	C 盘全新空目录	C 盘独立目录	0xC0000142	空
workspace-write	C 盘全新空目录	系统 TEMP（8.3 短名 XXX~1）	0xC0000142	空
workspace-write	D 盘全新空目录	C 盘独立目录	0xC0000142	空
read-only	C 盘全新空目录	C 盘独立目录	0	SANDBOX-OK

两模式的唯一差别：workspace-write 额外做了三件事：给工作区与私有临时目录写 ACL 授权、设置完整性标签、重写子进程的 TMP 与 TEMP。

4.4 参考：包内自带的实现说明（随产品分发的文档与代码注释）

• 令牌为 WRITE_RESTRICTED 受限令牌，限制 SID 列表：
  • read-only：[登录 SID, EVERYONE]
  • workspace-write：[登录 SID, EVERYONE, 工作区 SID, 可选临时 SID]
• 注释明确 (登录 SID + EVERYONE) 是保活组：“缺少它时早期 DLL 初始化会以 0xC0000142 死亡”；
• 包文档另载：“以 CREATE_NO_WINDOW 与 CREATE_NEW_CONSOLE 创建的子进程会在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡；子进程共享宿主控制台，基于管道的 stdio 重定向不受影响。”

这两条与本次现象部分吻合但不足以解释：按代码 workspace-write 仍保留保活组；且父进程有控制台时依然失败（见第 5 节第 7 项）。

---

5. 已尝试的排查、假设与结果

#	假设或方案	具体做法	结果	结论
1	沙箱整体不可用	将单条命令放宽为 danger-full-access 后执行	正常执行	可用，但属绕过而非修复；不能替代受限模式
2	会话切到完全权限	会话策略改为完全权限	正常（预期内）	与诉求冲突（要求保留 workspace-write）
3	工作区权限缺失	读取工作区根及各级祖辈目录的全部权限项	祖辈权限正常；工作区上只有两条预期项：Everyone: 拒绝 DeleteSubdirectoriesAndFiles、DSH 自身的 S-1-4-XXX-XXX: 允许 Write、Delete、DeleteSubdirectoriesAndFiles	权限供给已物化，未见缺失
4	受限身份读不到非系统盘上的程序文件（C 盘有 AppContainer 标准授权、D 盘没有）	对比 C 盘与 D 盘的 ACL（ALL APPLICATION PACKAGES 与 ALL RESTRICTED APPLICATION PACKAGES）；再用 C 盘全新工作区跑 workspace-write	C 盘有该两类授权，D 盘均无；但 C 盘全新工作区仍 0xC0000142	排除：与盘符、与 AppContainer 读取授权无关
5	DSH 装在非系统盘导致	用 D 盘全新空目录作工作区再跑	仍 0xC0000142	排除：把安装目录或工作区搬到 C 盘不会解决
6	路径短名，或工作区与临时目录重叠	用长名目录，并把工作区与临时目录彻底分开	仍 0xC0000142	排除
7	控制台（父进程无控制台，系统为子进程新建控制台，触发文档记载的失败模式）	检查进程链与 conhost；在有控制台的父进程下跑受限 runner	父进程有控制台时：read-only 成功，workspace-write 仍失败	排除控制台为触发条件
8	第三方安全软件（HIPS 内核过滤）拦截受限令牌进程创建	关闭杀软托盘后重测；并以 read-only 作对照	杀软服务与内核驱动仍在运行的情况下，read-only 受限 shell 成功	基本排除（若其拦截受限令牌创建，read-only 亦应失败）
9	旧版 0.1.x 源码编译安装的残留干扰	检查 PATH、注册表环境变量、全局 dsh 命令、运行中的旧进程、端口占用、profile 依赖	全部干净：无相关环境变量，无全局命令，无旧进程，端口由当前桌面版独占，profile 仅依赖 dsh-context 与 zod	排除；最小复现完全未涉及旧版残留，故障照旧
10	旧版遗留的计划任务在干扰	检查计划任务与孤儿启动器	存在 DSH Doctor Supervisor（Ready），其目标脚本已不存在	与 shell 链路无交集，属噪音而非原因
11	产品自带沙箱 ACL 诊断工具	评估是否运行	未运行	该工具面向目录无法完成授权供给的场景；本次授权供给已成功物化，且该工具会写入权限，不属于同类故障
12	文档记载的保活组缺失导致 0xC0000142	对照 0.2.0-rc.2 的打包注释	注释显示两模式均保留 (登录 SID, EVERYONE)	现有证据不足以支持该路径；失败更像发生在 workspace-write 的供给副作用之后
13	重启 DSH 客户端或新建会话说	未做（需用户侧操作）	待验证	仍建议作为低成本显影步骤
14	定位到更精确的 Win32 失败点（哪个 DLL，哪个访问被拒）	需要 0.2.0 的源码或调试符号	无法进行	用户侧只有打包后的代码

---

6. 影响面

能力	状态
文件类工具（读、写、编辑、检索）在 workspace-write 下	正常（不受影响）
shell（pwsh）在 workspace-write 下	完全不可用（100% 失败）
shell 在 read-only 下	正常
shell 在完全权限下	正常
依赖 shell 的自动化（脚本、构建、本地工具链、测试）	受限模式下全部中断；用户被迫在完全放开与没有 shell 之间二选一

---

7. 用户侧无法解决的部分

1. 无法在保留 workspace-write 的前提下获得受沙箱约束的 shell。 沙箱供给与受限子进程创建都在产品内部完成，用户侧没有任何可用开关可以改动这一层。
2. 无法定位到精确的 Win32 失败点。 需要 0.2.0 的源码、调试符号或内核级跟踪；用户侧只有 app.asar 内的打包产物，而失败发生在进程初始化阶段，连用户代码都未执行。
3. 无法靠更换安装位置或工作区位置解决。 已在 C 盘与 D 盘的全新空目录上分别复现（含安装目录在非系统盘、工作区在非系统盘的各种组合）。
4. 无法靠禁用安全软件解决。 关闭杀软托盘后故障不变；反证是同一杀软全防护状态下 read-only 受限 shell 正常。
5. 无法靠清理旧版本残留解决。 最小复现完全不涉及旧版文件；且清理旧版只会移除排查所需的参考源码，不影响故障。
6. 无法自行确认是否为单机环境特性。 缺少第二台机器或纯净系统作对照，无法区分本机特有的系统策略与累积更新差异，还是版本普遍缺陷。
7. 当前只能降级规避（两者都不满足原始诉求）：
   • 保留 workspace-write，把每一条 shell 命令单独放宽（需要逐条批准）；
   • 或整会话切到完全权限（改变原有的沙箱使用方式）。

---

8. 对开发者的问题定位建议

1. 在 workspace-write 供给完成后补一步自检：用受限令牌起一个最小进程（例如 cmd /c exit 0 或 pwsh -Command exit），捕获退出码；失败即 fail-closed，并给出可读原因，而不是让用户看到裸 0xC0000142。
2. 对比两模式的令牌差异：重点检查 workspace-write 是否给子进程附加了低完整性标签，以及该标签与早期 DLL 初始化（如 CNG 设备写入）之间的相互作用。
3. 把 runner 的 stderr 完整回传给工具结果：目前用户侧看不到 windows-acl-run: <detail> 一类诊断信息，失败信息量几乎为零。
4. 提供诊断与降级开关：允许把授权、标签、TMP 与 TEMP 重写这几步分开执行并逐步输出结果，便于定位是哪一步之后子进程开始起不来。
5. 补充验证矩阵：把 read-only 通过而 workspace-write 失败这组对照纳入 Windows 冒烟用例，且必须覆盖父进程无控制台的桌面宿主场景。
6. 对用户暴露可操作提示：受限 shell 不可用时直接提示可选路径（完全权限、read-only、报告该问题），避免用户长时间在黑箱中试错。

---

9. 打码对照

报告中	实际内容类型
XXX\XXX	用户名与主机名
D:\XXX\XXX	用户工作区路径
C:\Users\XXX\...	用户主目录及其子路径
S-1-4-XXX-XXX	由工作区路径派生的沙箱身份 SID
S-1-15-3-XXX	系统卷上的能力 SID（机器相关）
XXX~1	8.3 短名中的用户名部分
session-XXX	会话 ID

未打码且需保留的信息：产品与包版本号、Windows 版本号、盘符与是否系统盘、NTFS、标准系统路径（C:\Program Files\...）、公开的第三方软件产品名、退出码与命令原文。

---

附录 A：可直接运行的复现脚本（PowerShell）

只读、可安全运行：仅在系统临时目录下创建测试目录，结束时删除。
运行前把 <DSH_INSTALL> 替换为实际安装目录（例如 D:\Program Files\DS）。

$exe    = '<DSH_INSTALL>\DeepSeek Harness.exe'
$runner = '<DSH_INSTALL>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'
$pwsh   = 'C:\Program Files\PowerShell\7\pwsh.exe'

$ws  = Join-Path $env:TEMP 'dsh-sbx-ws'
$tmp = Join-Path $env:TEMP 'dsh-sbx-temp'
New-Item -ItemType Directory -Force -Path $ws, $tmp | Out-Null

$env:ELECTRON_RUN_AS_NODE = '1'

function Invoke-Sbx([string]$mode) {
  $o = Join-Path $tmp "out-$mode.txt"
  $e = Join-Path $tmp "err-$mode.txt"
  $arg = '--expose-internals "' + $runner + '" --workspace "' + $ws + '" --temp "' + $tmp +
         '" --mode ' + $mode + ' -- "' + $pwsh + '" -NoLogo -NoProfile -NonInteractive -Command "Write-Output SANDBOX-OK"'
  $p = Start-Process -FilePath $exe -ArgumentList $arg -Wait -PassThru -NoNewWindow `
        -RedirectStandardOutput $o -RedirectStandardError $e
  $hex = ($p.ExitCode -band 0xFFFFFFFF).ToString('X8')
  "mode=$mode  exit=0x$hex"
  "  stdout: " + ((Get-Content -LiteralPath $o -ErrorAction SilentlyContinue) -join "`n")
  "  stderr: " + ((Get-Content -LiteralPath $e -ErrorAction SilentlyContinue) -join "`n")
  Remove-Item -LiteralPath $o, $e -Force -ErrorAction SilentlyContinue
}

Invoke-Sbx 'workspace-write'   # 缺陷：预期 0xC0000142，无任何输出
Invoke-Sbx 'read-only'         # 对照：预期 exit 0，输出 SANDBOX-OK

Remove-Item Env:ELECTRON_RUN_AS_NODE -ErrorAction SilentlyContinue
Remove-Item -LiteralPath $ws, $tmp -Recurse -Force -ErrorAction SilentlyContinue

预期输出（本机实测）：

mode=workspace-write  exit=0xC0000142
  stdout:
  stderr:
mode=read-only  exit=0x00000000
  stdout: SANDBOX-OK
  stderr:

---

附录 B：本次排查使用的只读检查（可复现）

1. 确认沙箱模式与策略：读取会话投影中的 sandboxMode 与 permissions（值：workspace-write，approval=ask）。
2. 确认 shell 调用链：枚举进程及其命令行，定位 subprocess-local 与 sandbox-windows-acl 的 runner 与最终 pwsh 的 argv。
3. 确认无崩溃记录：查询 Windows 应用程序事件日志（近 3 小时，匹配 pwsh、DeepSeek、Harness）与 WER 报告目录，结果 0 条。
4. 确认权限供给：读取工作区根与祖辈目录的权限项；对比 C 盘与 D 盘的 AppContainer 标准授权。
5. 确认无旧版干扰：检查用户与机器环境变量、PATH、全局命令、监听端口属主、profile 依赖清单。
6. 确认打包版本：只读解析 app.asar 头部目录，列出 @deepseek-ai/dsh-* 包名与版本（0.2.0-rc.2）。
7. 隔离实验：以 --mode read-only 与 --mode workspace-write 交叉对照，分别更换工作区盘符、临时目录位置与命名形式。

以上均为只读操作；除自建的临时测试目录外，未修改任何文件、权限与配置。

[PerryLink]

你的报告质量很高（对照实验、排除项、ACL 观测与代码逐条对得上）。你引的两段"包内自带说明"我逐字找到了源码位置 —— 而且这恰好能让两条你标为"部分吻合但不足以解释"的线索直接结案。另外你有两处排除逻辑不成立。

1. 你引的两段，源码逐字在此

• packages/sandbox/sandbox-windows-acl/README.md:127 → 「Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142); children share the host console, and pipe-based stdio redirection is unaffected.」
• packages/sandbox/sandbox-windows-acl/src/token.ts:187-189 → 「The logon SID + EVERYONE keep-alive group is shared by both modes: early DLL init dies with 0xC0000142 and CNG (\Device\CNG write trustee — pwsh crashes 0xE0434352) fails without them.」
• 第三处独立复述：README.md:102
• 还有第四处：assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1:151-152

2. ⭐ 因此「keep-alive 组缺失」可以排除

token.ts:224-228 的 createRestrictedToken 在两种模式下都带 [logonSid, world]，workspace-write 只是追加能力 SID。

⇒ 你 §5 第 12 项写"现有证据不足以支持该路径" —— 方向要改：这不是"证据不足"，而是排除该路径的正面证据。建议把它从怀疑清单里划掉。

3. ⭐ 你漏掉的第四个差异（也是我建议上游先查的一处）

你说 workspace-write 相对 read-only 多做了三件事（ACL / 标签 / TMP 重写）——还有第四件：

packages/sandbox/sandbox-windows-acl/src/index.ts:304：

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

两种模式给「令牌默认 DACL」加的 SID 不同（read-only 走 worldSid，workspace-write 走能力 SID）。这是你那张对照表里唯一没被点名的变量，也是最值得先查的一处。

⚠️ 顺带说明：另有人（#9507）独立报到了同一行。两帖合看，变量能收敛到这一处。

4. ⚠️ 排除逻辑不成立之一：低完整性标签

你 §8.2 猜"检查 workspace-write 是否给子进程附加了低完整性标签" —— 这条可以放一放：index.ts:290 的 restrictTokenIntegrity(api, restrictedToken, lowLabelSid) 在两种模式都执行（read-only 也降 Low）。而你的对照正是"read-only 正常" ⇒ 它解释不了差异。

5. ⚠️ 排除逻辑不成立之二：控制台

你 §5 第 7 项写"父进程有控制台时仍失败 ⇒ 排除控制台" —— 这个推理不成立。README:127 那条边界的触发条件是「创建子进程时传了 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE」，不是"父进程有没有控制台"。

而产品自身的 win32-process 明确不传这两个 flag：packages/subprocess/win32-process/src/process.ts:454-456 → // Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization.（只加 CREATE_SUSPENDED，:542）；win32-process/README.md:35 复述。

正确结论应是：

产品路径不该命中该边界 ⇒ 要么有别的调用方加了这些 flag，要么是第三条未知成因。

——这是可执行的下一步，比"排除控制台"有用得多。

6. 你另外几处判断我确认（请保留）

• §5 第 11 项「未运行诊断脚本」+ 理由在本帖成立：你的工作区上已有 S-1-4-* 项 ⇒ grantWrite 曾经成功过（它同时写 DACL + LABEL，acl.ts:255-259）⇒ 本帖失败点在更后面（子进程创建/初始化），与 [Bug] workspace-write: 所有 shell 命令因预授权缺 WRITE_OWNER 失败 (SetNamedSecurityInfoW Win32 5) #9510 不是同一故障。这个区分很重要，建议在报告里显式写明。
• §4.1 的进程链正确：受限时启动的是 dsh-subprocess-local/lib/runner.js，再由它起 dsh-sandbox-windows-acl/lib/runner.js，再到 pwsh.exe；argv 前缀由 sandbox-local/src/index.ts:571-575 决定。
• §4.1「失败时没有 windows-acl-run: <detail> 特征输出」判断正确：assets/.../runner.ts:40-43 + :210-227 规定 runner 侧失败才打印签名并以 127 退出；0xC0000142 是子进程退出码被 runner 如实镜像（:221 process.exitCode = exitCode）⇒ 不会出现该签名。你 §8.3 那条建议（回传 stderr）因此有依据。
• §5 第 3 项的 ACL 读取结论与代码一致，可以放心采信：「Everyone 拒 DeleteSubdirectoriesAndFiles」= acl.ts:395-397 的 buildExplicitAccess(worldSidPtr, abi.DENY_ACCESS, abi.FILE_DELETE_CHILD, abi.CONTAINER_INHERIT_ACE)；「DSH 自身的 S-1-4-… 允许 Write、Delete、DeleteSubdirectoriesAndFiles」= win32-abi.ts:28 的 GRANT_MASK = 0x00110156。
• dispose() 不撤销工作区授权、也不撤销 Low 标签 —— 说对了：index.ts:34-42 → 「WORKSPACE grants are deliberately never revoked — the ACE is the cross-session reuse cache」；README.md:128/129 同义。

7. ⚠️ 一处要更正：源码是公开的

你 §7.2 写"无法定位到精确的 Win32 失败点（只有 app.asar）" —— 部分不成立。你手上的桌面包里就带着 dsh-sandbox-windows-acl 的 README 与打包 JS（你自己都读到注释了），而源码在公开 npm 包与公开仓库里。⇒ 你其实已经具备定位条件，缺的只是"去找公开源码"这一步。这条更正对你有利。

8. fail-closed 现状（你 §3.2/§8.3 的诉求有依据）

如实说明给维护者：runner 先授权再 spawn，子进程退出码是被镜像的（runner.ts:210-227），所以 0xC0000142 不会变成 SANDBOX_UNAVAILABLE、也不会有 windows-acl-run: 诊断行。⇒ 你要求的"可读原因 + 回传 stderr"是合理的产品改进项，建议照原样保留。

9. 版本与边界

你写内置 @deepseek-ai/dsh-*@0.2.0-rc.2、更新通道 nightly。相关代码在 origin/master（= dsh-v0.2.1-alpha.2）上一致 ⇒ 未过期。
⚠️ 注意：nightly 不是 npm dist-tag 名（那是 next/alpha），但桌面包内置的版本号你读对了。
⚠️ 「为什么只有 workspace-write 崩」我无法在本仓证伪/证实 —— 缺的证据是：在 0.2.0-rc.2 上按公共 API 复现你 §4.3 那张 2×2 表，并同时打印调用方的 creationFlags。这是唯一能把结论从"推测"变成"定位"的一步，建议补上。

[pede-w]

AI回复AI这一块哦，我还以为进moltbook了...

[pede-w]

补充证据与一处更正：崩溃与子进程无关，故障域在 workspace-write 的沙箱供给环节

先更正本线程里的一处假设：该故障并非 pwsh 7 或 .NET 特有。同一台机器、桌面版内置 0.2.0-rc.2、随包自带的 runner，除模式与子进程之外参数完全相同，结果如下。

子进程	read-only	workspace-write
pwsh 7.6.6	退出 0，输出 hi-pwsh7	退出 3221225794（即 0xC0000142），stdout 与 stderr 全空
Windows PowerShell 5.1	退出 0，输出 hi-ps51	0xC0000142，零输出
cmd.exe	退出 0，输出 hi-cmd	0xC0000142，零输出
node 24.18.1	退出 0，输出 hi-node	0xC0000142，零输出
Git Bash（msys2）	0xC0000142，signal pipe 创建被拒（Win32 5）	0xC0000142，零输出

四点结论：

1. workspace-write 下任何子进程都在 DLL 初始化阶段死亡，包括 cmd.exe 这种最朴素的进程，而且没有任何输出。所以问题不在 shell，也不在 .NET 运行时，而在 workspace-write 的供给或进程创建环节。
2. 同一批子进程在 read-only 下全部正常，差异被锁死在两种模式各自的供给差异上。
3. 换 shell 底层、或把 pwsh 路径指向 Windows PowerShell 5.1，都不能规避（5.1 同样 0xC0000142）。
4. msys2 的 bash 在两种受限模式下都不可用，原因是它需要创建命名管道做信号处理，这与 README 记录的命名管道边界一致。所以换用 Git Bash 同样不是出路。

复现方式（参数说明；路径含空格时请调用方自行加引号）：

• 入口：安装目录下 resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js
  注意 asar 内的真实层级比常见引用多一层 dsh。
• 运行方式：把环境变量 ELECTRON_RUN_AS_NODE 设为 1，用桌面版可执行文件把该入口当作 node 脚本执行。
• 参数顺序：先给工作区（参数名 workspace，前置两个连字符），再给临时根目录（参数名 temp，同样前置两个连字符），再给模式（参数名 mode，前置两个连字符，取 read-only 或 workspace-write），然后是一个只由两个连字符构成的独立参数，最后是子进程及其参数。
• 子进程依次替换为上表五者，其余参数保持不变。
• 另一处现场：同一会话内，DSH 的 pwsh 工具在 workspace-write 下 4 次调用 4 次以 0xC0000142 退出，命令仅为输出一行字。

与 9510 的区别（依据本线程上一条回复的描述）：本工作区上已存在 S-1-4 开头的授权项，说明 grantWrite 曾经成功过，它同时写 DACL 与标签，因此本文故障点在更后面的子进程创建与初始化阶段，与预授权缺 WRITE_OWNER 的 Win32 5 失败不是同一故障。

建议排查方向（尚未证实）：workspace-write 相对 read-only 的独有差异目前收敛到三处。README 说明 keep-alive 组缺失会让早期 DLL 初始化以 0xC0000142 死亡，而令牌默认 DACL 属于同一类开关，因此建议优先看 setTokenDefaultDaclGrant 的实参在 workspace-write 下由 Everyone 变为能力 SID 这一处；其次是工作区与私有临时目录的授权与 Low 标签；再次是 TMP 与 TEMP 重写。另外建议把子进程退出码与 stderr 如实回传：目前 0xC0000142 被静默镜像为零输出，使用者拿不到任何可读原因。

环境：桌面版内置 @deepseek-ai/dsh-* 0.2.0-rc.2；pwsh 7.6.6；node 24.18.1；Windows。

[PerryLink]

你这张表把变量消掉了一个：五个子进程（含 cmd.exe 这种最朴素的）在 workspace-write 下全部死在 DLL 初始化、且零输出 ⇒ 故障与子进程无关，这个推论成立。基于你的数据，我能把候选差异从三处收到两处，并给出一条代码可支撑、且一行就能验证的新假设。

1. 候选差异收到两处（Low 标签可以划掉）

你列的"三处独有差异"里，低完整性标签不成立：

packages/sandbox/sandbox-windows-acl/src/index.ts:290：

restrictTokenIntegrity(api, restrictedToken, lowLabelSid)

它在两种模式下都执行（紧接着 :285-289 的 createRestrictedToken，没有任何 mode 分支）。⇒ 既然你的 read-only 列全部成功，低标签就不是差异源。

于是只剩两处：

1. 令牌默认 DACL 里那个 SID（:304）
2. 私有临时目录及其 ACL/标签（read-only 用 ambient tmpdir() 且不带 SID；workspace-write 用私有 temp 目录 + temp-write SID）

2. ⭐ 一条新假设：index.ts 的取舍理由只论证了 pass-2，没有论证 pass-1

index.ts:292-303 的原文（我逐字引）：

The restricted token's default DACL still names only the user's ambient SIDs — none of the restricting SIDs. Every NEW object the confined process creates (anonymous stdio pipes, sync objects) takes its DACL from that default, so the write pass-2 check would deny pipe creation… Merge a full-access ACE for a restricting SID (the PRIVATE temp SID when present, otherwise the workspace SID, or Everyone under read-only): new-object creation stays gated by the parent object's DACL, while the new object's own DACL passes pass-2. Choosing the temp SID prevents default-DACL objects in one session's temp tree from acquiring the shared workspace capability.

注意它只说了 pass-2 通过。 而写受限令牌的访问检查是两道都要过。关键在两个 SID 的身份不同：

packages/sandbox/sandbox-windows-acl/src/token.ts:224-228：

const restrictingSids = buildRestrictingSids(mode === 'read-only'
  ? [logonSid, known.world]
  : … [logonSid, known.world, ...writeSids])

⇒ 写 SID 只加入「限制列表」，不进令牌的常规组（createRestrictedToken 的 0, null 就是"不添加/不禁用任何 SID"，:233-234）。而 Everyone 本身就是任何令牌的常规 SID。

所以两种模式下，默认 DACL 那条 FILE_ALL_ACCESS ACE（token.ts:128）命中的对象是：

模式	默认 DACL 新增 ACE 的 SID	该 SID 是否在令牌常规组里
read-only	Everyone	是
workspace-write	私有 temp SID / 工作区 SID（S-1-4-x-y）	否（只进限制列表）

假设：如果一个新建对象的 DACL 只命名一个"只存在于限制列表"的 SID，那么 pass-1（常规检查）无从匹配 ⇒ 对象对创建者自己也变成不可访问 ⇒ 而进程初始化期间映射 DLL 恰恰就是在创建对象 ⇒ 0xC0000142、零输出。这与你观察到的"连 cmd.exe 都死在 DLL 初始化"完全对得上。

⚠️ 一个诚实的反证需要考虑：注释说这个 ACE 当初修好了管道创建（"would deny pipe creation… Merge…"），说明它至少对管道是生效的。所以这条假设要么说明管道走在受影响路径之外，要么说明真正的差异在第二处（temp 目录）。我不把它当结论 —— 它是一个能被一次实验判定的问题。

3. ⭐ 一行判定实验（诊断用，不是修复）

把 index.ts:304 的 SID 强制成 worldSid：

setTokenDefaultDaclGrant(api, restrictedToken, worldSid)   // 诊断：让 workspace-write 也命名 Everyone

然后重跑你那张表的 cmd.exe 一行：

• 若 cmd.exe 起来了 ⇒ 差异确实在这一条 ACE 的 SID 上，假设成立；
• 若仍然 0xC0000142 ⇒ 差异在第二处（私有 temp 目录及其 ACL/标签），请把 --temp 换成 ambient 目录再试一次，两者可完全分离。

⚠️ 必须说清：这只是诊断，不是修复。:301-303 明确写了选 temp SID 是有意的 —— 目的是"防止某个会话 temp 树里的默认-DACL 对象拿到共享的工作区能力"。真按 worldSid 修，受限子进程新建的所有对象都会带上 Everyone:(F)，而它们不在任何被贴 Low 标签的目录里 ⇒ 同用户的任意 Medium 完整性进程都能写它们。所以请把这条写成"用于定位的实验"，并把它作为对上游的问题提（"index.ts:292-303 的取舍理由是否需要补充 pass-1 的论证"）。

4. 你那条 msys2 记录是对文档的独立确认（建议保留）

read-only 下 Git Bash 报"signal pipe 创建被拒（Win32 5）"，与 packages/sandbox/sandbox-windows-acl/README.md:102 一带记录的命名管道边界一致 ⇒ 这是一个额外收获，说明你的探针可靠。建议在报告里点明"这解释了为什么换 Git Bash 不是出路"。

5. 你与 #9510 的区分正确

你写"本工作区已存在 S-1-4 授权项 ⇒ grantWrite 曾经成功 ⇒ 本文故障在更后面的子进程创建与初始化，与缺 WRITE_OWNER 的 Win32 5 不是同一故障" —— 完全正确，而且这个区分很重要（grantWrite 一次同时写 DACL 与 LABEL，所以有那个 ACE 就证明它成功过）。建议在报告开头就把这句放上去，避免维护者把两帖混为一谈。

6. 退出码与 stderr 回传：你说得对，缺口在这两行

• packages/sandbox/sandbox-windows-acl/assets/diagnose-windows-sandbox-acl/… 与 src/runner.ts:210-227：runner 在子进程正常退出时如实镜像其退出码（:221 process.exitCode = exitCode）⇒ 0xC0000142 被如实报成命令失败、零输出。
• windows-acl-run: 这个诊断签名只在 runner 自身失败时才打印（:40-43）；sandbox-local/src/index.ts:241 的 fatalSignatures: ['windows-acl-run: '] 也据此判定 ⇒ 本故障必然不会带该签名。

⇒ 所以你 §8.3 的诉求（把子进程退出码与 stderr 如实回传、并给出可读原因）有明确依据，建议照原样保留。

7. 边界（按规矩标注）

• 我无法在本机证伪或证实第 2 节那条假设 —— 那需要 Windows 受限令牌实验，仓库里没有。
• 你建议的"其次是工作区与私有临时目录的授权与 Low 标签；再次是 TMP 与 TEMP 重写"这个排序，我同意第 2 项应提到与第 1 项并列（因为 Low 标签与模式无关，所以第 2 项里真正剩下的是私有 temp 目录的存在与否，而不是标签）。
• 环境与版本我按你给的对齐（桌面内置 0.2.0-rc.2）；相关代码在 origin/master（= dsh-v0.2.1-alpha.2）上一致。