[Bug][Windows] Windows ACL 沙箱（workspace-write）三个授权缺陷：受保护 DACL 子目录永不获授权 / desktop 根授权缓存不复核不自愈 / 标准用户+非系统盘 grantWrite 失败（Win32 5）

[wldxiaobai]

项	内容
版本	DeepSeek Harness 桌面版（Electron 安装版）0.2.0-rc.2，nightly 更新通道
平台	Windows，NTFS 非系统盘（数据盘）工作区；标准用户账户（无 Administrators，Low-IL 过滤令牌实测确认）
会话策略	file policy = workspace-write，approval = ask
沙箱实现	@deepseek-ai/dsh-sandbox-windows-acl：WRITE_RESTRICTED 受限令牌 + 确定性工作区能力 SID（S-1-4-*）+ Low 完整性标签 + world 拒绝 FILE_DELETE_CHILD，一次 SetNamedSecurityInfoW 写入
复现形态	desktop 与 agentless runner（直调 runner.js）均复现，各缺陷归属见下文

---

摘要

实测发现 Windows ACL 沙箱存在 3 个授权缺陷（A / B / C）。用户侧最直观的症状是「沙箱写权限不对工作区子目录开放」，实测其成因与另两个缺陷相关但独立：

• 缺陷 A（子目录授权缺口，desktop 与 agentless 均复现）：DACL 不继承工作区根（受保护 DACL）的子目录，永远不会获得工作区能力 SID 的授权 ACE；受限进程在其中创建/追加/删除全部被拒（读取正常）。与 profile 无关。
• 缺陷 B（desktop 独有，缓存不自愈）：desktop seam 的工作区常驻授权是「每工作区每服务器生命周期一次 + 复用缓存」，此后不再复核根 DACL。根上的能力 ACE 一旦丢失（用户/工具改 ACL、备份恢复等），连工作区根都写不进，且不会自愈，直到桌面端重启；agentless runner 每次调用重新校验并自动补授权（实测自愈）。
• 缺陷 C（授权前置条件失败，环境触发）：标准用户 + 工作区位于数据盘默认继承 ACL 之下（Authenticated Users=Modify，用户无显式 ACE）时，授权所需的 Low 标签编辑要求 WRITE_OWNER 而当前用户没有 → SetNamedSecurityInfoW 返回 Win32 5 → 会话内所有受限命令在启动前即失败。内置 ACL 诊断技能可修复，但工具错误只抛裸 Win32 串，没有任何引导。

---

附带发现

• 曾作为工作区根的目录上永久残留常驻编辑：能力 SID ACE、world 拒绝、Low 标签会留在「曾作为工作区根」的目录上（实测工作区的父、祖父两级目录各残留一条非继承的旧工作区能力 SID ACE）。无 inert 危害，但跨工作区会累积。
• icacls /remove 无法处理未映射的能力 SID（静默处理 0 个文件），与源码 README 记载的 ERROR_NONE_MAPPED (1332) 一致；手工清理须用 .NET 按 SID 操作。
• harness 的 read 工具读 asar 内路径时报 Cannot mix BigInt and other types（工具层缺陷，与沙箱无关，一并反馈）。
• 受限令牌（Low IL + WRITE_RESTRICTED）下 WMI/CIM 查询被拒（「无法从客户端中访问 CIM 资源」），属预期约束，仅记录。

---

测试范围声明

仅覆盖 Windows ACL 沙箱的 desktop 与 agentless 两种形态；junction/reparse 子树、跨卷移入（copy 语义，预期重新继承）、FAT/exFAT 卷未测；缺陷 B 的缓存生命周期上界（新会话是否重建 server）未验证，但不影响上述结论。

[wldxiaobai]

缺陷 A：受保护 DACL 子目录永远无法写入

症状

会话开始时（若同时命中缺陷 C）每一条 shell 命令在执行前就失败：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<工作区根>)

排除缺陷 C 后（工作区根授权成功、根可写），工作区内不通过 NTFS 继承获得权限的子目录仍全部拒绝写入，且缺失是永久性的（授权侧跳过逻辑只看根，见机理节）。

复现

# 0) 前提：workspace-write 会话已能正常受限写入（根授权完成）
# 1) 非受限侧准备夹具（DACL 受保护，不含能力 ACE）：
mkdir <工作区根>\sub-protected
icacls <工作区根>\sub-protected /inheritance:r /grant "$env:USERNAME:(OI)(CI)F"
# 2) 受限侧（沙箱内 shell）：
'x' | Set-Content <工作区根>\sub-protected\f.txt
#    → 拒绝访问（Get-Content 读取却正常）

