[Bug] Windows 下，工作区连接后新增的子目录无法写入

[awmaure]

我在 Windows 上测试 Agent 工具时遇到一个比较稳定的问题。

把 D:\harness 连接为工作区并执行过一次工具后，如果其他本地进程再在工作区里创建子目录，Harness 后续无法在这个子目录中写文件。直接写工作区根目录正常，由 Agent 自己新建子目录再写文件也正常。

复现方式：

1. 把 D:\harness 连接为工作区，并执行一次工作区可写模式的工具。
2. 在 Harness 外部创建 D:\harness\late-child。
3. 新建一个 Harness session，执行：

Set-Content -LiteralPath "D:\harness\late-child\test.txt" -Value "TEST"

结果会提示：

[sandbox: file access denied under workspace-write mode]

同一个 session 写入 D:\harness\test.txt 可以成功。使用相对路径和绝对路径写入 late-child 都会失败。

我用 icacls 对比了一下：工作区根目录带有 Harness 的 workspace capability SID；外部后来创建的 late-child 没有；Agent 自己创建的子目录可以正常继承这个 SID。

我又看了 grantWrite 的实现。工作区根目录已经存在相同 ACE 时会跳过再次应用。所以我怀疑，首次授权传播完成后，外部新增且没有继承 capability SID 的子目录，在后续 session 中也不会被补上。

预期是工作区内后来创建的正常子目录，在后续工作区可写 session 中仍然可以写入。

这里是否需要在 workspace provision 时重新检查这类子目录，或者在其他层做一次 ACL 补齐？

测试环境：Windows，commit 47f943859bef60e4160492346772ded9b24f765a，Node v24.15.0，pnpm 11.19.0。

可能和 #81 有关，但我还不能确定是不是同一个原因。

[Electricitysheep]

这个 Windows 路径问题我们也踩过。dsh 的 workspace 路径处理在 Windows 上确实是重灾区- 含中文/特殊字符路径会触发 0x00 截断和 ENOENT（官方讨论区 #151/#396 也有类似反馈），我们把这类坑整理进了手册第 12 章「已知不足与边界」：

https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/12-limitations.md

临时 workaround 建议（按优先级）：

1. 工作区路径用纯英文（D:/harness 已经是英文了，可以试下换一个不含空格/特殊字符的目录名）
2. 检查是否为权限沙箱问题 - 先临时把 profile 的 sandbox/权限配置放宽测试定位（如果是 sandbox 规则拦截，看日志里有没有 permission denied 之外的提示）
3. 加 debug 日志确认是解析阶段还是写入阶段挂的

如果方便，把完整报错日志贴出来，我们手册第 8 章（工具与上下文/安全模型）的排查思路也许能帮上。

[awmaure]

感谢。我重新回读了两次原始 Session 的工具记录。这个复现和 #151/#396 应该不是同一类：工作区是纯英文路径 D:\harness，没有出现 0x00 截断或 ENOENT，实际返回的是 workspace-write 的访问拒绝。

两次失败都没有重试或升级权限，完整报错如下：

相对路径写入外部新增子目录

工作目录：D:\harness

Set-Content -LiteralPath ".\dsh-torture-fixture\state\relative-nested.txt" -Value "RELATIVE_NESTED" -Encoding utf8

退出码 1

[stderr]
Set-Content: Access to the path 'D:\harness\dsh-torture-fixture\state\relative-nested.txt' is denied.
[sandbox: file access denied under workspace-write mode]
[sandbox: escalation available — retry this exact command once with sandbox_permissions (the narrowest wider mode that suffices) + justification; the approval prompt asks the user]

绝对路径写入同一个外部新增子目录

工作目录：D:\harness

Set-Content -LiteralPath "D:\harness\dsh-torture-fixture\state\absolute-nested.txt" -Value "ABSOLUTE_NESTED" -Encoding utf8

退出码 1

[stderr]
Set-Content: Access to the path 'D:\harness\dsh-torture-fixture\state\absolute-nested.txt' is denied.
[sandbox: file access denied under workspace-write mode]
[sandbox: escalation available — retry this exact command once with sandbox_permissions (the narrowest wider mode that suffices) + justification; the approval prompt asks the user]

同一轮里的根目录控制组可以写入：

Set-Content -LiteralPath "D:\harness\absolute-root.txt" -Value "ABSOLUTE_ROOT" -Encoding utf8

(no output)

另一个新 Session 由 Agent 自己创建子目录再写入也成功：

New-Item -ItemType Directory -Path ".\agent-created-child" -Force | Out-Null; Set-Content -LiteralPath ".\agent-created-child\inside.txt" -Value "AGENT_CREATED_CHILD" -Encoding utf8

(no output)

我又做了一次只读 ACL 对照，结果仍然一致：

D:\harness
  S-1-4-993433741-300855501:(OI)(CI)(W,D,DC)

D:\harness\dsh-torture-fixture
  没有 S-1-4-993433741-300855501

D:\harness\agent-created-child
  S-1-4-993433741-300855501:(I)(OI)(CI)(W,D,DC)

因此我目前仍倾向于把它看成工作区授权完成后，外部新增子目录没有补到 capability SID 的问题，而不是 Windows 路径解码问题。放宽 sandbox 可以绕过拒绝，但会改变这里要验证的 workspace-write 条件。

[DRAG0NM]

感谢这组完整的对照数据——它与 #423 的根因完全吻合：工作区授权是一次性 standing ACE（exact-ACE 跳过规则使授权不重播），授权之后外部新增的子目录没有 capability SID，也不会被补授。torture-fixture（无 SID → 拒绝）与 agent-created-child（OI/CI 继承 → 可写）的对照正是该机制的直接证据；纯英文路径复现也排除了中文截断家族，把问题锁定在 ACL 补授路径。感谢复核。

[DRAG0NM]

已发布完整根因报告：grantWrite 的 exact-ACE skip 使 workspace capability ACE 一次性生效，之后外部创建/移入的子目录（Windows 移动保留源 DACL）永远不会被补授。rc.6 发布包实测复现（icacls 对照 + 受限写入拒绝 + 补授恢复）、源码定位与修复建议（provision 时增量补授）见 #423 。