[BugReport] [Windows] sandbox-windows-acl 的工作区 grant 会在授予期间给指向 pnpm store 的硬链接打上 Low 完整性标签，使该 store 里的可执行文件以 Low 完整性运行

[IsFaser]

碳基话:

在从0.2-rc1升级到0.2-rc2时发现发现eslint一直在报错, 无法移除temp下的临时目录. 而我因为写插件图方便将harness源码目录导入进了harness. 导致无法升级,
因为之前的sanbox问题我手动改过完全访问权限, 我以为这个问题, 遂还原无用. 使用其他agent排查老半天终于解决了. 方案简单来说就是给完整性标签全部覆盖回去.

硅基话:

摘要

在 Windows 上以 workspace-write 模式执行受限命令时，@deepseek-ai/dsh-sandbox-windows-acl 会向工作区根写入三条常驻的安全描述符改动，其中一条是可继承（OI|CI）的 Low 完整性标签（S-1-16-4096 + NO_WRITE_UP）。SetNamedSecurityInfoW 会立即把可继承 ACE 整树传播，因此该标签也会落在 node_modules 内指向 pnpm 内容寻址 store 的硬链接上；NTFS 硬链接共享同一个安全描述符，标签于是被写到 store 的共享文件对象上并在那里常驻。

此后从该 store 硬链出来的可执行文件（esbuild.exe、lefthook.exe …）会带上 Low 标签。按 Windows 强制完整性规则，进程以 min(用户完整性, 镜像文件完整性) 创建，因此这些程序以 Low 完整性进程运行，无法删除 Medium 完整性的临时文件/钩子文件，于是 vite build、pnpm install 等与 DSH 无关的流程持续失败，且官方自带的 diagnose-windows-sandbox-acl 技能按设计无法移除完整性标签。

当前状态（重要）：报告人机器上的故障已通过手工清理消失，本文投稿时无法再复现该故障；但机制链条的每一环都已在源码、仓库自带测试、官方文档与本机实测中得到独立确认（见「证据」与附录）。

---

环境

项	值
OS	Windows 11 (10.0.22631)
Node	v22.23.2
pnpm	11.7.0
pnpm store	D:\.pnpm-store\v11（与工程同卷，packageImportMethod 为默认 hardlink）
仓库	D:\work\DS-Harness\deepseek-harness
被 grant 的工作区根	D:\work\DS-Harness（仓库位于其子目录内）
DSH 版本	0.2.0-rc.2
commit	639ed015397290b3745d163aafe02ffee4aa3f84

---

现象

1. pnpm run build 在 apps/web 的 vite build 阶段失败：

   [vite:esbuild-transpile] remove C:\Users\<user>\AppData\Local\Temp\esbuild-<hex>: Access is denied.
   

   每次构建在 %TEMP% 留下一个约 1.5 MB 的 esbuild-<hex> 残留文件。

2. pnpm install 的根 postinstall 失败：

   [install-lefthook] ... lefthook.cmd install --force failed:
   Error: could not replace the hook: remove ...\.git\dsh-hooks\pre-commit: Access is denied.
   

3. 两者是同一类故障：一个以 Low 完整性运行的可执行文件（esbuild / lefthook）删不掉 Medium 完整性的文件。

---

最小复现

1. 准备 Windows + pnpm 工程，pnpm store 与工程在同一卷（hardlink 生效）。

2. 以 workspace-write 模式、工作区根设为该工程（或含该工程的父目录）执行一次受限命令，使 AclSandbox provision 工作区 grant。

3. 之后任何时刻：

   # 应在 node_modules 的 hardlink 上看到 Low 标签
   icacls <root>\node_modules\.pnpm\@esbuild+win32-x64@<ver>\node_modules\@esbuild\win32-x64\esbuild.exe
   
   # 证明它是 store 文件的硬链接
   fsutil hardlink list <上面的 esbuild.exe>
   
   # store 里的原始对象同样是 Low
   icacls D:\.pnpm-store\v11\files\<bucket>\<hash>-exec