实测矩阵

场景	受限（workspace-write）写入结果
工作区根写文件	✅ OK
受限进程自建子目录：建目录、写、读、删除	✅ OK
受限进程建 5 层嵌套 a\b\c\d\e 后在最深层写	✅ OK
宿主进程（write 工具）创建的子目录内写	✅ OK
从工作区外同卷移入的子目录内写	✅ OK（Windows 移入时自动把新父目录的可继承 ACE 传播进被移目录，icacls 可见 (I) 能力 ACE）
DACL 受保护（/inheritance:r，不继承）的子目录：新建文件 / 追加既有文件 / 新建子目录	❌ 全部「拒绝访问」
同上目录内读取	✅ OK（读不受限是设计行为）
授权前就已存在的保护型子目录；摘除根 ACE 迫使下次调用重新授权（含「急切全树传播」）后写入	❌ 仍拒绝；传播完全没有触达该子目录（DACL 无变化）
保护型子目录执行 icacls /reset（恢复继承）后写入	✅ OK（有效应急补救）

触发条件

触发：工作区内任何 DACL 不继承根的子目录。现实来源：robocopy /COPYALL、提权安装器/工具设置过显式权限的目录、icacls /inheritance:r、某些解压/备份还原流程、以显式 DACL 创建目录的服务进程。

不触发（实测）：受限进程自建目录、宿主进程（write 工具）创建的目录、任意深度嵌套、同卷移入的目录（Windows 自动补继承）。

profile 归属：无关。desktop 与 agentless runner（直接调 dsh-sandbox-windows-acl/lib/runner.js，不带 --write-sid 对）均复现。

[wldxiaobai]

缺陷 B：desktop 根授权缓存陈旧，ACE 丢失后连根都写不进且不自愈

症状

desktop seam 首次成功授权后缓存「已物化」；此后根上的能力 ACE 被移除/丢失（现实中如用户重置 ACL、从备份恢复目录、某些「权限修复」工具），受限写入连工作区根一起失败，不会自愈（后续调用不再重新授权），直到桌面端/工作区服务器重启。

复现

# 1) 会话内先成功执行一次受限写（seam 物化并缓存根授权）
# 2) 非受限侧摘除根上的能力 ACE（icacls 处理不了未映射 SID，须 .NET）：
$acl = Get-Acl <工作区根>
$cap = @($acl.Access | ? { "$($_.IdentityReference)" -like 'S-1-4-*' -and -not $_.IsInherited })
$cap | % { $acl.RemoveAccessRuleSpecific($_) }
Set-Acl <工作区根> $acl
# 3) 受限侧再写工作区根 → 拒绝访问；此后每次调用都失败，重启桌面端才恢复

agentless 对照

同破坏下，agentless runner 第二轮调用写入成功且能力 ACE 自动补回（DACL 快照可见原能力 SID 重现）——runner 每次 spawn 自行 grantWrite，幂等跳过判据每次实读 DACL。

agentless runner 直调方式（对比实验用）：

ELECTRON_RUN_AS_NODE=1 "DeepSeek Harness.exe" --expose-internals `
  <安装目录>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js `
  --workspace <ws> --temp <已存在的临时根目录> --mode workspace-write -- pwsh -NoProfile -Command "..."

[wldxiaobai]

缺陷 C：标准用户 + 非系统盘工作区，grantWrite 报 Win32 5，会话内全部命令启动前失败

症状

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<工作区根>)

沙箱对工作区根做 ACL 授权这一步被 Windows 拒绝（错误 5 = 拒绝访问），命令本体根本没有运行。错误只抛裸 Win32 串，没有任何引导。

复现

标准用户在非系统盘（数据盘默认继承 ACL）下新建工作区 → 新会话执行任意受限命令 → 上述错误

触发条件

标准用户 + 工作区位于默认 ACL 不给当前用户 WRITE_OWNER 的路径（数据盘默认 ACL：Authenticated Users (S-1-5-11) 仅 Modify，Users 仅 RX，Administrators/SYSTEM FullControl，当前用户 SID 无显式 ACE）+ 宿主进程非提权。工作区在用户配置文件目录下（用户对目录有显式 FullControl）则不触发。

