[Windows] Low integrity label is written only on the workspace root, so every pre-existing subdirectory stays unwritable to confined processes under workspace-write

[taskeee]

Summary

The Windows ACL sandbox backend writes its Low mandatory integrity label onto the workspace root only, and relies on inheritance to cover the tree. Windows propagates DACL changes to existing child objects, but it does not back-fill a newly added SACL label onto children that already exist.

Consequence: in a workspace that already contained directories and files before the label was written, every pre-existing directory and file stays unwritable to confined processes, while the root itself and anything created afterwards are writable. On the reporter's machine that is ~124,600 directories and ~925,000 files.

This originates from the same change as #8412 (d5ad3baeb5, "fix(sandbox): confine Windows deletes with a Low integrity label", first shipped in dsh-v0.1.7-alpha.1), but it is a different failure mode:

• [Windows] workspace-write 会把工作区打成常驻 Low 完整性标签，用户自己启动的程序被降级、写不进 %TEMP% / %LOCALAPPDATA% #8412: the label is standing and inherited, so every executable inside the workspace runs at Low integrity — including programs the user launches themselves — and they can no longer write %TEMP% / %LOCALAPPDATA%.
• This report: the label is written too narrowly, so the sandbox's own confined children cannot write the workspace's pre-existing content.

Environment

• DSH Desktop (Electron), DeepSeek Harness.exe file version 0.2.0-rc.2, nightly channel
• Windows x64, NTFS volume; DSH_HOME on a non-system volume; profile desktop
• Session policy workspace-write, approval ask
• Workspace root: a pre-existing directory tree, created months before DSH was installed. DSH did not create it.

Symptom

Under workspace-write, a confined child process (pwsh) cannot create or delete files anywhere in a pre-existing subdirectory of the workspace, while reads / listing / stat all work:

Set-Content  <workspace>\<existing-subdir>\x.tmp
  -> UnauthorizedAccessException : access to the path is denied

Remove-Item  <workspace>\<existing-file>
  -> ArgumentException : access to the path is denied

case	result
list / read / stat anywhere in the workspace	OK
write into the workspace root itself	OK
write into a newly created directory under the root	OK (inherits the label)
the fs capability channel (agent write / edit tools)	OK — not a confined child process
session switched to danger-full-access	OK

Root cause

grantWrite() in @deepseek-ai/dsh-sandbox-windows-acl writes three things onto the workspace root:

1. an Allow ACE for the workspace capability SID (S-1-4-<sha256(canonicalPath)-derived>) — DACL
2. an Everyone FILE_DELETE_CHILD Deny — DACL
3. a Low mandatory integrity label (S-1-16-4096, MandatoryPolicy = NO_WRITE_UP) — SACL

grantWrite() is invoked once, on the workspace root, and relies on inheritance to cover the tree. DACL entries are inherited by existing children; the SACL label is not. So:

• root: labelled → writable by a Low-integrity confined process
• every pre-existing child: unlabelled → Windows treats it as Medium → a Low-integrity process is blocked by mandatory no-write-up

Measured:

<workspace-root>              Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
<workspace-root>\sub-a        (no label)
<workspace-root>\sub-b        (no label)
top-level directories:  with-label = 0   without-label = 22
whole tree:             124,631 directories / 925,168 files — none labelled
object created under the root afterwards:  inherits the Low label -> writable

The confined child is created with its token lowered to Low integrity (restrictTokenIntegrity(); CreateRestrictedToken flags = 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED).

Decisive experiment

Using a self-built token that reproduces DSH's exact combination:

token	write into root	write into pre-existing subdir
Low integrity + WRITE_RESTRICTED	OK	DENIED
Low integrity only (no write restriction)	OK	DENIED

The only variable that differs between the two targets is the integrity label ⇒ the label, not the DACL, is what blocks the write.