4. 对 >1 MB 输入调用 esbuild transform（等价于 Vite 对大 chunk 的 vite:esbuild-transpile）即稳定失败：

   import esbuild from '<repo>/node_modules/.pnpm/esbuild@<ver>/node_modules/esbuild/lib/main.js'
   let src = ''
   for (let i = 0; src.length < 1_500_000; i++) src += `export const x${i} = ${i}\n`
   await esbuild.transform(src, { loader: 'js', minify: true, target: 'es2022', sourcemap: true, format: 'esm' })
   // → remove C:\Users\<user>\...\Temp\esbuild-<hex>: Access is denied.

复现前提：必须是"标签仍在"的状态。一旦标签被清除（见「规避与恢复」），第 4 步会成功且 %TEMP% 无残留——这正是本文投稿时的状态。

---

根因

1. grant 写入三条改动，其中第三条是可继承的 Low 标签（已确认）

workspace-write 的 grant 在一次 SetNamedSecurityInfoW 调用里应用三条改动（src/acl.ts）：

1. 能力 SID 允许项 S-1-4-x-y:(OI)(CI)(W,D,DC)；
2. world 的 FILE_DELETE_CHILD 拒绝项 Everyone:(CI)(DENY)(DC)（仅容器继承）；
3. Low 完整性标签 S-1-16-4096 + SYSTEM_MANDATORY_LABEL_NO_WRITE_UP + (OI|CI)。

第 3 条可继承，会整树传播（README 自述 "eager full-tree propagation"）。

2. 硬链接让标签落到树外的共享文件对象（已确认）

工作区树的 node_modules 含大量指向 D:\.pnpm-store 的硬链接。NTFS 硬链接的两个名字指向同一个文件对象、共享同一个安全描述符，所以对链接路径设置安全描述符等于对 store 里的原对象设置。仓库自带测试已把这一行为钉死（tests/runner.spec.ts，用例名 "partial boundary: a workspace hard link lets the grant reach an external file object"），其注释也写明 "pnpm workspaces commonly contain hard links, so rejecting every multiply-linked file is not a viable profile"。

结果：Low 标签被写到 store 的共享文件对象上（带继承标记 (I)）；store 目录自身没有标签，排除了"从 store 目录继承"的可能。

3. 进程按 min(用户, 镜像) 取得完整性（官方依据）

"When a user attempts to launch an executable file, the new process is created with the minimum of the user integrity level and the file integrity level."
—— Microsoft, Mandatory Integrity Control

因此带 Low 标签的 esbuild.exe / lefthook.exe 被普通（Medium）用户启动时，进程实际以 Low 完整性运行。NO_WRITE_UP 不允许它写入/删除 Medium 对象。

4. esbuild 的具体失败路径（机制推断，行号已更正）

esbuild 的临时文件是 Node 父进程以 Medium 完整性创建的（lib/main.js 中 randomFileName() = <tmpdir>/esbuild-<hex>），而执行清理的服务端是那个 Low 完整性的 esbuild.exe；删除 Medium 文件触发 NO_WRITE_UP 拒绝，服务端报 remove <path>: Access is denied.。

注意：Node 侧的删除是静默失败的（lib/main.js 的 fsSync.readFile 对 unlinkSync 用了空 catch），因此能在用户面前冒出来的只有服务端那条错误，行号请勿再引 lib/main.js:774（该行在 0.28.1 里是 entryPoints 解析）。残留文件恰好约等于输入体积（≈1.5 MB），与"父进程写入成功、子进程删除失败"一致。

---

证据

已独立确认（本机实测）

