workspace-write sandbox fails entirely on Windows when the workspace grants no WRITE_OWNER (SetNamedSecurityInfoW error 5)

[gkpsdsg]

Summary

On Windows, after upgrading 0.1.5-rc.3 → 0.1.7-rc.2, every shell command fails before it
runs, and the workflow tool dies with the same error:

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\develop\dsh)
Error: workflow run failed: workflow execution failed (worker-exit):
       SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\develop\dsh)

The workspace is an ordinary directory: owned by the user, whose Modify comes from an
inherited Authenticated Users ACE. Inherited Modify does not include WRITE_OWNER, and
0.1.7's grantWrite now needs it — it writes a Low mandatory label into the object's SACL. One
missing right aborts the whole grant, so the sandbox never comes up and the command never starts.

Giving the workspace WRITE_OWNER fixes it completely, which is why this looks like a
precondition that was added without a fallback rather than a fundamental design problem.

Environment

• Windows 11 (Chinese locale); Windows PowerShell 5.1 (no PowerShell 7 on this machine); Node v24.15.0
• @deepseek-ai/dsh 0.1.7-rc.2 (npm tag next), profile web, file policy workspace-write (default)
• Workspace D:\develop\dsh on an NTFS data volume
• The same workspace and the same user worked normally on 0.1.5-rc.3

Reproduction

1. Start dsh web on Windows with the default workspace-write policy.
2. Ask the agent to run any pwsh command (even pwd).
3. Every call fails immediately with SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>).
4. workflow fails with the worker exiting on the same error.
5. In-process tools are unaffected — read / write / edit / glob / grep, subagent,
   web_fetch / web_search all work. Only the paths that confine a child process break.

What was measured

Workspace DACL (icacls D:\develop\dsh):

D:\develop\dsh S-1-4-60725554-498175233:(OI)(CI)(W,D,DC)   <- capability ACE left by an earlier DSH run
               BUILTIN\Administrators:(I)(F) ...
               NT AUTHORITY\Authenticated Users:(I)(M)     <- where this user's Modify comes from
               BUILTIN\Users:(I)(RX) ...

Note what is missing: there is no Mandatory Label line, i.e. the Low label was never applied,
and no explicit WRITE_OWNER for the user. The inherited Modify ACE carries the (I) flag, so it
comes from a parent (on this machine the data volume's default permissions).

Isolation, same non-elevated token, scratch directory:

Operation	Result
icacls <dir> /setintegritylevel Low	Access is denied, exit 5
icacls <dir> /grant "*S-1-5-11:(W)" (DACL only)	exit 0
icacls <dir> /grant "<user>:(WO)" then /setintegritylevel Low	exit 0, Mandatory Label\Low Mandatory Level:(NW) appears

So the DACL edit is permitted and only the label edit is refused — which is exactly the merge that
grantWrite performs in one SetNamedSecurityInfoW call.

After granting WRITE_OWNER, everything recovers:

1) command runs            OK
2) workspace write/read/delete   ok
3) sandboxed child         integrity = Low Mandatory Level (S-1-16-4096), 1 privilege
4) DSH applied the label   Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
5) workflow smoke test     {"workflowOk": true}
6) background job          completed, exit 0

Root cause

dsh-sandbox-windows-acl, grantWrite() merges three edits into a single
SetNamedSecurityInfoW(path, 1, SecurityInfo, null, null, dacl, label) call where
SecurityInfo = 20 (DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION). The package's own
comment states the precondition (lib/types-DxezulnA.js, above grantWrite):

The directory must be owned by the caller AND grant WRITE_OWNER (the label lives in the
SACL; owner-implicit rights cover only READ_CONTROL and WRITE_DAC) — a Full-control workspace
satisfies both.

"Owned by the caller plus inherited Modify" is not enough, and that combination is common:
a directory created by another tool, or one inheriting the data volume's default ACL, looks
perfectly writable to the user and still fails this precondition.

