[Bug] Windows: after upgrading to 0.1.7-rc.1 every shell command fails at the ACL grant with SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>) / 升级到 0.1.7 后所有 shell 命令在沙箱授权阶段立即失败（粘性，需手工修 ACL）

[zhou2005-calcite]

中文摘要：0.1.5-rc.2 → 0.1.7-rc.1 升级后，所有沙箱命令（含空命令）在启动阶段即失败并报 SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ws)。文件读写工具仍可用，且该故障粘性——不手工修工作区根目录 ACL 就每条命令都失败。已定位到函数级原因（新版权限授予把 DACL 与完整性标签合并成一次调用，写标签需要 WRITE_OWNER，而该目录没有使用者本人的显式 ACE），一条 icacls 可修复。

---

Summary

After upgrading @deepseek-ai/dsh 0.1.5-rc.2 → 0.1.7-rc.1 on Windows, every sandboxed command fails before execution — including an empty one:

代码块

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

Win32 5 is ERROR_ACCESS_DENIED. File read/write tools keep working; only the sandboxed shell is dead, and the failure is sticky: it repeats for every subsequent command until the workspace root's ACL is repaired by hand. Nothing in the upgrade output hints at an ACL prerequisite.

Environment

• @deepseek-ai/dsh 0.1.5-rc.2 → 0.1.7-rc.1 (explicit version, npm i -g)
• Windows 11 (zh-CN), Windows PowerShell 5.1, Node v24.18.0, npm 11.16.0
• Session policy: {"preset":"workspace-write","sandbox":"workspace-write","approval":"ask"}
• Workspace root D:\ws: owned by the invoking user, but its DACL names no explicit ACE for that user — effective access comes from Authenticated Users: Modify plus inherited defaults. Token is a standard UAC-filtered one (BUILTIN\Administrators present as deny-only).

Steps to reproduce

1. On 0.1.5-rc.2, run any sandboxed command in the workspace (works — the older, simpler grant is applied).
2. Upgrade to 0.1.7-rc.1 and restart the host.
3. Run any sandboxed command, e.g. an empty probe.
4. Every later sandboxed command fails identically. Seen on two independent sessions, including one created during the first post-upgrade boot.

Root cause

@deepseek-ai/dsh-sandbox-windows-acl changed substantially between the two versions:

symbol | 0.1.5-rc.2 | 0.1.7-rc.1 -- | -- | -- grantWrite | (api, path, sidPtr) | (api, path, sidPtr, lowLabelSidPtr, worldSidPtr) mergeAndApply | single entry, no label edit | entries + labelEdit, one SetNamedSecurityInfoW(..., DACL\|LABEL = 20, ...) readCurrentSecurity, buildLowLabelAcl, hasExactEntry, hasExactDeny, hasExactLabel | absent | present workspaceWriteSid / tempWriteSid (capability SID derivation) | — | byte-identical to 0.1.5

[argszero]

Your function-level analysis matches the released code, and one detail in it is worth making sharper: the failure is not only sticky by symptom, it is re-derived from scratch on every command.

Confirming the root cause at 0.1.7-rc.1

The table in the report is right. mergeAndApply (packages/sandbox/sandbox-windows-acl/src/acl.ts) applies the merged DACL and the mandatory label in one call — acl.ts:255 passes DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION, and acl.ts:262 throws the line you are seeing:

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

label is grantWrite for the workspace root, which is why detail reads grantWrite(D:\ws). The text itself comes from Win32Error (packages/subprocess/win32-process/src/errors.ts:9) and carries the API, the Win32 code and that detail — nothing else. The label lives in the SACL, and the owner's implicit rights cover only READ_CONTROL and WRITE_DAC, so the label half additionally needs WRITE_OWNER on the directory. That is an object right, not a token privilege: the standard reflex (SeSecurityPrivilege, whoami /priv, elevation) is the wrong lever here, which is exactly why the error is so hard to act on.

Why every command fails, not just the first

materializeAclGrant (packages/sandbox/sandbox-local/src/index.ts:400) memoizes the workspace grant per root — but the entry is written only after the apply succeeded (:403 throws, :415 is the workspaceGrants.set). A failing workspace therefore caches nothing: AclWriteGrant is disposed and the error propagates, so the next confined call re-enters the same grantWrite → same SetNamedSecurityInfoW → same refusal. That is the mechanism behind the "sticky" behaviour you measured, and it is also why one manual repair ends it permanently: once the ACL grants you WRITE_OWNER, the next apply succeeds and every later call short-circuits at the exact-ACE/deny/label check (acl.ts:385).

Your workspace shape is the one that trips it: owned by the invoking user, DACL with no explicit ACE for that user, effective access from Authenticated Users: Modify. A mkdir root inherits Modify (0x1301bf), and that mask carries neither WRITE_DAC nor WRITE_OWNER.

Where the information is lost (the part I would call the real bug)

The prerequisite is documented — packages/sandbox/sandbox-windows-acl/README.md:122 states it verbatim ("Granted directories must be caller-owned and grant WRITE_OWNER"). But nothing in the upgrade output, the policy selection, or the thrown error brings it to the user, and the site that throws already knows the operation it was refused on (a merged DACL+label apply) and knows the directory's current explicit DACL (readCurrentSecurity ran one line earlier, and hasExactGrant/hasExactDeny/hasExactLabel just decided whether to skip). So the condition that makes this a 50-minute detour instead of a one-line fix is that the refusal is reported as a bare Win32 code while the remedy the project already documents never reaches the person who needs it. My suggestion for the upstream shape is narrow: when the merged apply is refused with ERROR_ACCESS_DENIED, say what was refused and name the missing object right — the same sentence the README already carries. That belongs at the grant site, not in a plugin.

Today's mitigation: a plugin

Until that lands, the decision layer is reachable from a plugin, so I built one and published it:

• npm install @argszero/cordis-plugin-sandbox-grant-advisor — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor
• source: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor

It observes the public tools/post-execute waterfall, recognizes this signature (only the two ...NamedSecurityInfoW operations, keeping your Win32 code and the producer's detail verbatim), and attaches one durable user-role advisory per agent through additionalContexts, so the model sees it beside the failure instead of in a log nobody reads. The advisory names WRITE_OWNER on the directory as the missing right, gives the discriminator (icacls <dir> — if the strongest entry naming your own account is (M) / Modify, that is this failure) and the unelevated fix:

icacls "D:\ws" /grant "$env:USERNAME:(OI)(CI)F"

There is an optional, off-by-default enforceAfter that refuses an identical call this plugin has watched fail, bounded by maxDenials per episode of brokenness — the useful half here is the diagnosis, not the blocking. It never edits an ACL and never elevates; the icacls line is yours to run. It also complements repeat-guard-escalation, which keys on call identity: several different commands sharing one cause is precisely what that guard cannot see.

Two boundaries, stated plainly. First, the Windows path itself was not witnessed — I built and tested this on macOS, so what the suite covers is the decision layer (classification against the producer's exact error shape, once-per-agent delivery, the denial budget, and the wiring to the real ToolRuntime), not the ACL syscalls. Second, the plugin treats the symptom: it turns an unexplained refusal into an explained one, it does not make a Modify-only directory grantable. The fix that removes the detour is upstream, and your report is what makes it actionable.

[yangxj0323]

这问题整的我工作区内执行pnpm run build都没权限了，只要有往外部目录写东西的操作都会被拒