Windows：ACL 诊断/修复技能会奖励「模型不用 DSH 文件工具、改用命令行」的错误路径，在沙箱正常拒绝时触发主动提权与自制工具

[murphy-work]

摘要

在 Windows 上，模型本来就更倾向于用 Bash/PowerShell 工具去列目录、找文件，而不是用 DSH 自带的 glob/read/grep。这不是 ACL 技能引起的，但自 v0.2.0-rc.1 引入、并在 v0.2.1-alpha.2 合并为「一次调用同时诊断并修复」的 diagnose-windows-sandbox-acl 技能，会把这条错误路径的后果进一步放大：

当模型用命令行做本该由 DSH 文件工具完成的事、并被沙箱正常拒绝时，技能目录里常驻的 ACL 诊断技能会让模型把「预期内的拒绝」误判成「需要修复的环境故障」，进而

1. 主动发起提权申请（把命令升级到 full access / danger-full-access），或
2. 开始自制工具——写探针文件、写诊断脚本、构造辅助命令来「排查环境」。

而正确的行为本应是：改用 DSH 文件工具，或把预期拒绝直接解释给用户。结果是模型既没有回到 DSH 工具，又额外动了文件系统和权限。

影响

• 用户被无意义地要求扩大系统权限；一旦误点「通过」，模型获得了远大于任务所需的权限。
• 工作区被留下探针文件、诊断脚本、报告目录等任务无关产物。
• 沙箱的失败提示（denial 反馈）从「教会模型用对工具」退化成「教模型去做权限工程」。
• 对 workspace-write 下最普通的越界写入拒绝（本应直接解释）尤其容易误触发。

复现路径

环境：Windows + 内置 Windows runner（未配置 runnerCommand），文件策略 workspace-write。

1. 用户的输入完全不涉及任务（例如只发一句打招呼）。
2. 模型先用命令行工具列目录，例如 Get-ChildItem -Force，而不是 glob。
3. 该命令行被沙箱拒绝；在 Windows 上这类失败会以工具层错误形式返回。
4. 模型看到拒绝，并从常驻技能目录里发现 diagnose-windows-sandbox-acl。
5. 模型阅读技能、决定「需要修复权限」，于是申请把该命令升级为不受限执行；被拒绝后可能改为写探针文件、编写诊断脚本来自证环境有问题。
6. 全程没有回到 glob/read/grep——而它们本来可以正常完成同一件事。

关键点：第 2 步就是错的（DSH 提示词本就要求用文件工具而非 shell），而技能的存在让第 3 步之后的走向从「改正」变成了「升级权限 + 造工具」。

触发机制（源码定位）

• 技能随包发布，并由 sandbox-local 在内置 Windows runner 下自动注册为常驻技能目录条目：
  packages/sandbox/sandbox-local/src/index.ts 第 301–303 行

  if (process.platform === 'win32' && this.runnerCommand === undefined) {
    ctx.inject(['skills'], (skillsCtx) => { registerAclDiagnosisSkill(skillsCtx) })
  }

• 注册实现：packages/sandbox/sandbox-windows-acl/src/acl-skill.ts（提取 SKILL.md 与脚本到临时目录，modelInvocable: true, userInvocable: true）。
• 技能正文：packages/sandbox/sandbox-windows-acl/assets/diagnose-windows-sandbox-acl/SKILL.md。

也就是说，只要有内置 Windows runner，这个技能就始终出现在技能目录里，与是否真的发生故障无关。

版本证据

版本	情况
dsh-v0.1.6-alpha.2	不存在该技能。同一路径 packages/sandbox/sandbox-windows-acl/assets/diagnose-windows-sandbox-acl/SKILL.md 返回 404
dsh-v0.2.0-rc.1	技能首次出现（发布说明原文：「Windows 内置沙箱新增权限诊断技能……」；该说明声明汇总自 v0.1.7-rc.2 以来的变更）。此时是分步流程：先纯诊断拿到 CULPRIT/PRECONDITION/BOTH 判定，再单独用 -Fix 或 -GrantFullControl 发起第二次修复
dsh-v0.2.1-alpha.2（当前）	已合并为一次授权调用同时完成诊断与修复，脚本不再有模式开关。发布说明原文：「合并 Windows 沙箱权限诊断与修复为一次授权运行，保留修改前备份和恢复命令」