This is a regression from the 0.1.7 sandbox hardening ("fix Windows sandbox deletions escaping
the authorized directory", 0.1.7-alpha.1): 0.1.5-rc.3 wrote the DACL only. The leftover capability
ACE in the DACL above, with no matching label, is the fossil of a successful old-style grant —
which is why the same machine worked before the upgrade.

Suggested fixes

1. Make the failure actionable. Win32 5 on grantWrite(<path>) gives a user no way to know
   that WRITE_OWNER is the missing right. Naming the right and the path (and that the sandbox
   therefore cannot start) would have saved a long diagnosis.
2. Degrade instead of aborting. If WRITE_OWNER is unavailable, applying the DACL without the
   label still yields a working sandbox, exactly as 0.1.5-rc.3 did. Losing one hardening measure
   is strictly better than losing every command.
3. Or acquire the right first. The owner can always grant itself WRITE_OWNER (WRITE_DAC is
   owner-implicit), so grantWrite could add the missing ACE before applying the label — no admin
   rights needed, as the workaround below shows.
4. Whichever is chosen, the Windows precondition belongs in the docs: an agent workspace must grant
   the user Full control, or at least WRITE_OWNER.

Workaround (applied locally)

icacls <workspace> /grant "<user>:(OI)(CI)(WO)"

No elevation required. After this, the default workspace-write policy works again and DSH applies
its Low label itself. It has to be repeated for every workspace whose Modify is inherited, and
again after an ACL reset (e.g. a fresh clone or a restored directory).

Related

• [Feature request] Let users choose the model when dispatching subagents + [Bug] pwsh sandbox grantWrite failure #1312 titles a "pwsh sandbox grantWrite failure", but its details live in an inaccessible
  .docx attachment and its two comments only cover the subagent-model request. Mentioning it in
  case maintainers know whether it describes this same precondition — if so these could be merged.
• Other Windows ACL sandbox reports: [Bug] Windows 下，工作区连接后新增的子目录无法写入 #401, [Bug Report] Windows 工作区：连接后外部创建/移入的子目录永远无法写入（capability ACE 永不补授） #423, [BUG] workspace-write 调用外部工具可能导致卡死 #469, # Bug + fix: Windows 大工作区首次 workspace-write 授权同步遍历 ACL 整树，事件循环冻结数分钟 #3434, DSH | @topolyte/windows-acl | 非阻塞 Windows ACL 沙箱授权，消除大工作区首次命令冻结 #3430.

Happy to test a patch on this machine (0.1.7-rc.2, PowerShell 5.1, secondary NTFS volume) — the
failure reproduces every time.

[kittimzhe]

Confirmed at source level against master 477b4f420 (the 0.1.7-rc.2 merge).

mergeAndApply (packages/sandbox/sandbox-windows-acl/src/acl.ts:255-262) applies the DACL grant and the Low mandatory label in one SetNamedSecurityInfoW call (DACL | LABEL_SECURITY_INFORMATION), so the whole grant — including the DACL half that ownership would permit — fails atomically with the Win32 5 you saw. Writing a mandatory label via SetNamedSecurityInfo is governed by WRITE_OWNER (not ACCESS_SYSTEM_SECURITY), and owner-implicit rights only cover READ_CONTROL + WRITE_DAC, which matches your inherited-ACE analysis exactly.

Timeline: the label write arrived in d5ad3baeb ("confine Windows deletes with a Low integrity label", 2026-09-19), first shipped in v0.1.7-alpha.1 — matching your 0.1.5-rc.3 → 0.1.7-rc.2 window.

One refinement to the "precondition without a fallback" framing: a no-label fallback is not safe by itself. The runner lowers the sandboxed token to Low integrity (restrictTokenIntegrity, src/token.ts:156-163), and a Low-integrity process cannot write a Medium-labeled directory (no-write-up). Skipping the label on ERROR_ACCESS_DENIED would let grantWrite "succeed" while every actual write inside the sandbox still fails — a clear error traded for a silently broken one. WRITE_OWNER is a real functional requirement of the 0.1.7 design.

What would actually help: split the combined call (DACL first, label second — or preflight the desired access before touching anything), so the failure names the missing right and the remediation (icacls <workspace> /grant "<user>:(WO)"), instead of an opaque Win32 5. I can't run Windows here (macOS, source-level verification only), but the fix is well-scoped in acl.ts.

[argszero]

Your case is the one where the unelevated one-liner works — and the same error also covers the one where it cannot run

kittimzhe's analysis above is right, and it matches what I read at master 477b4f4205: mergeAndApply (sandbox-windows-acl/src/acl.ts:255-262) applies the DACL grant and the Low label in one SetNamedSecurityInfoW, the label write is governed by WRITE_OWNER, and the no-write-up argument rules out a no-label fallback.

Your workspace is the environment where the cheap fix applies: D:\develop\dsh is yours (your Modify comes from an inherited Authenticated Users ACE, and an owner holds WRITE_DAC implicitly — which is what icacls /grant itself needs), so icacls "D:\develop\dsh" /grant "%USERNAME%:(OI)(CI)(WO)" is the whole of what is missing, unelevated.

What now delivers that, in the failing result rather than in a README

@argszero/cordis-plugin-sandbox-grant-advisor (npm / public repo) hooks the public tools/post-execute waterfall, recognizes this signature narrowly (only the two ...NamedSecurityInfoW operations, so a SetEntriesInAclW or LocalFree failure is never given an ACL story), and attaches one user-role advisory to the failing result: your error line quoted verbatim, the missing right named, and the command ready to paste. Verified loading on 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.3, 0.1.6-alpha.2 and 0.1.7-rc.2.

New in 0.5.0 (published today) — the remedy now forks on ownership, because this identical error also covers a directory the caller does not own (#7771: owner BUILTIN\Administrators, held deny-only for that token). There the unelevated line is refused before it does anything — icacls /grant itself needs WRITE_DAC, which that caller holds neither as owner nor through any ACE — and (WO) alone would not be enough even if it went through, since the merged write wants WRITE_DAC and WRITE_OWNER. So the advisory hands over the ownership check as the selector, (Get-Acl "<dir>").Owner, and gives the not-owned branch an elevated icacls "<dir>" /grant "<account>:(OI)(CI)F", or /setowner first (also elevated; it wants SeTakeOwnership), or a workspace under %USERPROFILE%. Until this release it printed one unconditional one-liner with a sentence noting it assumed ownership — which would have sent that second environment to a command that is denied, i.e. the very defect the plugin exists to answer.

The advisory also carries two facts the error cannot: the version boundary (the label half arrives at 0.1.7-alpha.1; up to 0.1.6-alpha.x the flag was DACL-only, so the same string on an older line is a different cause space, and rolling back is not the remedy either), and the two repairs that look right and are not — takeown (ownership supplies the DACL half and never WRITE_OWNER) and icacls /reset (it restores the inheritance that supplied the Modify-only ACE) — each with its reason.

Scope: a stopgap, not a fix. The plugin never edits an ACL and never elevates; the upstream gap — a failure naming neither the missing right nor a remedy, under a precondition that is not pre-flighted — is still open in packages/sandbox/sandbox-windows-acl/src/acl.ts.

• install: npm i @argszero/cordis-plugin-sandbox-grant-advisor

[kittimzhe]

Thanks for confirming — glad the read matched master.

One thought on the advisor: once the upstream split-call fix lands, the error text it matches on will change (a failed label write would name WRITE_OWNER explicitly), so keying the detection on the Win32 error + object type rather than the message string might keep it stable across that boundary.

And if a branch with the split-call version (DACL grant first, label second, each failure naming the missing right) plus tests would save you time, I'm happy to push one — same fork-first pattern as #5588.