#	证据	说明
E1	icacls "<workspace-root>" 曾出现 S-1-4-<sid>:(OI)(CI)(W,D,DC)、Everyone:(CI)(DENY)(DC)、Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)	与 grant 的三条改动逐一对应
E2	用仓库算法对同一路径现算，得到的 SID 与工作区 ACL 里那条精确一致	精确命中，排除巧合。算法：sha256(path) 前 8 字节，每 4 字节 LE 取 % 2^30-1 再 +1（src/workspace-sid.ts）。该值随路径变化，不随机器/用户变化
E3	fsutil hardlink list 显示 esbuild.exe → \.pnpm-store\v11\files\c0\ea92…-exec；lefthook.exe → \.pnpm-store\v11\files\b3\1d74…-exec	坐实"工作区内的可执行文件就是 store 的硬链接"
E4	store 抽样 40 个 *-exec：Low=0/40 且全部为显式 Medium；store 目录本身也是 Medium	这是清理后的状态，证明污染可以被移除（也说明当初 (I)Low 不是继承自 store 目录）
E5	无 DSH 限制下跑最小复现第 4 步：transform: OK, code bytes = 1275374，%TEMP% 残留 0	说明故障与标签状态强相关：标签在 = 失败，标签除 = 成功
E6	对照：Medium token 在 %TEMP% 写→读→删 1.5 MB × 多次全部成功；提权后实测 Medium 进程可删除 Low 标签文件（ok=True）	排除"通用文件锁"，并确认强制策略只禁向上写，不禁止向下写
E7	esbuild / lefthook 的 Windows 二进制确在 store 内（@esbuild+win32-x64@0.28.1、lefthook-windows-x64@2.1.9）	前提成立

未能复现（诚实声明）

• 故障态下"exe → 子进程降为 Low"的直接进程观测（GetTokenInformation(TokenIntegrityLevel) 打在那个 esbuild 子进程上）没有取到：标签清除后才具备完整命令能力。E2/E3 与官方规则、仓库测试共同支撑该推断。
• 投稿时 pnpm run build 已恢复正常，无法再给出失败日志的实时复现。

---

影响

• 机器级、跨项目、持久：一旦 store 被污染，本机所有使用该 store 的 pnpm 工程都受影响；而 dispose() 对工作区 grant 是 standing，永不撤销，官方诊断技能又明确保留完整性标签（README 的 Known Limitations 自述 "Diagnosis preserves integrity labels — it cannot fix Low-labeled executables affecting programs launched outside DSH"）。
• 症状与病因距离极远：用户看到的是构建工具/依赖安装报错，几乎不可能归因到 DSH 沙箱。
• 触发门槛低：pnpm + 同卷 store + 任一次受限命令。

---

⚠️ 附带的独立缺陷：清理之后，DSH 再也无法授权（本机复现）

这是报告人在自救过程中踩到的二级故障，请一并处理。

执行 icacls <workspace-root> /reset /T /C /Q 之后，工作区根的 DACL 只剩从卷根继承的条目（原始输出）：

<workspace-root> BUILTIN\Administrators:(I)(F)
                 NT AUTHORITY\SYSTEM:(I)(F)
                 NT AUTHORITY\Authenticated Users:(I)(M)   ← 只有 Modify
                 BUILTIN\Users:(I)(RX)
                 Mandatory Label\Medium Mandatory Level:(OI)(CI)(NW)

当前用户没有任何显式 ACE，而 Authenticated Users:(M) 不含 WRITE_OWNER。实测 CreateFileW(WRITE_DAC | WRITE_OWNER)：工作区根 DENIED win32=5、D:\.pnpm-store DENIED（对照：仓库子目录与 %TEMP% 均为 OK）。

而 grantWrite 要求调用者拥有 WRITE_OWNER（标签在 SACL；owner 的隐式权利只覆盖 READ_CONTROL 与 WRITE_DAC —— 见 src/acl.ts 的 JSDoc）。于是此后每一条受限命令都在 provision 阶段失败：

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

DSH 的 sandbox 是 fail-closed，因此命令根本不执行（连 Write-Output "ping" 也一样），该会话里只剩下不经过沙箱的文件读写工具可用。这与"再跑一次受限命令只是让 grant 重新写入"完全不同。

可自救的修复（用户此时仍持有 WRITE_DAC，无需提权）：