DSH 内置的 ACL 诊断技能（diagnose-windows-sandbox-acl）可修复：给当前用户在工作区根补一条 FullControl ACE 后，WRITE_OWNER: false → true 验证通过、授权成功。

---

观测到的机理（源码证据，行号为 0.2.0-rc.2 app.asar 内文本行号，可用 rg -n 复查）

沙箱（dsh-sandbox-windows-acl）的授权模型：

1. grantWrite(path)（≈L909762）读取当前 DACL 与标签，做精确跳过判定（L909765）：hasExactGrant && hasExactDeny && hasExactLabel —— 三者在根上都精确存在则跳过；否则用一次 SetNamedSecurityInfoW 同时写入能力 SID 允许 ACE（(OI)(CI) 可继承，掩码 GRANT_MASK=1114454=0x110156，L909192——不含 WRITE_DAC）、world 拒绝 FILE_DELETE_CHILD（(CI)）、Low 标签（(OI)(CI)(NW)）。失败即抛 Win32Error（L909658，即会话里看到的 grantWrite(<路径>) 错误串）。
2. 带可继承 ACE 的该调用会让 NTFS 急切地把 ACE 传播到全部现存后代（README L907888）——但不会触碰 DACL 受保护（不继承）的子目录（实测证实）。
3. 之后新出现的子目录通过创建时继承获得能力 ACE（实测证实，含同卷移入自动补继承）。
4. 因此能力 ACE 到达子目录的唯一两条通道（首次传播 / 创建继承）都绕开「受保护 DACL」子目录，且跳过判定只检查根 → 一旦缺失，无任何机制补齐（缺陷 A）。
5. GRANT_MASK 不含 WRITE_DAC，受限进程自己无法修复，修复只能来自宿主侧。
6. 两种运行形态：desktop seam「每工作区每服务器生命周期物化一次 + 复用缓存」，runner 侧 manageDacls:false（L907817、L909131）；agentless runner 每次 spawn 自行 grantWrite（manageDacls:true，L910446-910448，幂等跳过判据每次实读 DACL）→ 缺陷 B 的根源是 seam 只信缓存、不复核。
7. 缺陷 C 的根源：标签编辑需要 WRITE_OWNER；属主隐含权只覆盖 READ_CONTROL/WRITE_DAC；数据盘默认 ACL 不给标准用户 WRITE_OWNER → L909658 抛 Win32 5。

关键 ACL 快照（占位符表示）

授权成功后的工作区根：

<工作区根> Everyone:(CI)(DENY)(DC)                  ← world 拒绝删除子项（非继承）
           S-1-4-<本工作区能力SID>:(OI)(CI)(W,D,DC)  ← 工作区能力 SID（非继承）
           <当前用户>:(F)                             ← ACL 诊断技能修复条目
           S-1-4-<旧能力SID>:(I)(OI)(CI)(W,D,DC)     ← 曾作为工作区根的祖先目录上的残留（继承而来）
           ...(卷默认 ACL)...
           Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) ← Low 标签（可继承）

缺陷 A 现场的保护型子目录（无能力 ACE；Low 标签在 SACL，不受 /inheritance:r 影响）：

<工作区根>\sub-protected <当前用户>:(OI)(CI)(F)
                         Mandatory Label\Low Mandatory Level:(I)(OI)(CI)(NW)

[wldxiaobai]

补充：发帖前检索了本仓库 Discussions，把与本帖各缺陷重合的历史反馈汇总如下，方便对照与去重。

缺陷 A（受保护 DACL 子目录 capability ACE 永不补授）

• [Bug Report] Windows 工作区：连接后外部创建/移入的子目录永远无法写入（capability ACE 永不补授） #423 《[Bug Report] Windows 工作区：连接后外部创建/移入的子目录永远无法写入（capability ACE 永不补授）》——机理定位与本帖完全一致（grantWrite 的 hasExactGrant 精确跳过只看根 + 可继承 ACE 的 eager 传播只在首次 provision 发生），0.1.0-rc.6 时代已报告；本帖在 0.2.0-rc.2 实测仍复现。
  • 一处事实分歧供对照：[Bug Report] Windows 工作区：连接后外部创建/移入的子目录永远无法写入（capability ACE 永不补授） #423 称「同卷移动保留源 DACL → 移入的子目录不可写」；本帖实测（矩阵 T5）同卷移入时 Windows 会自动把新父目录的可继承 ACE 传播进被移目录、写入正常。两个结论可能各自成立于不同前提（被移目录原 DACL 是否已含可继承条目）。