这个合并是放大效应的重要一步：分步设计下，模型至少要先做一次不改任何东西的纯诊断；合并后，一次调用就直接走到「改权限」，从「看到拒绝」到「申请提权」之间少了一道天然缓冲。

建议

1. 优先修工具选择而不是修 ACL：这条链路真正的起点是模型不用 glob/read/grep。如果能在工具层强化或强制这一点，整条放大链会自动消失。
2. 让技能对「预期拒绝」不可见或不可用：例如当拒绝原因属于「工作区外写入 / read-only 下写入」这类预期类别时，不向模型展示该技能，或在工具结果里直接标注「这是预期拒绝，不要修复」。技能正文其实已经写了这条（Expected confinement denials need no ACL repair），但它依赖模型先正确分类——而这恰是失败的一环。
3. 在技能里显式禁止用命令行做文件工具能做的事：明确要求「若失败命令属于 glob/read/grep 可替代的操作，先改用该工具，不得因此申请提权或创建诊断脚本/探针文件」。
4. 提权申请前置门槛：当拒绝可通过更换工具解决时，不允许发起提权；或在申请文案里强制区分「工具用错」与「环境故障」。
5. 可选：把该技能改为非默认注册，由用户在真的遇到不可解释的拒绝时再启用。

补充：实例记录

以下记录来自一次真实会话，已做匿名化（不涉及用户内容）：

1. 用户只发送了一句问候。
2. 为了「列个目录」执行 Get-ChildItem -Force（DSH 提示词明确要求此类操作用 glob，此处是错误）。
3. 该命令返回工作区授权失败错误。
4. 把这个失败当成「环境故障」，调用 skill 加载 diagnose-windows-sandbox-acl。
5. 三次申请把权限修复脚本升级为不受限执行（前两次因系统禁止运行 .ps1、缺少 pwsh 而未真正执行，第三次被用户拒绝）。
6. 期间用写入操作创建了探针文件用于验证写入可用性，在你磁盘上留下了任务无关产物。
7. 全程没有改用 glob+read；而它们本可以完成同样的事，且不会触发任何权限问题。

需要说明的是：第 2 步是判断失误，技能本身并不「命令」做这些。但要强调的是——技能的存在把一次本可即时纠正的小失误，导向了提权申请与文件系统改动。如果没有这个常驻技能，在第 3 步最自然的反应就是换用 DSH 文件工具。

[MalikAhed]

The safest fix is to make the tool-choice boundary explicit before changing ACLs. A normal workspace-write denial for an out-of-workspace path or a read-only target is an expected confinement result, not evidence that the Windows ACL is broken.

I would change the flow in three places:

1. Have the file tool layer return a stable reason such as EXPECTED_CONFINEMENT_DENIAL, including the requested path and policy, but no repair hint.
2. Gate diagnose-windows-sandbox-acl on a separate signal that the denial is unexpected (for example, a permitted in-workspace operation failing, SetNamedSecurityInfoW failing on a path that should be writable, or a reproducible failure across the native file tools). For an expected denial, the skill should be unavailable and the model response should recommend glob/read/grep or asking the user to move the file.
3. Keep diagnosis and repair separate. A diagnostic run may collect evidence, but any ACL mutation or full-access request should require an explicit user action and a clear backup/restore path. Add a regression test covering the exact Get-ChildItem → denial → no elevation/no probe-file path, plus a real ACL-failure fixture that still exposes the diagnostic skill.

This preserves the useful repair workflow for genuine host failures while preventing a tool-selection mistake from escalating privileges or leaving probe files. If this matches the intended behavior, could you please click GitHub’s Mark as answer on this reply?

[argszero]

Source-verified follow-up on the mechanism, and a precise answer to which of your five suggestions a plugin can actually reach.

Your citations hold at HEAD, checked line by line.