icacls "<workspace-root>" /grant "$env:USERNAME:(OI)(CI)F"

请一并澄清的文档事实：icacls /reset 不会清除 Low 标签——标签在 SACL，/reset 只重建 DACL。真正移除标签的是 icacls <path> /setintegritylevel Medium，而它需要 WRITE_OWNER，普通权限下会 Access is denied（本机实测 exit=5），必须提权执行。

---

期望行为

• 沙箱不得在工作区之外的对象（尤其是跨项目共享的内容寻址 store 文件）上写入持久的安全描述符改动；
• 传播前应探测指向树外的多链接（硬链接）对象，命中时 fail-closed 或降级，而不是污染外部共享对象；
• 必须提供受支持的撤销/清理路径，并让诊断技能能够移除 standing grant 与其标签；
• 当工作区根缺少 WRITE_OWNER 时，应在授权前明确报出"工作区需要 FullControl 而非 Modify"，而不是让整个会话瘫痪；
• 文档需记录该具体症状与规避方式。

---

建议修复

1. 传播标签前检测硬链接：用 GetFileInformationByHandle 的 nNumberOfLinks 找出多链接对象，并判定其其它链接名是否在工作区内；命中树外链接时拒绝或降级。README 目前以 "rejecting multiply-linked files is not viable for ordinary pnpm installations" 为由未处理——但"拒绝多链接文件"与"探测并在命中树外链接时不施加可继承标签"是两回事，后者正是本 issue 的触发条件。
2. 不要对文件施加可继承标签。注意：仅"对目录打标签、文件不打"会带来已知代价——被限制的子进程将连工作区内已有文件都无法删除，等于退回 ADR 关闭删除逃逸之前的状态。因此该方向应表述为"对含树外硬链接的树不施加可继承标签"，或明确接受该代价并同步修改删除封闭性的承诺。
3. 增加 standing workspace grant 的真实撤销入口（现有 revokeWrite 只覆盖可撤销的 temp 授权），并提供清理命令；Dev Note 目前把"回收改名工作区残留 ACE 的清理命令"列为 undecided。
4. 扩展 diagnose-windows-sandbox-acl：使其能移除 standing 标签/ACE。当前该技能既不能移除标签，其自身文档也未提示这个盲区（只有包 README 的 Known Limitations 提到），用户按技能跑完不会被告知标签仍在。
5. 授权前做权限前置检查：工作区根缺 WRITE_OWNER 时给出可执行的指引（例如提示执行上面的 icacls /grant），避免 fail-closed 变成"整个会话不可用"。
6. 降低默认影响或明确告知：Windows 上默认不挂 ACL 后端，或首次使用时明确告知会常驻修改安全描述符。

---

规避与恢复

# 1) 恢复工作区根的可授权状态（普通权限即可；注意不要再用 /reset）
icacls "<workspace-root>" /grant "$env:USERNAME:(OI)(CI)F"

# 2) 移除工作区树的 Low 标签（需要 WRITE_OWNER → 在【管理员】PowerShell 中执行）
icacls "<workspace-root>" /setintegritylevel "(OI)(CI)Medium" /T /C /Q

# 3) 恢复被污染的 pnpm store（需要 WRITE_OWNER → 管理员）
icacls "D:\.pnpm-store" /setintegritylevel "(OI)(CI)Medium" /T /C /Q

# 4) 复跑
node scripts/install-lefthook.mjs
pnpm run build

日常规避：

• 运行 DSH 会话时使用 完全权限 / danger-full-access，绕开 Windows ACL 后端；
• 或强制 pnpm 复制而非硬链接：$env:npm_config_package_import_method='copy' 后重装。

注意：只要再跑一次 DSH 的受限命令，grant 会重新写入（exact-ACE 跳过只在三条改动都还在时生效，而第 1、2 步已经把两条 DACL 改动清掉了）。因此长期应使用完全权限模式。

---

相关代码与文档

