DSH 沙箱初始化失败：工作区位于数据盘时 grantWrite 报 Win32 5（缺 WRITE_OWNER），会话内一切命令不可用

[MOOS2046]

TL;DR
只要工作区不在用户目录下（例如新建的 D:\新建文件夹，ACL 来自盘符默认继承），并且会话文件策略是受限模式（workspace-write），DSH 在该工作区启动时执行的工作区授权（grantWrite）就会失败：

代码块

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:<工作区>)
失败后该会话内所有经沙箱的命令全部不可用——包括完全不需要写入的只读命令（Get-Date 也一样）。文件读写工具不受影响，表现为「文件能看，命令全废」。报错本身不足以自我诊断。

根因：grantWrite 以 WRITE_DAC | WRITE_OWNER 打开工作区根目录，而数据盘的默认继承 ACL 下，账户只能隐式拿到 WRITE_DAC（所有者身份），拿不到 WRITE_OWNER（需要显式 ACE 或 SeTakeOwnershipPrivilege）→ 打开被拒 → Win32 5 → 沙箱初始化整体中止。

这是默认配置命中，不是异常配置：凡把项目放在数据盘/非用户目录的用户都会遇到。

项 | 值 -- | -- DSH 桌面端 | 0.2.0-rc.1（DeepSeek Harness.exe 文件版本 0.2.0-rc.1 / 产品版本 0.2.0.0） 操作系统 | Windows 11 专业版 25H2，Build 26200.9457（10.0.26200） 严重性：高 全灭：一旦命中，该会话的命令执行能力为零，且失败发生在会话启动阶段，与具体命令无关。 不可自我诊断：报错只给「Win32 5」，不提示缺失的权限名，用户凭报错无法定位。 默认配置即触发：数据盘默认 ACL 天然不含普通账户的完全控制。这不是用户把权限改坏了，而是没改过才会命中。 同一台机器上每个工作区根各命中一次：新增的 ACE 只作用于该文件夹本身、不向下继承，因此换一个工作区就要重新修一次。

复现步骤
在数据盘（D / E / …）新建一个目录，例如 D:\repro，不做任何权限修改（保持盘符默认继承）。
以该目录为工作区启动 DSH 会话，文件策略保持默认的受限模式（workspace-write）。
执行任意命令，例如 Get-Date。
预期：命令执行（至少只读命令应当能执行）。 实际：命令直接失败，报错固定为：

代码块

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\repro)

[argszero]

Thank you — this is the tenth report of this signature, and the first one that isolates the shape of the failure instead of its cause. Three things in it are worth separating, because the earlier reports only had the first.

1. The diagnosis is right, and it is the same one the backend documents. grantWrite opens the workspace root with WRITE_DAC | WRITE_OWNER; a mkdir-created directory on a data volume inherits only Authenticated Users: Modify, which gives you the owner-implicit WRITE_DAC and not WRITE_OWNER. packages/sandbox/sandbox-windows-acl/src/acl.ts states the prerequisite in as many words ("granted directories must be caller-owned and grant WRITE_OWNER"), and the merged write is one SetNamedSecurityInfoW call whose failure is what you see:

if (applyResult !== abi.ERROR_SUCCESS) throwWin32(api, 'SetNamedSecurityInfoW', applyResult, `${label}(${path})`)

2. "Everything through the sandbox is dead, including Get-Date" is the part the earlier reports did not isolate. They described it as a per-command failure; your report names the real geometry. The grant is materialized when the sandbox initializes, so the failure is not one refused operation — it is the whole command surface, and a read-only command is not a retry that can succeed. Your "文件能看，命令全废" is the correct split: the filesystem tools never enter this path.

3. "Each workspace root on the same machine fails once" is the fact that changes the remedy's shape. (OI)(CI) carries an ACE into children of the directory that received it and nowhere else; a second root on the same volume is a sibling, not a child. So the correct shape is one grant per workspace root, not one per machine — and the natural reading of "it worked" is "it is fixed", which is exactly the loop your report closes.

The contribution this round: the plugin I maintain for this family, @argszero/cordis-plugin-sandbox-grant-advisor (source), is now 0.8.1, and both of those shape facts are in the advisory it attaches to the failure:

npm install @argszero/cordis-plugin-sandbox-grant-advisor

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

It observes the public tools/post-execute waterfall, recognizes this signature from the failure text (the two ...NamedSecurityInfoW operations only), and attaches one durable user-role advisory per agent — so the model stops retrying and the reader gets the missing right, the ownership-forked remedy, the reason takeown / icacls /reset do not supply it, and now:

• the failure belongs to the workspace, not the command — a command that only reads fails identically, so a different command is not a retry;
• the grant is scoped to the directory it names and its children — a sibling workspace root needs the line once more.

It repairs nothing itself: no ACL is written, nothing is elevated, no mode is changed. Upstream is untouched — this is the stopgap for "the error does not name the outstanding condition", since the error text cannot be changed from a plugin.

[MOOS2046]

OK，那等修复

[lovezi0]

做了个插件可以自动对工作区授权
https://github.com/lovezi0/dsh-workspace-acl-allow

[nickmyb]

同签名 +1（0.2.0-rc.2，Win11 企业版 LTSC 24H2，工作区 D:\DeepSeekHarnessData）。补三条本讨论尚未覆盖的增量，供团队定位：

应用自己的"添加工作区 → 新建文件夹"也会制造这个目录。创建链路是 packages/client/ui-workspace/src/client/navigation.ts:278 → packages/api/workspace-controller/src/directory-picker.ts (@Remote('createDirectory')) → packages/host/directory-picker-browse/src/index.ts:315 的裸 await mkdir(target)（无安全描述符）；默认工作区初始化 packages/workspace/workspace/src/index.ts:267 同样如此。即无需任何外部创建，应用自身在盘根建的工作区就命中。

对照组实验：同一台机器上 Explorer 右键新建的文件夹与应用创建的结果完全相同（都只有盘根继承的组 ACE、无用户显式 ACE）；且 C:\ 与 D:\ 两个盘根（自装系统默认状态）都无 CREATOR OWNER 继承项。所以触发条件是"盘符根目录默认 ACL"，与创建方式无关——这也意味着修 createDirectory 的 mkdir 只能挡一部分，provision 侧的防御才是关键。

官方内置自愈路径实测可用：本机触发后，内置 diagnose-windows-sandbox-acl 技能一次运行即完成诊断与修复（判定 PRECONDITION → 为用户补写 FullControl ACE → 重读验证 WRITE_OWNER=true），随后沙箱 grantWrite 正常落地，全部受限操作恢复。修复无需提权（属主隐含的 WRITE_DAC 足够）。