• [0.2.0-rc.2][Windows] workspace-write: subdirectories unwritable — Low mandatory label not inherited by children (DACL grant present) #8383 《[0.2.0-rc.2][Windows] workspace-write: subdirectories unwritable — Low mandatory label not inherited by children (DACL grant present)》——症状相同（根可写、子目录全拒），但作者归因于 Low 完整性标签未到达子目录（no-write-up），并称 DACL grant 存在且正确继承；这与本帖实测（Low 标签 (OI)(CI) 可继承、子目录标签为 (I)；而保护型子目录的 DACL 确实无能力 ACE）相矛盾。同一症状可能有两条独立触发路径，建议维护者两帖对照排查。
• 同症状家族（子目录 DACL 丢失/未含能力 ACE 后永久不可写）：[Windows] workspace-write 沙箱下 tempfile.TemporaryDirectory() 失败：chmod 重写 DACL 抹掉 capability ACE #7395（tempfile 的 chmod 重写 DACL 抹掉 capability ACE）、[Bug][Windows sandbox] tempfile.mkdtemp creates unwritable directories #1490（tempfile.mkdtemp 创建的目录不可写）。

缺陷 B（desktop 根授权缓存不复核、不自愈）

未检索到「工作区根能力 ACE 被摘除 → desktop seam 不复核 → 连根都写不进」的完全同款报告，本帖复现应属新实例。但同一「缓存态永不复核 → 会话内永久失效」模式在私有 temp 目录上已有多条报告：

• windows-acl sandbox: cached private temp dir is never re-validated — one external delete permanently bricks the sandbox mid-session #6801 《windows-acl sandbox: cached private temp dir is never re-validated — one external delete permanently bricks the sandbox mid-session》
• Bug report: Windows windows-acl sandbox dies permanently for a session when its cached private temp dir disappears #6483、Bug:Windows ACL 沙箱在其缓存的私有临时目录被回收后永久失效 #5477（缓存的私有临时目录被外部清理/回收后，沙箱在会话内永久死亡）
• windows-acl: private temp dir under C:\Windows\Temp loses creator access after ACL re-apply (all sandboxed commands unusable) #2287（C:\Windows\Temp 下私有 temp 在 ACL re-apply 后丢失创建者访问权，全部沙箱命令不可用）
• [Bug Report] Windows：非提权启动时 workspace-write 沙箱 provisioning 必然失败，且留下残破 ACL 导致永久无法自愈 #8115（非提权启动时 provisioning 必败，且留下残破 ACL 导致永久无法自愈）——涉及「授权状态损坏后不自愈」的同一面，其根因是缺陷 C 的另一形态。

缺陷 C（grantWrite Win32 5 / 缺 WRITE_OWNER）

社区报告量最大的问题，横跨 0.1.7-alpha2 → 0.2.0-rc.2（本帖版本），检索时点看仍未修复：