• The automatic registration is packages/sandbox/sandbox-local/src/index.ts:301-303: if (process.platform === 'win32' && this.runnerCommand === undefined) { ctx.inject(['skills'], (skillsCtx) => { registerAclDiagnosisSkill(skillsCtx) }) }. The gate is the platform plus the absence of an operator runnerCommand — never whether anything is actually broken.
• The candidate is built in packages/sandbox/sandbox-windows-acl/src/acl-skill.ts as a bundled SkillProvider (modelInvocable: true, userInvocable: true, source: 'bundled'), whose resources are copied from assets/diagnose-windows-sandbox-acl/ into a per-fiber temporary directory on activation.
• At HEAD the script has no modes — the SKILL.md text says so verbatim ("The script has no modes"), so the v0.2.1-alpha.2 merge you describe is the current shape.

The text already draws the line you are asking for; the problem is where it asks the model to draw it. The frontmatter description ends with "Expected confinement denials need no ACL repair", and the "Run it" section enumerates the expected categories: "writes outside the workspace, any write in read-only, piped grandchild spawn EPERM, ConstrainedLanguage errors". So your suggestion 3 is already implemented in the asset. What remains is that the classification is delegated to the model at the moment it is least equipped to make it — immediately after a denial, with a repair skill sitting permanently in the catalog. Your framing is the right one: the skill amplifies a pre-existing tool-selection error rather than causing it, and it is why I would not try to fix this by editing the skill text further.

Which of your suggestions a plugin can reach (against the actual seams).

• 2 and 5 — make the skill invisible, or non-default — core-side, not plugin-reachable. The skills service declares exactly one event, skills/change, and it is @mode emit: an unfiltered invalidation notification with no veto. Registration is additive; registerProvider() / register() return a disposer for your own contribution only. There is no waterfall through which a plugin could filter, demote or withdraw another provider's candidate, and the "register only when something is actually broken" decision lives at sandbox-local/src/index.ts:301.
• 4 — a gate in front of an escalation request — plugin-reachable: tools/pre-execute is a waterfall whose deny short-circuits dispatch.
• the tool-result half of 2 — telling the model, at the point of denial, that this denial is expected — plugin-reachable: tools/post-execute may replace the result content or attach ordered contexts to it. This is not theoretical: our published sandbox-grant-advisor rides that same seam for the opposite polarity. It speaks only when a denial matches a genuine breakage signature (a provisioning failure, a denial for a path inside the workspace root, the temp-root invariant, the CIM access code) and deliberately says nothing about ordinary expected denials. The two would not overlap: that package answers "your sandbox is really broken, and here is which way"; the missing one answers "your sandbox is working, do not repair it".
• 1 — make the model prefer the file tools — is prompt/tool-surface territory, core-side.

Where I would place the boundary inside such a plugin. The denial is the decision point, so an advisory attached to the denial result is the natural place — but I would keep it an annotation and not suppress the escalation affordance, because an out-of-workspace read is precisely what escalation exists for. What must not happen is a repair run or a probe file. So the notice would carry the triage in order: this is a confinement policy result under mode X and not evidence that the host is broken; if glob/read/grep can do this, use them; if the path is outside the workspace, the one-shot escalation retry with the user's approval is the sanctioned path and is not a repair; ACL diagnosis belongs only to the case where an operation inside the workspace is also denied.

If that ordering matches your intent, I will build it and test it against one of your anonymized transcripts — the report's step-by-step record is exactly the fixture such a plugin needs.

[MalikAhed]

The source check strengthens the boundary: the bundled skill is registered from sandbox-local on Windows regardless of whether the denial is expected, so the cleanest fix is still classification at the denial result plus a tools/pre-execute gate before any escalation. That preserves the plugin-reachable path while leaving registration and candidate visibility to core. The proposed fixture should therefore assert both outcomes: expected out-of-workspace denial produces guidance only, while an in-workspace ACL failure exposes the diagnostic path. If the original answer matches the maintainer’s intended behavior, please mark it as answered.

[MalikAhed]

Thanks for checking the current source and confirming the exact registration and plugin seams. That supports the proposed split: classify expected confinement denials in the tool result, gate escalation before dispatch, and reserve ACL diagnosis for a reproducible in-workspace failure. The two regression fixtures you described should preserve that distinction. If this gives the maintainer the needed direction, please mark the original answer as answered.