• packages/sandbox/sandbox-windows-acl/src/workspace-sid.ts（SID 推导：sha256 前 8 字节）
• packages/sandbox/sandbox-windows-acl/src/acl.ts（三条改动的合并应用；grantWrite/revokeWrite；WRITE_OWNER 要求见其 JSDoc）
• packages/sandbox/sandbox-windows-acl/src/token.ts（restrictTokenIntegrity：把受限 token 降到 Low）
• packages/sandbox/sandbox-windows-acl/src/grant.ts、src/index.ts（workspace grant 为 standing、dispose() 不撤销）
• packages/sandbox/sandbox-windows-acl/README.md（硬链接边界、standing 编辑、Diagnosis preserves integrity labels、eager full-tree propagation）
• packages/sandbox/sandbox-windows-acl/tests/runner.spec.ts（"a workspace hard link lets the grant reach an external file object"）
• .agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.md（Low 标签与 token 降权的设计取舍）
• packages/sandbox/sandbox-windows-acl/assets/diagnose-windows-sandbox-acl/SKILL.md（"never … erase a deny, or replace child permissions recursively"；以及 "A confined run of the script is never useful"）
• Microsoft, Mandatory Integrity Control（进程完整性 = min(用户, 镜像)）

---

需要复现 E2 的读者：对你自己的工作区根运行附录第 1 节的脚本即可，SID 必然随路径不同而变化——关键是"ACL 里那条 SID == 按该算法算出的值"这一一致性，而非某个固定数值。

附录：Windows ACL / 硬链接 / 完整性标签 证据复现手册

配套 issue：issue-windows-acl-hardlink-store.md。
所有命令均为只读，除非明确标注「会改动」。

示位符约定：

• <workspace-root> = 报告人的工作区根（即仓库的父目录），下游只有一个 pnpm 工程；
• <repo> = <workspace-root> 内的仓库目录（含 node_modules）。

---

0. 环境对照

(Get-Content '<repo>\package.json' | Select-String '"version"|packageManager')
Get-Content '<repo>\.git\refs\heads\master'

观测：

"version": "0.2.0-rc.2",
"packageManager": "pnpm@11.7.0",
639ed015397290b3745d163aafe02ffee4aa3f84

→ 与 issue 环境表一致（同 commit 也挂在 refs/tags/dsh-v0.2.0-rc.2）。

---

1. 工作区 SID 的独立复算（E2）

$p = '<workspace-root>'   # 换成你自己的工作区根（注意：必须是 canonical 拼写）
$d = [System.Security.Cryptography.SHA256]::Create().ComputeHash([System.Text.Encoding]::UTF8.GetBytes($p))
$a = [BitConverter]::ToUInt32($d,0) % 1073741823 + 1
$b = [BitConverter]::ToUInt32($d,4) % 1073741823 + 1
"S-1-4-$a-$b"

观测（报告人机器）：

S-1-4-<sid>          # 该值由路径决定，随路径变化；此处不披露具体数值

→ 复算结果与 icacls "<workspace-root>" 输出里那条能力 SID 逐字一致。算法等价于 src/workspace-sid.ts：sha256(canonicalPath) 前 8 字节，每 4 字节 LE 取 % (2^30-1) 后 +1。

判据不是某个固定数值，而是一致性：ACL 里出现的那条 S-1-4-* 必须等于按上式对工作区路径算出的值。读者换用自己的路径，数值必然不同。

---

2. store 硬链接关系（E3）

$exe = '<repo>\node_modules\.pnpm\@esbuild+win32-x64@0.28.1\node_modules\@esbuild\win32-x64\esbuild.exe'
$lf  = '<repo>\node_modules\.pnpm\lefthook-windows-x64@2.1.9\node_modules\lefthook-windows-x64\bin\lefthook.exe'
fsutil hardlink list $exe
fsutil hardlink list $lf

观测（<repo> 段已替换）：