• [Bug][Windows] 工作区在用户配置目录之外时沙箱预授权 fail-closed（SetNamedSecurityInfoW Win32 5） #8387（0.2.0-rc.2 桌面版，工作区在用户配置目录之外时预授权 fail-closed；根因分析与本帖一致——SACL 标签写入需 WRITE_OWNER、属主隐含权不含它，并给出 icacls /grant <用户>:(OI)(CI)(WO) 免提权修复；同样指出报错无任何引导）
• [sandbox-windows-acl] 标准用户 + 非系统盘工作区下 workspace-write 完全不可用：缺少 WRITE_OWNER 导致 grantWrite 失败 #8339（标准用户 + 非系统盘工作区，workspace-write 完全不可用；与本帖环境组合几乎相同）
• Sandbox (workspace-write) broken after update: SetNamedSecurityInfoW failed (Win32 5) - grantWrite now requires WRITE_OWNER on workspace root #8282、# [Windows] 非系统盘工作区在 sandbox provisioning 阶段 fail-closed（Win32 5），且唯一官方修复手段与「避免 Low 完整性标签副作用」不可兼得 #8275、DSH 沙箱初始化失败：工作区位于数据盘时 grantWrite 报 Win32 5（缺 WRITE_OWNER），会话内一切命令不可用 #8232、[Bug] [Windows] 0.1.7-rc.2 沙箱 grantWrite 失败：SetNamedSecurityInfoW failed (Win32 5)，shell 命令全部被拒 #8136、[Bug] Windows 非系统盘工作区在 workspace-write 下全部命令不可用：grantWrite 需要 WRITE_OWNER，而工作区目录默认没有 #7912、workspace-write sandbox fails entirely on Windows when the workspace grants no WRITE_OWNER (SetNamedSecurityInfoW error 5) #7816、[Bug] Windows：工作区位于非系统盘时 ACL 沙箱必然初始化失败（Win32 5 / grantWrite）/ ACL sandbox fails on non-system drives: the default ACL grants the caller no WRITE_OWNER #7804、[Windows] workspace-write 沙箱在数据盘工作区完全不可用：SetNamedSecurityInfoW failed (Win32 5) #7750、[Bug Report] Windows: workspace ACL with Modify-only (no WRITE_OWNER) makes the ACL sandbox fail at init, disabling all shell tools #7720、[Bug] Windows: after upgrading to 0.1.7-rc.1 every shell command fails at the ACL grant with `SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)` / 升级到 0.1.7 后所有 shell 命令在沙箱授权阶段立即失败（粘性，需手工修 ACL） #7646、[BUG REPORT] Windows 沙箱无法在用户自建目录上 provision 工作区 ACE → 该目录下所有 shell 命令失败 #7538、Windows: workspace-write sandbox fails with SetNamedSecurityInfoW Win32 5 when the workspace directory DACL lacks WRITE_OWNER #7504、0.1.7-alpha2 版本 Sandbox ACL failure失败需要审批次数太多了是什么原因呢 #7564（同一 SetNamedSecurityInfoW failed (Win32 5): grantWrite(...) 症状的中英文报告；# [Windows] 非系统盘工作区在 sandbox provisioning 阶段 fail-closed（Win32 5），且唯一官方修复手段与「避免 Low 完整性标签副作用」不可兼得 #8275 还指出「官方修复手段与避免 Low 标签副作用不可兼得」）
• 变体：[Bug/UX] Windows：工作区目录所有者为 BUILTIN\Administrators 时，workspace-write 下所有命令直接失败（grantWrite / SetNamedSecurityInfoW Win32 5） #7771（工作区属主为 BUILTIN\Administrators 时同样 Win32 5）
• 组合报告之一：[Bug][Windows] 0.1.7-rc.2: 窗口关闭死锁 / ACL沙箱权限崩溃(Win32 5) / 子代理卡片失踪与硬锁8并发 / SSRF误杀TUN代理 #8001

附带发现的重合

