[Bug][Windows] workspace-write leaves a permanent Low integrity label on the project, breaking every other tool used on it — several reports, still unchanged in 0.2.0-rc.2

[See-Sol-Lab]

Once DSH has written to a folder in workspace-write mode, three edits stay on its root forever: the capability ACE, Everyone:(CI)(DENY)(DC), and Mandatory Label\Low Mandatory Level:(OI)(CI)(NW). They survive the session and DSH exiting. The README describes this as intentional: the grant is a reuse cache and is never revoked.

Why this is serious

Most of us don't use only one tool on a project. DSH edits it, then Codex, Claude Code, an IDE or a plain terminal works on the same folder. The label is inherited by every file in the tree. So after one DSH session, whichever tool starts something from that project gets a Low-integrity process or a refusal, and nothing points at DSH as the cause:

• [Bug] Windows: the workspace Low integrity label also lowers the user's own launches from that tree, silently degrading the toolchain inside it #7709: Electron/Chromium apps in the project exit with 0x80000003 at startup, with no output and no log.
• Issue with DSH 0.2.0 rc1 creating things in internet zone? #8175: build tools (msbuild, dotnet, npm) refuse or warn about the files, which looks like a Mark-of-the-Web / Internet-zone problem even though no Zone.Identifier exists.
• [Bug] Windows：沙箱给工作区根目录盖 Low 完整性标签后，目录内的 .bat/.cmd/.exe 双击弹「无法验证发布者」 #7735: double-clicking .bat / .cmd / .exe in the project shows "publisher could not be verified" every time.
• [Bug][Desktop][Windows] workspace-write can poison the DSH Desktop install directory itself, making Harness unlaunchable after restart #8048: the label can land on the DSH Desktop install directory itself, after which Harness cannot start.

Users end up chasing Electron, antivirus or zone problems for hours. The only recovery today is editing ACLs by hand, and icacls cannot remove these entries (error 1332, as the README notes).

Between 0.2.0-rc.1 and rc.2, sandbox-windows-acl (acl.ts, grant.ts) and sandbox-local did not change. The reworked diagnose skill reports LOW_LABEL but does not remove it.

What we would ask for

1. Revoke the workspace grant when the sandbox is done with the folder, instead of keeping it as a cache.
2. Provide an official way to clean folders that are already marked.
3. Until then, say plainly under Known Limitations that programs started from a folder DSH has written to run at Low integrity.

An approach that works

We implemented the following against the current sandbox-windows-acl / sandbox-local code and tested it on real ACLs:

• Leases. The runner holds a lease file (<pid>, under a directory keyed by the workspace SID) for as long as it runs. When a workspace has had no live lease for ~30 s, the seam revokes the ACE, the deny and the label. Long commands and background jobs keep their access until they exit. Leases left by a crashed runner name a dead pid and are discarded. The next confined command grants again, and it checks the root first, so a grant removed from outside is repaired.
• Out of process. Grant and revoke run in a small helper process that the seam awaits. On a checkout with ~133k entries (node_modules included) one propagation takes 14–25 s, which should not sit on the Harness event loop.
• Exact revoke. SetEntriesInAclW with REVOKE_ACCESS never removes the deny, and removing a whole trustee would also remove the user's own entries. Instead, copy the DACL minus exactly the explicit entries the grant wrote, and clear the label in the same SetNamedSecurityInfoW call. While another capability grant is still on the folder, keep the deny and the label. The user's own entries (including their own Everyone entries) are left untouched.
• Cleanup. On start, clean registered workspaces that a crash or an older version left marked: one read per workspace, and a write only where a mark is found. Also offer a "clean this folder" action. When the chosen folder only inherits the marks, clean the ancestor that carries them. Refuse while a runner holds a lease there.

The cost is one re-propagation per idle period on large trees. That is far better than a project whose own programs stop working for every other tool.

This has now been reported in several threads over a week without a maintainer response. Could someone working on the Windows sandbox take a look?

---

中文