\.pnpm-store\v11\files\c0\ea922534539bbb08cf3f829b4905a7e92288b43e990b35e9807ac518e59ba2eb9920c64b328677c01e76dd0fffdcba1c0fd26a40f34767da0abd699e62a0d2-exec
\<repo>\node_modules\.pnpm\@esbuild+win32-x64@0.28.1\node_modules\@esbuild\win32-x64\esbuild.exe

\<repo>\node_modules\.pnpm\lefthook-windows-x64@2.1.9\node_modules\lefthook-windows-x64\bin\lefthook.exe
\.pnpm-store\v11\files\b3\1d74ece35dcda441d2f6b51e556274a399cade4bd897f6f5b24a9e459262c1241eca4dd06976669d3bc512ea4439291f23fb8f9610a30e791efec3d18eee98-exec

→ 两个可执行文件都是 store 的硬链接（同一文件对象的两个名字）。这里的 <repo> 位于 <workspace-root> 之内，而 store 位于其之外——正是本 issue 的前提：grant 沿树传播时会顺着硬链接摸到树外的共享对象。

---

3. 标签现状（清理后，E4）

# store 目录自身
icacls 'D:\.pnpm-store' | Select-String 'Mandatory Label'

# store 内 *-exec 抽样：Low 数量
$all = Get-ChildItem 'D:\.pnpm-store\v11\files' -Recurse -File -Filter '*-exec' | Select-Object -First 40
$low = 0; $tot = 0
foreach ($e in $all) { $tot++; if (icacls $e.FullName 2>&1 | Select-String 'Low Mandatory Level') { $low++ } }
"low=$low total=$tot"

观测：

Mandatory Label\Medium Mandatory Level:(OI)(CI)(NW)
low=0 total=40

单个样本（icacls <store 文件>）：

Mandatory Label\Medium Mandatory Level:(I)(NW)

→ 投稿时 store 没有 Low 标签。这是清理后的状态；它同时说明该标签可以被移除，且 (I) 继承标记对应的传播源不可能是 store 目录（store 目录自己的标签不带 Low）。

---

4. 工作区根的 DACL 与标签（原始输出）

icacls '<workspace-root>'

观测（/reset 之后；仅首行路径被替换）：

<workspace-root> BUILTIN\Administrators:(I)(F)
                 BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                 NT AUTHORITY\SYSTEM:(I)(F)
                 NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                 NT AUTHORITY\Authenticated Users:(I)(M)
                 NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
                 BUILTIN\Users:(I)(RX)
                 BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                 Mandatory Label\Medium Mandatory Level:(OI)(CI)(NW)

关键点：

• 报告人账号没有任何显式 ACE，只剩从卷根继承的条目（全部带 (I)）。
• Authenticated Users:(I)(M) 只给 Modify，不含 WRITE_OWNER。
• 标签是无 (I) 的显式 Medium，带 (OI)(CI) —— 与 icacls <path> /setintegritylevel 的写法一致。

对照：store 内的 esbuild.exe（同一个硬链接对象）：

BUILTIN\Users:(I)(F)
BUILTIN\Administrators:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\Authenticated Users:(I)(M)
Mandatory Label\Medium Mandatory Level:(I)(NW)

---

5. WRITE_DAC | WRITE_OWNER 有效权限探测（本 issue 的二级故障）