This is a regression relative to 0.1.5 (consistent with the upstream history in #8412)

A 0.1.5 runtime is still present on the reporter's machine:

• ...\app-0.1.5-rc.1\node_modules\@deepseek-ai\dsh-sandbox-windows-acl, version 0.1.5-rc.1 (3 files)
• grep for S-1-16-4096|buildLowLabel|lowLabel|LowLabel|LABEL_SECURITY_INFORMATION → zero matches

0.1.5-rc.1 predates dsh-v0.1.7-alpha.1, the first release containing d5ad3baeb5 — matching the upstream history quoted in #8412. The older sandbox only wrote DACL entries (which are inherited), so pre-existing workspaces kept working.

Any user who points DSH at an existing directory tree hits this immediately after upgrading. A fresh install never reproduces it, because a workspace created by DSH has all of its subdirectories created after provisioning, so they inherit the label. This is probably why it is hard to see in testing.

The bundled diagnostic skill cannot repair this

diagnose-windows-sandbox-acl performs SetDacl only (repairs WRITE_DAC / WRITE_OWNER, removes AppContainer package ACEs). $LOW_LABEL_SID is used for detection/reporting only — the script never writes a SACL / label. Running it against a failing subdirectory reports verification: verified and changes nothing. (This matches the "cannot be fixed by the shipped skill" conclusion in #8412.)

Separately, running it on the workspace root did fix a real, distinct problem: the root lacked explicit WRITE_OWNER, which made every confined pwsh invocation fail with SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace-root>). That part is resolved; this label-coverage problem is not.

Suggested fix

1. At provision time, apply the Low label recursively — at minimum to the directory layer — of an existing workspace instead of relying on inheritance; or
2. Detect "workspace root already exists and is not fully labelled" and surface a clear, user-visible consent / error path instead of silently leaving a half-provisioned workspace; and
3. Extend diagnose-windows-sandbox-acl to detect and repair missing integrity labels (it currently only reports them).

If #8412 leads to the standing label being narrowed or dropped, please make sure this coverage gap is handled in the same design pass — otherwise "workspace-write works on a fresh workspace but silently fails on an existing one" will remain.

Impact

Any user whose workspace is a pre-existing directory tree loses the ability to run any shell command that writes files (downloads, builds, code generation, npm install) in the default workspace-write mode. All workarounds are user-side: switch to danger-full-access, work inside a newly created directory, or use the fs capability channel instead of a shell.

[argszero]

This is the label half of the same shape, measured on its own — and your experiment is the decisive form of it, which is why it is worth separating from the sibling report rather than folding into it.

Why your reading is the right one. Your distinction is exactly the one that matters: Windows propagates DACL changes into existing children, and does not back-fill a newly added SACL label onto children that already exist. That is why the root is writable, a directory created afterwards is writable, and every pre-existing child is denied — and it is the same conclusion a sibling report reached on a 0.2.0-rc.2 install with the complementary control (a directory created after the grant inherits the capability ACE marked (I) and still receives no label; a grandchild proves nothing, because inheritance is per-parent and the intermediate directory carries none).

Why it is permanent, from the source. The label goes out in the same single SetNamedSecurityInfoW as the grant, with the inheritance flag set, but only on the paths the backend enumerates — the workspace root plus the session's private temp directory, with no descendant walk. The root-only idempotency check then requires the grant, the world delete-child deny and the exact label before it returns early (hasExactGrant() + hasExactDeny() + hasExactLabel() all matching, sandbox-windows-acl/src/acl.ts:386-388, label read at :198-204), so once the root is labelled the propagation is never attempted again. Your "0 of 22 top-level directories labelled / 124,631 directories, 925,168 files" is the size of the gap.

Your token experiment is the strongest evidence in the thread. Low-integrity only and Low + WRITE_RESTRICTED both wrote the root and both were denied in a pre-existing subdirectory: the only variable left is the object's own label, so the kernel's no-write-up check is running in addition to the access check and not instead of it. That is the sentence a reader needs before reaching for a DACL repair that cannot work.

On the bundled skill. Your finding matches the report in the sibling thread: diagnose-windows-sandbox-acl calls SetNamedSecurityInfoW with DACL_SECURITY_INFORMATION only (sacl = IntPtr.Zero), so LOW_LABEL is used for detection and never written — it can report and cannot repair. The separate problem it did fix for you (the root lacking an explicit WRITE_OWNER, which made every confined invocation fail with SetNamedSecurityInfoW failed (Win32 5)) is a different family: that one is the provisioning failure, and its remedy is a one-liner the user can run while the session continues, which is why it is the only family where a plugin's optional blocking half exists at all.

Shipped form. @argszero/cordis-plugin-sandbox-grant-advisor — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor — reads the executors' own stamp on the result (sandbox: { mode: "workspace-write", denied: true }, i.e. the harness's own reading of its own sandbox rather than a guess from rendered text) and attaches one durable user-role advisory per agent through additionalContexts. Since 0.14.0 it forks the diagnosis on breadth into three cells — a handful of stubborn objects (DACL half), nothing below the root writable with the root itself writable (your label half), and the root itself refused (a third shape added this week) — names each cell's own test, states that the first two are permanent for the same root-only short-circuit, and ships no repair command, because this project has no Windows host to verify one on. Mount it with:

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

On your suggested fixes: (1) recursive label application at provision time is the direct answer to this cell, and (2) the "existing, partially labelled workspace" detection is what turns a silent half-provisioned tree into a decision the user can make — both are core changes, and the plugin is the stopgap that tells the model what it is looking at in the meantime.