DSH 只要以 workspace-write 写过一个文件夹，它的根目录上就会永久留下三项改动：能力 SID 授权、Everyone:(CI)(DENY)(DC) 拒绝项，以及 Low 完整性标签 (OI)(CI)(NW)。会话结束、DSH 退出后依然存在。README 写明这是有意为之：授权作为复用缓存，从不撤销。

为什么严重

很多人写代码不只用一个工具：同一个项目，DSH 改完，再交给 Codex、Claude Code、IDE 或普通终端。这个标签会被树里每个文件继承。于是 DSH 用过一次之后，不管哪个工具从这个项目里启动东西，得到的都是低完整性进程或者被拒绝，而且没有任何提示指向 DSH：

• [Bug] Windows: the workspace Low integrity label also lowers the user's own launches from that tree, silently degrading the toolchain inside it #7709：项目里的 Electron/Chromium 程序一启动就以 0x80000003 退出，没有输出也没有日志
• Issue with DSH 0.2.0 rc1 creating things in internet zone? #8175：msbuild、dotnet、npm 等构建工具拒绝或警告这些文件，看起来像「来自 Internet 区域」，实际上并没有 Zone.Identifier
• [Bug] Windows：沙箱给工作区根目录盖 Low 完整性标签后，目录内的 .bat/.cmd/.exe 双击弹「无法验证发布者」 #7735：双击项目里的 .bat/.cmd/.exe 每次都弹「无法验证发布者」
• [Bug][Desktop][Windows] workspace-write can poison the DSH Desktop install directory itself, making Harness unlaunchable after restart #8048：标签可能落到 DSH 桌面端自己的安装目录上，之后 Harness 起不来

用户往往要花几个小时去查 Electron、杀毒软件或 Internet 区域。目前唯一的恢复办法是手工改 ACL，而 icacls 删不掉这些条目（README 也写了，错误 1332）。

0.2.0-rc.1 到 rc.2 之间，sandbox-windows-acl（acl.ts、grant.ts）和 sandbox-local 没有任何改动；新的诊断技能会报告 LOW_LABEL，但不会去掉它。

希望官方做的

1. 沙箱用完这个文件夹就收回授权，不要当缓存留着。
2. 提供官方办法，清理已经被打上标记的文件夹。
3. 在那之前，在已知限制里写明：DSH 写过的文件夹里启动的程序会以低完整性运行。

一个可行的做法

我们基于现有的 sandbox-windows-acl / sandbox-local 代码实现了下面这套，并在真实 ACL 上测过：

• 租约：runner 运行期间持有一个租约文件（<pid>，放在按工作区 SID 命名的目录里）。工作区约 30 秒没有活的租约，就撤掉授权、拒绝项和标签。长命令和后台任务在退出前一直保有权限；崩溃留下的租约对应的是已不存在的 pid，会被丢弃。下一条受限命令会先检查根目录再重新授予，所以被外部撤掉的授权也能补回来。
• 放到进程外：授予和收回交给一个小的辅助进程，seam 等它完成。约 13.3 万条目的仓库（含 node_modules）传播一次要 14–25 秒，不该压在 Harness 的事件循环上。
• 精确撤销：SetEntriesInAclW 的 REVOKE_ACCESS 删不掉 deny，按整个 trustee 删又会带走用户自己的条目。改为复制 DACL，只去掉授权当初写下的那几条显式条目，并在同一次 SetNamedSecurityInfoW 调用里清掉标签。文件夹上还有其他能力授权时，保留拒绝项和标签。用户自己的条目（包括他们自己的 Everyone 条目）原样保留。
• 清理：启动时清理崩溃或旧版本遗留标记的已登记工作区，每个只读一次，发现标记才写。另外提供「清理这个文件夹」的操作：选中的文件夹只是继承了标记时，就去清真正带标记的上层；那里有 runner 持有租约时先不动。

代价是大仓库每个空闲周期后要重新传播一次。对每一个别的工具来说，这都远好过项目里自己的程序起不来。