Add-Type -Namespace A -Name P -MemberDefinition @'
[DllImport("kernel32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern IntPtr CreateFileW(string path, uint access, uint share, IntPtr sec, uint disp, uint flags, IntPtr tmpl);
public static string Probe(string path) {
  IntPtr h = CreateFileW(path, 0x00040000 | 0x00080000, 7, IntPtr.Zero, 3, 0x02000000, IntPtr.Zero);
  if (h == new IntPtr(-1)) return "DENIED win32=" + Marshal.GetLastWin32Error();
  return "OK";
}
'@
foreach ($p in @('<workspace-root>','<repo>','<workspace-root>\.acl-reports','D:\.pnpm-store',"$env:TEMP")) {
  "{0,-18} {1}" -f [A.P]::Probe($p), $p
}

观测：

DENIED win32=5      <workspace-root>        ← 工作区根：缺 WRITE_OWNER
OK                  <repo>
DENIED win32=5      <workspace-root>\.acl-reports
DENIED win32=5      D:\.pnpm-store
OK                  C:\Users\<user>\AppData\Local\Temp

win32=5 即 ERROR_ACCESS_DENIED。grantWrite 的标签写入需要 WRITE_OWNER，因此工作区根上 provision 必然失败：

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

（DSH 是 fail-closed，报此错时命令不会执行。）

---

6. icacls /setintegritylevel 的权限要求（会改动，仅新建的临时目录）

$t = Join-Path '<workspace-root>' '.acl-final'
New-Item -ItemType Directory -Path $t | Out-Null
icacls $t /setintegritylevel Low          # 观测 exit=5 / Access is denied（缺 WRITE_OWNER）
cmd /c rmdir /s /q "$t"                    # 清理

观测：

setintegritylevel exit=5  Successfully processed 0 files; Failed processing 1 files | ...\.acl-final: Access is denied.

在提权会话中同一操作 exit=0，并得到：

Mandatory Label\Low Mandatory Level:(NW)

→ 说明：设置/移除完整性标签需要 WRITE_OWNER；普通权限的工作区（只有 Modify）无法完成"清除标签"这一步，必须提权。

---

7. 完整性策略的语义对照（提权，仅在 %TEMP% 新建的子目录内）

在一个全新 %TEMP% 子目录里执行（脚本结束即删除）：

步骤	观测
给文件打 Low 标签	Mandatory Label\Low Mandatory Level:(NW)
Medium 进程删除该 Low 文件	ok=True（删除成功）
在 Low 目录内创建文件	ok=True，新文件标签为 Mandatory Label\Low Mandatory Level:(I)(NW)
Medium 进程删除该文件	ok=True

→ 强制完整性策略只禁止向上写（Low → Medium 被拒），不禁止向下写（Medium → Low 允许）。这正是"Low 进程删不掉 Medium 临时文件"与"用户自己能清理 Low 对象"能同时成立的原因。

---

8. esbuild 复现脚本（标签清除后：应当成功）

// verify-esbuild.cjs —— <repo> 换成你自己的仓库路径
const os = require('node:os'); const fs = require('node:fs')
const esbuild = require('<repo>/node_modules/.pnpm/esbuild@0.28.1/node_modules/esbuild/lib/main.js')
;(async () => {
  let src = ''
  for (let i = 0; src.length < 1_500_000; i++) src += `export const x${i} = ${i}\n`
  try {
    const out = await esbuild.transform(src, { loader: 'js', minify: true, target: 'es2022', sourcemap: true, format: 'esm' })
    console.log('transform: OK, code bytes =', out.code.length)
  } catch (e) { console.log('transform: FAILED ->', e.message) }
  await new Promise(r => setTimeout(r, 500))
  console.log('esbuild-* residue in temp:', fs.readdirSync(os.tmpdir()).filter(n => n.startsWith('esbuild-')).length)
})()

观测（标签已清除的状态）：

tempdir       : C:\Users\<user>\AppData\Local\Temp
input bytes   : 1500000
transform     : OK, code bytes = 1275374
esbuild-* residue in temp now: 0 (new this run: 0)

→ 与 issue 中"标签在 = remove … Access is denied. + 约 1.5 MB 残留"形成对照；也说明故障与标签状态强相关。

---

9. 关于 .acl-reports\acl-report-*.jsonl（既有诊断报告，请勿据此归因）

工作区里存在一份由 diagnose-windows-sandbox-acl 生成的报告。其调用者 token 记录为：

{"kind":"observation","operation":"caller","status":"read","details":{"integrity":"S-1-16-4096 (Low)", "...":"..."}}

随后对 C:\Users\<user>（(OI)(CI)(F)）等路径全部判定：

{"writeDac":false,"writeOwner":false}

并以 PRECONDITION 结束、"fixed":0、"status":"skipped","reason":"No mutation mode was requested; all reported ACLs were left unchanged."

这是受限会话里的假警报：脚本自己就是 Low 完整性 token，当然读不到 Medium 对象的 WRITE_DAC/WRITE_OWNER。SKILL.md 本身要求 "Run it unconfined… A confined run of the script is never useful"。此报告为只读 + skipped，未对 ACL 做任何改动——可据此排除"诊断技能改坏了 ACL"。

---

10. 本次核验产生的临时文件

全部位于 <workspace-root> 顶层，均可删除：

• .acl-verify* / .acl-final / .acl-snap / .acl-verify2/3/4（测试目录，已逐个清理）
• .acl-verify-esbuild.cjs（第 8 节脚本，已删除）
• acl-verify-elevated.ps1 + .log（提权测试，已删除）

未改动 pnpm store 内容、未改动任何既有对象的安全描述符。

[argszero]

This is the most complete mechanism chain in the family, and I can confirm each link from the shipped source (packages/sandbox/sandbox-windows-acl, 0.2.0-rc.2) — which matters here, because your report says the failure itself became non-reproducible on your machine once the labels were cleared. A chain whose links are independently checkable does not depend on the original repro:

• Three edits, one call, one of them inheritable. src/acl.ts applies the capability ACE, the Everyone:(CI)(DENY)(DC) deny and the Low label (S-1-16-4096, NO_WRITE_UP) in a single SetNamedSecurityInfoW carrying DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION, with SUB_CONTAINERS_AND_OBJECTS_INHERIT. Your point about the eager whole-tree propagation follows from that flag combination.
• The hard-link step is a boundary the repository already documents. tests/runner.spec.ts pins it in a case named "a workspace hard link lets the grant reach an external file object", and its comment adds that refusing multiply-linked files "is not a viable profile" for a pnpm workspace. Two names, one file object, one security descriptor — so the store's object carries the label, with the (I) you observed on the store object and no label on the store directory itself. That is exactly the arrangement your icacls / fsutil sequence shows.
• min(user, image) is Microsoft's rule, not an inference. Processes start at the lower of the two integrity levels, so a normal-Medium launch of a Low-labelled esbuild.exe produces a Low process, and NO_WRITE_UP is what makes it unable to delete the Medium temp files its Medium parent created.
• The skill boundary you name is real and is a version boundary as well. diagnose-windows-sandbox-acl reports LOW_LABEL and by design does not remove it, and — worth knowing if you compare against an older tree — that skill does not exist in the 0.1.7 line at all; it arrives with 0.2.0. So a reader who found the promise in a 0.1.7 README was reading a 0.2.0-era document.

What I shipped, and what I deliberately did not. I maintain @argszero/cordis-plugin-sandbox-grant-advisor, a diagnostic plugin for the other half of this backend (SetNamedSecurityInfoW failed (Win32 5): grantWrite(...), the twelve threads in this family). Because its advisory is what hands a reader the command that applies the grant, 0.10.0 now states what the grant leaves behind — the standing entries, the SACL and the inheritable flag, the min(user, image) rule, and this hard-link chain into the content-addressed store with vite build / pnpm install as the far away symptom — before that command rather than after.

It ships no removal command. Removing an integrity label needs WRITE_OWNER, this project has no Windows host to verify a line on, and an unverified removal command handed to a reader is the same defect the reports in this family are made of. The section says where it stops and why, and attributes the out-of-tree chain to your measurement instead of presenting it as a property of every workspace.

One correction to your own text, offered because it is the kind of thing that gets requoted: you write that the failure "cannot be reproduced any more" on your machine while the mechanism is confirmed at every link. That is the strongest form this report can take — a mechanism verified per link is more useful than a repro that only worked once, and the reproduction steps you did record (fsutil hardlink list, the store object's icacls, the >1 MB esbuild transform) are the ones someone else can follow.

npm: @argszero/cordis-plugin-sandbox-grant-advisor@0.10.0.