[Bug] 工作区不可写问题可能原因：低完整性标签没有铺到已存在的子目录：同一个机制导致的三种故障 / workspace-write writes fail in every pre-existing subdirectory: the Low-integrity label is never applied to objects that already existed — one mechanism behind three failure modes

[MaccharitY]

Summary

On Windows in workspace-write mode, the sandbox can write to the workspace root but not to any subdirectory that already existed when the sandbox provisioned it. Every write fails with Access to the path '<dir>\_wtest' is denied.

This breaks ordinary work, not just an edge case: py_compile / mypy (which write __pycache__), git, node, and any build tool that writes inside a project directory all fail. Reproduced with a workspace whose project lives in subdirectories (D:\projects, 8 first-level subdirectories — all denied).

The mechanism behind it is a persistent, inheritable Mandatory Label\Low Mandatory Level on the workspace root plus a Low-integrity sandbox token. Two other reports document the same mechanism failing in different directions (#9314: executables built in the workspace inherit Low IL and break outside the sandbox; #9407: the label breaks Explorer icons and persists after the session). A section below analyses all three together, because they share one root cause and cannot all be fixed by adjusting how the label is applied.

Provenance and reliability (please read before acting on this)

• The technical analysis below was produced by DSH's own agent self-diagnosis inside a live session: the agent read the installed package source in its own dependency tree (node_modules/@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2) and ran measurements in its sandboxed shell.
• It is an agent's reading of code, not a maintainer statement. I can vouch for what was measured on this host and for the quoted source comments; I cannot vouch for the design intent, nor for behaviour on configurations other than mine.
• Single machine, single version, single OS build. All first-hand measurements come from one Windows 10 Pro (10.0.26200) host, @deepseek-ai/dsh@0.2.0-rc.2, workspace D:\projects. No other version, locale, filesystem or Windows release was tested.
• Version attribution is uncertain. I compared two packages locally (dsh-sandbox-windows-acl 0.1.5-rc.2 vs 0.2.0-rc.2); [Windows] Sandbox labels the whole workspace tree as Low integrity -> Explorer renders every icon in the workspace as a generic blank page #9407 reports the label being applied with runtime 0.1.5-rc.2, which my package comparison does not explain. Treat the version-history section as "needs confirmation from the maintainers", not as fact.
• Source filenames are content-hashed (lib/types-<hash>.js) and shift between builds; the function names quoted below are the stable anchors and should be re-verified against the tag being investigated.
• [BUG] Workspace-write provisioning leaves a persistent Low integrity label on the workspace root — executables built in the workspace run at Low IL and fail all writes outside the sandbox #9314's exe-integrity leakage was not reproduced by me (no compiled binary in my workspace at the time). It is another user's report with their own icacls evidence; I only note it is consistent with how Windows derives a process's integrity level from its image file.
• In short: treat the mechanism as reproducible on my host, and the design recommendation as an argued position — not as a verified upstream defect list.

Reproduction

1. Windows, DSH 0.2.0-rc.2, workspace D:\projects, file policy workspace-write.
2. Have a subdirectory that already exists, then let the sandbox write into it:

   New-Item -ItemType Directory -Path 'D:\projects\python\_wtest'
   # or: Set-Content -LiteralPath 'D:\projects\python\_wtest.txt' -Value x

3. Result: Access to the path 'D:\projects\python\_wtest' is denied.

Probe over every first-level subdirectory (stop descending once one fails):

OK    (root)          <- D:\projects itself is writable
FAIL  \.mypy_cache    Access to the path 'D:\projects\.mypy_cache\_wtest' is denied.
FAIL  \AI_api
FAIL  \c
FAIL  \c++
FAIL  \java
FAIL  \python
FAIL  \templates
FAIL  \tools

Ruled out (all verified):

• Not a permission gap: the current user owns those directories and has effective FullControl (WRITE_DAC and WRITE_OWNER both true). Granting explicit Full Control changes nothing.
• Not a foreign package ACE: diagnose-windows-sandbox-acl scanned 1085 objects in the subtree; PACKAGE_SOURCES=0.
• Not the Everyone … (DENY)(DC) entry: documented as expected behaviour.
• Not profile-specific: switching DSH profiles and escalating to full access make no difference.

Current behavior

Target	Result
workspace root D:\projects	writable ✅
any pre-existing subdirectory	Access to the path ... is denied ❌
a subdirectory created after provisioning, and its children	writable ✅

Downstream failures, same session: python -m py_compile → exit 1 with [Errno 13] Permission denied: '__pycache__\\game_stats.cpython-311.pyc'; mypy fails the same way; git reports access denied; node tools\align-tables.js <file under a subdirectory> → EPERM: operation not permitted.

Expected behavior

In workspace-write, the whole workspace subtree should be writable. A directory must not be excluded merely because it existed before the sandbox provisioned the workspace.

Root cause (read from source + measured)

dsh-sandbox-windows-acl does two things:

1. Applies a Low mandatory integrity label to the workspace root — grantWrite() → buildLowLabelAcl(), with (OI)(CI) inheritance.
2. Lowers the sandboxed child token's integrity level to Low — restrictTokenIntegrity() → SetTokenInformation(token, TokenIntegrityLevel = 25, S-1-16-4096).
3. Only one writable directory is configured: writableDirs: parsed.mode === "workspace-write" ? [parsed.workspace] : [] (lib/runner.js).

Under Windows Mandatory Integrity Control, a Low-integrity process can only write to objects whose label is Low. Two facts then collide:

• Windows does not retroactively apply inherited mandatory labels (SACL) to objects that already exist. Applying the label to the root with (OI)(CI) affects only objects created afterwards.
• grantWrite()'s idempotence short-circuit inspects only the object being granted: hasExactLabel(oldAcl, lowLabelSidPtr). Its own source comment states: "so a re-grant can skip the eager full-tree propagation." Once the root carries the label, every later provision returns early, so pre-existing children are never labeled.

Measured with the bundled diagnostic skill on the same tree (it reports LOW_LABEL per object):

OBJECT=D:\projects        MY_RIGHTS=[FullControl] WRITE_DAC=True WRITE_OWNER=True LOW_LABEL=True
OBJECT=D:\projects\tools  MY_RIGHTS=[FullControl] WRITE_DAC=True WRITE_OWNER=True LOW_LABEL=
OBJECT=D:\                 ...                                        LOW_LABEL=

So: root = Low (writable by a Low token), pre-existing children = Medium (not writable). A newly created directory and its descendants inherit Low and are writable, which matches the asymmetry above.

Same mechanism, three failure modes (cross-report analysis)

Report	Symptom as reported	Which property of the primitive causes it
#9314	An exe built inside the workspace runs at Low IL outside the sandbox and fails every write to %TEMP% / %LOCALAPPDATA%; rebuilding does not help; only a copy out of the workspace does	The label is a property of the file, and Windows derives a process's IL from its image file → the label escapes the sandbox
#9407	Every icon in the workspace renders as a blank page; survives the session; only restoring the level fixes it	The label is persistent (no lifecycle end) and visible to the shell
this report	Writes succeed in the root but fail in every pre-existing subdirectory; directories created after provisioning are writable	The label is not retroactive, while the grant short-circuit only inspects the object it is granting

#9407's statement that "the whole tree inherits the label" and my measurement that pre-existing children carry no label are not in conflict: both are explained by when an object was created relative to labelling. Objects created after labelling inherit Low (→ #9407, #9314); objects that existed before do not (→ the write denial above). One rule, two opposite outcomes, deterministic.

Under the DACL-only approach used by the 0.1.5-line package, none of these three would occur: a capability-SID allow entry grants writes without touching an attribute that outlives the session or follows files around.

Why this primitive is a poor fit for session-scoped write control (argued, not verified upstream)

	DACL / capability SID (apparently what 0.1.5-line used)	Mandatory integrity label (added by 0.2.x)
Semantics	"who may access this object"	"how trustworthy is this object/process"
Lifecycle	add/remove precisely, per object	persistent; lives in the file's SACL
Propagation	explicit ((OI)(CI)), repairable	inherited onto every new object, including build output
Effect outside the sandbox	none	determines the IL of processes launched from labelled images
Granularity	per object	all-or-nothing per object
Revocable at session end?	yes	removing it re-breaks exactly the objects that only became writable because of it

The last row is the core problem: the label is load-bearing for the write grant, so there is no coherent release step. Revoke it → everything created during the session becomes unwritable again; keep it → the user's files stay Low indefinitely (#9407, #9314). A session-scoped capability should not be implemented with an attribute that must outlive the session to keep working.

A second-order consequence: because the token is lowered, every write the toolchain performs must land on a Low object, so the sandbox cannot simply declare "this tree is writable" — it must keep the label aligned with everything the tools create, which is precisely where the retroactivity gap and the exe leakage come from.

Suggested direction

1. Short term (mitigation, keeps the design): make the label cover the whole current tree at provisioning (or apply it lazily to the write target), so the write denials stop; and provide a first-class unprovision/reclaim command that removes the label and the standing ACEs (per [BUG] Workspace-write provisioning leaves a persistent Low integrity label on the workspace root — executables built in the workspace run at Low IL and fail all writes outside the sandbox #9314, manual cleanup fails with ERROR_NONE_MAPPED unless the *SID form is used).
2. Structural: express session-scoped write authorization with the DACL capability grant alone, keeping integrity levels out of the write path (as the 0.1.5-line package appears to do); if Low-integrity isolation is wanted, confine it to a dedicated subtree (e.g. <workspace>\.dsh_sandbox\) that user content and build outputs never enter, and tie the label to that subtree's lifecycle.
3. If the label stays: exclude build-output directories from inheritance, warn when the chosen workspace is a shell-visible folder (Desktop / Documents / Downloads), and surface the state in the diagnostic — today the only user-visible signal is Access to the path … is denied, which reads as an ordinary permission problem (I spent a long time granting Full Control and repairing ACLs before finding the integrity label).

User-side workaround (one-off)

:: back up current state first (optional)
icacls D:\projects /save "%USERPROFILE%\Desktop\projects-integrity-backup.txt" /T

:: apply the same label the sandbox uses, to the whole existing subtree
icacls D:\projects /setintegritylevel (OI)(CI)L /T

:: rollback
icacls D:\projects /setintegritylevel (OI)(CI)M /T

After this, newly created directories inherit Low automatically, so it is a one-time fix. Measured after applying it: the same probe over 200 directories of the workspace returned OK for all of them; py_compile exit 0; mypy reports Success; node can write files under a subdirectory; git runs.

Notes on version history (please confirm from your side)

@deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.2 contains no integrity-level code at all (no LowLabel, integrity, or S-1-16 matches in its lib/*.js; writes appear to be authorized by the capability SID's inheritable DACL grant alone), whereas 0.2.0-rc.2 introduces the label plus the token lowering. However, #9407 reports the label already being applied with runtime 0.1.5-rc.2, so the exact version that introduced this behaviour should be confirmed upstream — I can only testify to the two package versions I compared locally.

Environment

Item	Value
OS	Windows 10 Pro, 10.0.26200 (Chinese locale), NTFS
DSH	@deepseek-ai/dsh@0.2.0-rc.2 (all sibling packages same version)
Relevant package	@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2
Comparison package	@deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.2
File policy	workspace-write
Workspace	D:\projects (owned by the signed-in user)
Related reports	#9314 (exe IL leakage), #9407 (Explorer icons)

Appendix: a separate, easily misdiagnosed symptom (not this bug)

Inside the sandboxed shell, invoking a program through a pipe / redirection (e.g. PowerShell & exe ... 2>&1 | Out-String, or | Select-Object) makes process creation itself fail with 程序'x'运行失败：拒绝访问 ("failed to run program … access denied"). This looks like "the sandbox blocks this executable", but the same executable runs fine without the pipe — it is a stdio-boundary restriction, unrelated to the integrity-label issue above. Recording it here so others do not chase the wrong cause.

---

中文

摘要

Windows 上以 workspace-write 模式运行时,沙箱能写工作区根目录,却写不进任何一个"在沙箱配置之前就已经存在"的子目录,每次写入都报 Access to the path '<dir>\_wtest' is denied。

这不是边角情况,而是普通干活就废:py_compile / mypy(要写 __pycache__)、git、node、以及任何往项目目录里落文件的构建工具全部失败。复现环境的工作区里,项目都放在子目录下(D:\projects,8 个一级子目录全部被拒)。

背后的机制是:DSH 给工作区根打了一个持久、可继承的 Mandatory Label\Low Mandatory Level(低完整性强制标签),同时把沙箱子进程令牌降到 Low 完整性。另有两份报告记录了同一机制在另外两个方向上的故障(#9314:工作区里构建出的 exe 继承 Low 完整性,在沙箱之外运行时写不了 %TEMP%; #9407:该标签让 Explorer 图标全变白纸,且会话结束后仍然存在)。下面有一节把三者放在一起分析,因为我认为它们同一个根因,而且不可能靠"调整打标签的方式"全部解决。

内容来源与可靠性声明(请先读这一段再据此行动)

• 下面的技术分析由 DSH 的 agent 在会话内自检得出:agent 读取了它自己依赖树里的包源码(node_modules/@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2),并在沙箱 shell 里做了实测。
• 这是 agent 读代码得出的结论,不是维护者的说法。 本机实测结果和所引用的源码注释我可以保证;设计意图、以及我这台机器之外的配置行为,我无法保证。
• 单机、单版本、单一系统构建。 所有第一手测量来自一台 Windows 10 Pro(10.0.26200)、@deepseek-ai/dsh@0.2.0-rc.2、工作区 D:\projects。未在其他版本、语言环境、文件系统或 Windows 发行版上测试。
• 版本归属不确定。 我本地只对比了两个包(dsh-sandbox-windows-acl 的 0.1.5-rc.2 与 0.2.0-rc.2);而 [Windows] Sandbox labels the whole workspace tree as Low integrity -> Explorer renders every icon in the workspace as a generic blank page #9407 报告在 runtime 0.1.5-rc.2 下就已经出现该标签,这一点我的包对比解释不了。版本史那一节请当作"需要维护者确认",不是事实。
• 源码文件名带内容哈希(lib/types-<hash>.js),不同构建会变;下面引用的函数名才是稳定锚点,核对时请以目标 tag 为准。
• [BUG] Workspace-write provisioning leaves a persistent Low integrity label on the workspace root — executables built in the workspace run at Low IL and fail all writes outside the sandbox #9314 的"exe 继承低完整性"我没有独立复现(当时工作区里没有编译产物)。那是另一位用户附了自己 icacls 证据的报告;我只指出它与"Windows 按镜像文件的标签决定进程完整性"这一行为一致。
• 一句话:机制部分在我这台机器上可复现,设计建议部分是我的论证立场,不是一份已验证的上游缺陷清单。

复现步骤

1. Windows、DSH 0.2.0-rc.2、工作区 D:\projects、文件策略 workspace-write;

2. 找一个已经存在的子目录,让沙箱往里写:

   New-Item -ItemType Directory -Path 'D:\projects\python\_wtest'
   # 或者:Set-Content -LiteralPath 'D:\projects\python\_wtest.txt' -Value x

3. 结果:Access to the path 'D:\projects\python\_wtest' is denied.

对每个一级子目录做同一探测(失败即不再下探):

OK    (root)          <- D:\projects 自己可写
FAIL  \.mypy_cache    Access to the path 'D:\projects\.mypy_cache\_wtest' is denied.
FAIL  \AI_api
FAIL  \c
FAIL  \c++
FAIL  \java
FAIL  \python
FAIL  \templates
FAIL  \tools

已排除的原因(均经验证):

• 不是权限不够:当前用户是这些目录的所有者,有效权限为 FullControl(WRITE_DAC、WRITE_OWNER 均为真);显式授予"完全控制"没有任何改变;
• 不是外来软件包权限项:diagnose-windows-sandbox-acl 扫描子树 1085 个对象,PACKAGE_SOURCES=0;
• 不是那条 Everyone … (DENY)(DC):文档说明它是预期行为;
• 不是 profile 相关:换 DSH profile、提权到完全访问都无差别。

实际行为

目标	结果
工作区根 D:\projects	可写 ✅
任何已存在的子目录	Access to the path ... is denied ❌
配置之后新建的子目录及其子目录	可写 ✅

同一次会话里的连带失败:python -m py_compile → 退出码 1,[Errno 13] Permission denied: '__pycache__\\game_stats.cpython-311.pyc';mypy 同样失败;git 报拒绝访问;node tools\align-tables.js <子目录下的文件> → EPERM: operation not permitted。

期望行为

workspace-write 模式下,工作区整棵子树都应可写;不能仅仅因为某个目录"在沙箱配置工作区之前就存在"就把它排除在外。

根因(读源码 + 实测)

dsh-sandbox-windows-acl 做两件事:

1. 给工作区根加低完整性强制标签 —— grantWrite() → buildLowLabelAcl(),带 (OI)(CI) 继承;
2. 把沙箱子进程令牌降到 Low —— restrictTokenIntegrity() → SetTokenInformation(token, TokenIntegrityLevel = 25, S-1-16-4096);
3. 可写目录只配置了一个:writableDirs: parsed.mode === "workspace-write" ? [parsed.workspace] : [](lib/runner.js)。

按 Windows 强制完整性控制(MIC),低完整性进程只能写"标签为低完整性"的对象。于是两个事实相撞:

• Windows 不会把继承来的强制标签(SACL)追溯应用到已存在的对象。用 (OI)(CI) 给根打标签,只影响之后新建的对象;
• grantWrite() 的幂等短路只检查当前正在授权的那个对象:hasExactLabel(oldAcl, lowLabelSidPtr)。它自己的源码注释写着:"so a re-grant can skip the eager full-tree propagation." 根一旦带上标签,后续每次配置都会提前返回,所以已存在的子目录永远不会被补标。

用内置诊断技能在同一棵树上实测(它逐对象报告 LOW_LABEL):

OBJECT=D:\projects        MY_RIGHTS=[FullControl] WRITE_DAC=True WRITE_OWNER=True LOW_LABEL=True
OBJECT=D:\projects\tools  MY_RIGHTS=[FullControl] WRITE_DAC=True WRITE_OWNER=True LOW_LABEL=
OBJECT=D:\                 ...                                        LOW_LABEL=

即:根 = 低完整性(低完整性令牌可写),已存在的子目录 = 中完整性(不可写)。而新建的目录及其子目录会继承低完整性、因此可写——这与上面的不对称完全吻合。

同一机制,三种故障(跨报告分析)

报告	报告者描述的症状	是该原语的哪个性质造成的
#9314	在工作区内构建的 exe 在沙箱之外以 Low 完整性运行,写 %TEMP% / %LOCALAPPDATA% 全部失败;重建无效,只有把项目复制出工作区才行	标签是文件自身的属性,而 Windows 按镜像文件决定进程完整性 → 标签逃出沙箱
#9407	工作区内所有图标渲染成白纸;会话结束仍在;只有把完整性改回去才恢复	标签持久(没有生命周期终点),且对 shell 可见
本报告	根可写、但每一个已存在的子目录都写不进;配置之后新建的目录可写	标签不追溯,而授权的幂等短路只检查被授权对象本身

#9407 说"整棵树都继承了标签",与"已存在的子目录没有标签"并不矛盾:两者都能用**"对象是在打标签之前还是之后创建的"**解释——之后创建的继承低完整性(→ #9407、#9314),之前已存在的不会(→ 本报告的写入被拒)。同一条规则,两种相反结果,而且是确定性的。

如果采用 0.1.5 那条线的纯 DACL 方案,这三种故障都不会出现:能力 SID 的允许项就能授权写入,不必动一个"会活得比会话更久、还会跟着文件走"的属性。

为什么这个原语不适合做"会话级写入控制"(论证,非上游确认)

	DACL / 能力 SID(0.1.5 线似乎用的就是这个)	完整性强制标签(0.2.x 新增)
语义	"谁可以访问这个对象"	"这个对象/进程有多可信"
生命周期	可按对象精确增删	持久;存在文件的 SACL 里
传播	显式((OI)(CI)),可修	继承到每个新对象,包括构建产物
沙箱之外的影响	无	决定由该镜像启动的进程的完整性级别
粒度	按对象	按对象、全有或全无
会话结束能撤销吗	能	一撤销,那些"唯一因为标签才可写"的对象立刻又写不了

最后一行是核心问题:标签是这次写入授权的承重结构,于是根本不存在一个干净的"释放"步骤——撤销它 → 本次会话创建的东西又不可写;留着它 → 用户的文件永久停在低完整性(#9407、#9314)。一个会话级的授权,不该用一个"必须活得比会话久才能继续生效"的属性来实现。

二阶后果:因为令牌被降级,工具链的每一次写入都必须落在低完整性对象上,所以沙箱无法简单地声明"这棵树可写"——它必须让标签跟着工具创建的一切保持同步,而"不追溯"和"exe 继承"两个问题恰恰出在这里。

建议方向

1. 短期(缓解,保留现有设计):在配置时让标签覆盖当前整棵子树(或按需给写入目标补标签),先把写入被拒解决掉;同时提供一个正规的 unprovision / 回收命令来移除标签和常驻权限项(据 [BUG] Workspace-write provisioning leaves a persistent Low integrity label on the workspace root — executables built in the workspace run at Low IL and fail all writes outside the sandbox #9314,手工清理会遇到 ERROR_NONE_MAPPED,必须用 *SID 形式)。
2. 结构性:会话级写入授权只用 DACL 能力项表达,把完整性级别移出写入路径(就像 0.1.5 线那个包一样);若确实需要低完整性隔离,就把它限制在一个专用子树(例如 <workspace>\.dsh_sandbox\)里,让用户内容与构建产物永不进入该范围,并把标签的生命周期绑定在这个子树上。
3. 若保留标签:把构建输出目录排除在继承之外;当所选工作区是 shell 里可见的目录(桌面 / 文档 / 下载)时给出警告;并在诊断里暴露该状态——现在唯一的用户可见信号是 Access to the path … is denied,看起来就像普通的权限问题(我为此花了很久去授"完全控制"、修 ACL,才找到完整性标签这一层)。

用户侧变通办法(一次性)

:: 可选:先备份当前状态
icacls D:\projects /save "%USERPROFILE%\Desktop\projects-integrity-backup.txt" /T

:: 把沙箱用的同一种标签,铺到整棵已存在的子树
icacls D:\projects /setintegritylevel (OI)(CI)L /T

:: 回滚
icacls D:\projects /setintegritylevel (OI)(CI)M /T

之后新建目录会自动继承低完整性,所以这是一次性修复。实测结果:对工作区 200 个目录重跑同一探测全部 OK;py_compile 退出码 0;mypy 判 Success;node 能写子目录下的文件;git 可运行。

版本史说明(请上游确认)

@deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.2 里完全没有完整性级别相关代码(其 lib/*.js 中 LowLabel、integrity、S-1-16 均无命中;写入似乎仅靠能力 SID 的可继承 DACL 允许项),而 0.2.0-rc.2 新增了标签 + 降令牌。但 #9407 报告在 runtime 0.1.5-rc.2 下就已经出现该标签,所以具体是哪个版本引入的,应由上游确认——我只能对本地对比过的这两个包作证。

环境

项	值
操作系统	Windows 10 Pro,10.0.26200(中文环境),NTFS
DSH	@deepseek-ai/dsh@0.2.0-rc.2(同级包版本一致)
相关包	@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2
对比包	@deepseek-ai/dsh-sandbox-windows-acl@0.1.5-rc.2
文件策略	workspace-write
工作区	D:\projects(所有者为当前登录用户)
相关报告	#9314(exe 完整性外溢)、#9407(Explorer 图标)

附录:另一个容易被误诊的现象(与本 bug 无关)

在沙箱 shell 里,如果通过管道 / 重定向调用程序(例如 PowerShell 的 & exe ... 2>&1 | Out-String,或 | Select-Object),进程创建本身就会失败,报 程序'x'运行失败：拒绝访问。看起来像"沙箱拦了这个可执行文件",但同一个 exe 不带管道直接跑就正常——这是 stdio 边界限制,与上面讨论的完整性标签无关。记录在此,免得别人查错方向。

---

[argszero]

Confirmed from source at origin/master (d743267388). Your reading of the mechanism is exact, and the three facts that make it deterministic are worth quoting with file and line, because they turn a "permission problem" that looks flaky into a predictable asymmetry:

1. One writable root, no children enumerated. packages/sandbox/sandbox-windows-acl/src/runner.ts:163:

   writableDirs: parsed.mode === 'workspace-write' ? [parsed.workspace] : [],

   grantWrite is therefore called on the workspace root and on nothing else.

2. The idempotence short-circuit is object-local. src/acl.ts:388:

   if (oldAcl !== null && labelAcl !== null
     && hasExactGrant(oldAcl, sidPtr) && hasExactDeny(oldAcl, worldSidPtr)
     && hasExactLabel(labelAcl, lowLabelSidPtr)) {
     // The exact ACE, deny, and label stand: releasing the descriptor is the whole operation.
     ...
     return
   }

   readCurrentSecurity(api, path) reads only path, so the first provision that leaves the root fully labelled makes every later provision return before any propagation happens. There is no second pass that would notice an unlabelled child.

3. Inheritance is forward-only, and the token is lowered to match. buildLowLabelAcl (src/acl.ts:169, applied at :398) carries (OI)(CI), which Windows applies to objects created after the label is set; and restrictTokenIntegrity (src/index.ts:290, defined at src/token.ts:156) sets TokenIntegrityLevel to S-1-16-4096. A Low token can write only objects labelled Low, so "root writable / pre-existing child denied / newly created child writable" is not an accident of your tree — it is the only outcome these three facts admit.

Two notes on the suggested direction, from the same code:

• "Label the whole tree at provisioning" and "keep provisioning cheap" are in direct tension, and the code comment is explicit that the second won: the short-circuit exists because applying the descriptor across the whole tree costs minutes on a large workspace (// ... would otherwise re-propagate the identical descriptor across the whole tree (eager inheritance; minutes on large workspaces)). A middle path keeps both: label the write target lazily (or the container chain down to it) at the moment a write is admitted. The mandatory-integrity check is evaluated against the object being opened, not against its ancestors, so labelling the target itself is sufficient and costs one SetNamedSecurityInfoW per touched object instead of a tree walk per provision. That also leaves the pre-existing-subtree case fixed for exactly the directories a session actually uses.
• Your LOW_LABEL probe is the discriminator that separates this from the DACL side of the same symptom. A workspace-internal write can be denied for two different reasons — a DACL that names no capability ACE for the caller, or a Medium label versus a Low token — and the fix commands differ (one is icacls /grant, the other /setintegritylevel). Reporting which one it is (as the bundled diagnose-windows-sandbox-acl skill does with LOW_LABEL) is the part a user cannot do from Access to the path ... is denied, which reads as an ordinary permission problem — exactly as you describe.

The cross-report framing (one primitive, three failure modes: not retroactive → this denial; inherited onto new objects → #9314's image-derived integrity level; persistent and shell-visible → #9407's icons) is the most useful part of the report: it says a fix has to be argued for the primitive's lifecycle, not patched per symptom.

For reference, the npm package @argszero/cordis-plugin-sandbox-grant-advisor exists for exactly this class of failure: it recognizes several Windows sandbox failure shapes that the pipeline reports as ordinary finished commands (non-zero exits are reported, not errored) and hands over the check to run rather than a guess, including a family for a write denied inside the workspace. Which producer caused that denial — capability-ACE inheritance or the integrity label — is the classification your probe makes possible, and it is what a report like this gives a reason to sharpen. No action needed from you; the mechanism above is the contribution.

[MaccharitY]

Thanks for the reply and the line-by-line analysis — much appreciated and very helpful.