这个问题已经在好几个帖子里报告了一周，一直没有维护者回应。能否请负责 Windows 沙箱方向的同学看一下？

[IsFaser]

我服了哈哈哈, 可惜没能早点看到你, 这个问题折腾死我了.

[See-Sol-Lab]

一堆人反馈了就是没人改这个

[IsFaser]

sad...

[masknull]

可以先试试我的patch...几天前上0.1.7写的 今天无聊逛社区发现一堆人反馈以为0.2.0没问题了结果还是没解决
https://github.com/masknull/dsh-acl-sandbox-patch

[argszero]

Thanks — this is the half of the backend the other threads do not describe, and it is worth separating what can be settled from the source here from what only a Windows machine can settle.

What the shipped source does say (all read from packages/sandbox/sandbox-windows-acl, 0.2.0-rc.2):

• The three edits are standing by design, and nothing revokes them. src/grant.ts keeps the revocable and the standing sets apart and its dispose path leaves the standing workspace edits in place; src/index.ts says the same in plainer words in its fail-closed cleanup — standing ACEs "are NOT revoked — they are the intended end state (the reuse cache), not an error artifact". So your first sentence is right as written: they survive the session and DSH exiting, and there is no code path that takes them back.
• The label is inheritable and it lives in the SACL. src/acl.ts applies the DACL and the label in one SetNamedSecurityInfoW (DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION) with SUB_CONTAINERS_AND_OBJECTS_INHERIT and NO_WRITE_UP. That is also why icacls /reset cannot help: it rebuilds the DACL and never touches the SACL. Your error 1332 from icacls is consistent with that — removing an integrity label needs WRITE_OWNER on the object, not a DACL write.
• The reach out of the tree is a boundary the backend's own suite already pins. tests/runner.spec.ts has a case named "a workspace hard link lets the grant reach an external file object", with a comment saying that rejecting every multiply-linked file "is not a viable profile". A hard link is a second name for one file object, so an inheritable label written inside the tree lands on the store's object too. I cannot reproduce that here (no Windows host in this project), which is why I am citing their test rather than claiming a measurement of my own.

Your three asks are the right ones, and the ordering matters: (1) revoking the grant when the sandbox is done is a core decision with a real cost — the propagation you measured at 14–25 s per pass is the reason it is a cache; (2) a supported cleanup path is the smaller change; (3) the Known Limitations line is free and should not wait for either. I have no standing to commit the project to any of them, and I am not claiming your lease design is the one that should land — but the mechanism you describe for exact revocation (rewriting the DACL minus exactly the grant's explicit entries and clearing the label in the same call) is the shape the current code would need, because REVOKE_ACCESS cannot remove the deny and a trustee-wide removal would take the user's own entries with it.

What I did ship, since it is the part I can verify. I maintain @argszero/cordis-plugin-sandbox-grant-advisor, a diagnostic plugin for the other end of this same backend (the SetNamedSecurityInfoW failed (Win32 5) threads). Its advisory is the thing that hands a reader the command that applies the grant, so as of 0.10.0 it states what the grant leaves behind before that command: the three standing entries, the SACL location and the inheritable flag, the min(user, image) rule, and the hard-link path into a content-addressed store — with your #7709 / #8175 / #7735 symptom list as the reason it matters, all attributed to this thread rather than asserted as my own measurement.

It deliberately ships no removal command, and that is the same judgement your report argues for: the packaged diagnose-windows-sandbox-acl skill reports LOW_LABEL and by design does not remove it, removing one needs WRITE_OWNER, and a removal line I cannot test on a Windows host would be exactly the defect this family of reports is made of. (Your thread's own comment links a community patch — masknull/dsh-acl-sandbox-patch — which is the shape a real fix takes; I am not asserting it works, only that it exists and is where the attempt lives.)

npm: @argszero/cordis-plugin-sandbox-grant-advisor@0.10.0 — the section is "What the grant leaves behind, once it applies".