• 常驻 Low 标签 / 授权残留的副作用（印证本帖「曾作为工作区根的目录上永久残留常驻编辑」的观察）：[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 #8312（永久 Low 标签破坏项目内其他工具，多起报告仍未变）、[Bug] 工作区常驻 Low 完整性标签导致资源管理器把所有文件显示为"来自其他计算机"，且"解除锁定"显示找不到该文件必然失败，移动文件时警告"这些文件可能对你的计算机有害 你的Internet安全设置阻止打开一个或多个文件" #7915（资源管理器显示「来自其他计算机」、「解除锁定」必败）、Windows ACL 沙箱的 standing Low 完整性标签会使工作区内其他工具无法写入（Electron 构建静默退出） #7846、[Bug] Windows: the workspace Low integrity label also lowers the user's own launches from that tree, silently degrading the toolchain inside it #7709、[Bug] Windows：沙箱给工作区根目录盖 Low 完整性标签后，目录内的 .bat/.cmd/.exe 双击弹「无法验证发布者」 #7735、Issue with DSH 0.2.0 rc1 creating things in internet zone? #8175、[BugReport] [Windows] sandbox-windows-acl 的工作区 grant 会在授予期间给指向 pnpm store 的硬链接打上 Low 完整性标签，使该 store 里的可执行文件以 Low 完整性运行 #8314（grant 期间给指向 pnpm store 的硬链接打 Low 标签）。
• junction 边界：本帖未测 junction/reparse 子树；社区已有 [BUG] Workspace-write 沙箱缺陷：受限进程可通过工作区内的目录 Junction 删除工作区外文件 #7517（受限进程可经工作区内目录 Junction 删除工作区外文件）。
• read 工具读 asar 报 Cannot mix BigInt and other types：未检索到同款报告（[Bug] v2.0.6: skill-registry BigInt type error breaks all requests (REQUEST_EXTENSION failed) #6108 是 skill-registry 的 BigInt 类型错误，非同一问题），此条应属新反馈。

---

检索范围说明：Discussions 首页（按最近更新）+ 关键词检索（sandbox / 沙箱 / 子目录 / SetNamedSecurityInfoW / grantWrite / permission / denied / BigInt / icacls / ACL / WRITE_OWNER / workspace-write / asar / subdirectories / capability ACE / stale / re-validated / temp dir / 残留），每个关键词取前 ~25 条，可能有遗漏。

[argszero]

Thanks — this is the most complete report of the Windows ACL backend so far, and defect B in particular is a cell nobody had named. Three things to add, all of them read off origin/master rather than inferred, plus the plugin-shaped stopgap that already answers two of the three.

Defect B has a layer above the one you found

Your attribution is right about the symptom — the root persists and never self-heals until the desktop restarts — and it is one layer higher than the ACL module. The provisioning check that "reads the DACL" is not what is being skipped here; it is not reached at all:

• packages/sandbox/sandbox-local/src/index.ts:403-421, materializeAclGrant(): if (!this.workspaceGrants.has(workspaceRoot)) { … }. The standing root grant is materialized once per provider lifetime, and after that only this in-memory map is consulted — the DACL is never read again. The file's own comment at :359 says it: "workspace-root ACE materializes once per workspace per server lifetime … the exact-ACE skip makes every later provision O(1)".
• packages/sandbox/sandbox-windows-acl/src/grant.ts:22-31 calls those standing edits the "cross-session reuse cache".
• The control you ran is a source fact, not one path being more careful: windowsAclRunnerArgv() (sandbox-local/src/index.ts:365-380) passes no --write-sid/--temp-write-sid when there is no session (or the mode is read-only), which is exactly the case you reproduced with the direct runner.js invocation; sandbox-windows-acl/src/runner.ts:27-31 documents that without the pair the runner owns the DACLs, so it re-grantWrites on every spawn — and that path really does read the DACL, which is why it heals.
• Corollary, and it matches your observation: emptying the map is the whole recovery. Restarting the provider re-reads the DACL, finds the ACE absent and writes it again.

So "the cache is stale" is true but understates it — the cache is the only thing consulted, and it is keyed per provider lifetime rather than per ACL state.

Defect A's trigger is a DACL that does not inherit

Your fixture is the one worth keeping: icacls <dir> /inheritance:r. A subdirectory whose DACL is protected never receives the inherited capability ACE, and the backend's root-only idempotency check (hasExactGrant(workspaceRoot) + hasExactDeny() + hasExactLabel() all matching, acl.ts:386-388) returns early once the root is provisioned, so it is never revisited. Your matrix line "移入 (move-in) works because Windows propagates on the move" is the same fact from the other side, and it is why this reads as intermittent: what decides is who created the object and with which DACL, not where it sits.

What has shipped as a plugin

@argszero/cordis-plugin-sandbox-grant-advisor — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor — observes the public tools/post-execute waterfall, recognizes the denial from the executors' own stamp on the value (sandbox: { mode: "workspace-write", denied: true }, produced by matching the backend's refusal dialect in the captured stderr) and — for defects A/C's signature, SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>) — from the error text, and attaches one durable user-role advisory per agent through additionalContexts, so the model gets the diagnosis in the same step as the failure. It speaks only when the host is Windows, the stamped mode is workspace-write and every absolute path the command names lies inside the session's workspace; a denial outside it, under read-only, or from a failed runner is left alone. It never edits an ACL, never elevates and never offers danger-full-access. Mount it in the profile's patch layer:

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

Since 0.14.0 (published today) its fourth family forks on breadth into exactly your three shapes, and defect B is the third branch: a refused root is neither of the propagation halves, no command reaches it, and the recovery is the user's — restart the provider, which empties the map. Defect A is the DACL branch (with your /inheritance:r fixture now named as its realistic trigger), and defect C is the first family, whose remedy is the unelevated icacls <dir> /grant "$env:USERNAME:(OI)(CI)(WO)" with the ownership fork. No repair command is printed for the fourth family on purpose: this project has no Windows host to verify a line on, which is the same standard the standing-grant section is held to.

Defect C is the one the built-in diagnose-windows-sandbox-acl skill can actually repair, which is worth saying beside your read-tool bug: the skill is not part of the 0.1.7 line at all (it arrives with 0.2.0), so a reader told to reach for it on a 0.1.7-* install is reading a 0.2.0-era document.