windows-acl 沙箱临时目录被外部清理后不会自动重建，沙箱命令持续报错

[MMiao79]

我没有找到正式的Bug提交位置，如果写在这里不对，还请谅解，谢谢！

windows-acl 沙箱临时目录被外部清理后不会自动重建，沙箱命令持续报错，直到重启服务进程。

复现、预期与验收

• 复现步骤：
  1. Windows 上从源码启动 dsh（pnpm install + pnpm run build + dsh web），进入任意会话
  2. 触发一次 workspace-write 沙箱命令（例如 pwsh 工具调用），确认 %TEMP% 下已生成 dsh-<6 位随机字符> 目录
  3. 外部删除该目录（Remove-Item -Recurse -Force，或磁盘清理工具）
  4. 再次触发沙箱命令
• 实际结果：命令失败，错误为 windows-acl-run: --temp is not an existing directory: C:\Users\???\AppData\Local\Temp\dsh-qM9mIf；沙箱 fail-closed（拒绝非受限运行），服务进程存活期间所有沙箱命令不可用，只能重启恢复
• 预期结果：临时目录被外部清理后，下一次调用自动重建（或每次调用使用新的随机目录），沙箱命令不受影响
• 环境：Windows 10 Pro 19041（x64）；Node.js v25.2.1；dsh 0.1.0-rc.7 源码运行
• 验收条件：删除 %TEMP%\dsh-* 后，下一次沙箱调用自动恢复（目录重建且命令成功），无需重启服务

根因分析

1. packages/sandbox/sandbox-local/src/index.ts 的 materializeAclGrant() 为每个 (sessionId, workspaceRoot) 组合用 mkdtempSync(join(tmpdir(), 'dsh-')) 创建临时目录，并缓存复用（this.tempCapabilities），仅在 provider dispose 时删除；没有任何「目录缺失则重建」的逻辑。
2. packages/sandbox/sandbox-windows-acl/src/runner.ts:109-113 的 requireDirectory() 每次调用校验 --temp 必须存在，否则 fail(...)（错误前缀 windows-acl-run: ）并以 127 退出（WINDOWS_ACL_RUNNER_FAILURE_EXIT，sandbox-local/src/index.ts:216）。
3. %TEMP% 是常规清理目标（磁盘清理、手动清理、第三方软件），固定名目录被删后即触发上述失败链。

建议修复（已本地应用并通过 tsc 构建）

在缓存命中分支补一个存在性检查与重建。安全性：runner 每次调用都会重新授予 temp SID 写权限（grantWrite），因此重建空目录是安全的、无需重新授权；路径随机且无敏感内容，无安全影响。

// packages/sandbox/sandbox-local/src/index.ts
const existing = this.tempCapabilities.get(key)
if (existing !== undefined) {
  // OS temp hygiene or manual cleanup can remove the materialized
  // directory between calls; recreate it so the runner's --temp
  // validation still passes (the runner re-grants the temp SID).
  if (!existsSync(existing.dir)) mkdirSync(existing.dir, { recursive: true })
  return existing
}

备选方案：

• runner 侧把「必须存在」改为「不存在则创建」（runner 有权限创建，但会弱化「provider 传参错误必须在边界大声失败」的现有设计意图，见 runner.ts:117-118 注释）
• 每次调用新建随机临时目录（更彻底，但改变 revocable-temp 能力的复用语义，需同步调整 grant 生命周期）

影响面与次生症状

• 影响面：Windows 平台沙箱（windows-acl runner 专属）；源码运行时服务进程内的模块缓存导致修复需重启进程生效
• 次生症状：沙箱子进程内 spill-local 会在该目录下创建 dsh-spill-* 子目录（spill-local 的私有根），父目录缺失时同样失败（本次排查中曾观察到隐藏服务器崩溃）；主目录修复后一并恢复
• 状态：已在本地应用修复并通过 tsc 构建（修复进入 lib/index.js）；因 Node 模块缓存，需重启服务进程后做端到端验证

最后说明：问题是我在使用过程碰到的，写修复建议和方案的是DeepSeek-Harness以及DeepSeek-V4-Flash(High)这两位，也算是原汤化原食了！

[argszero]

源码验证过（rc.7 99f6f02fec）——你的根因分析完全准确，补丁落点也正确。并且这不是孤立问题：#3190 是同族第二报（外部清理 %TEMP% 破坏运行中的 dsh），两报合起来值得按一个家族处理。

1. 机制确认。 materializeAclGrant（packages/sandbox/sandbox-local/src/index.ts:392-443）：:413 缓存命中直接返回（无存在性检查）；:415 mkdtempSync 只创建一次；tempCapabilities 缓存到 dispose（:464）才清。requireDirectory（sandbox-windows-acl/src/runner.ts:109-113）每次校验 --temp 必须存在。外部删除 → 缓存命中返回不存在的目录 → runner fail-loud → 服务存活期间全沙箱命令 fail-closed。全链属实。

2. 补丁落点判断：provider 侧重建是对的，别改 runner 侧。 runner.ts:118-119 的注释是设计意图："provider 传错根目录必须在 runner 边界大声失败"——这是有意为之的边界校验。若改成 runner 侧"不存在则创建"，会弱化这个边界（provider 传了错路径却被静默"修复"）。你的补丁（缓存命中分支加 existsSync + mkdirSync recursive 重建）正好把修复放在 provider 侧，保留 runner 的 fail-loud 语义——正确。补充一点：重建后无需重新授权（你已指出 runner 每次调用重新 grantWrite temp SID），且新目录继承原 grant 路径——安全。

3. 家族：#3190 + #3203 = "外部 OS 临时目录清理破坏运行中 dsh" 两报，两个子系统：

• [Bug] dsh web crashes with ENOENT when external temp cleanup removes the subprocess spill dir #3190（Windows 11，dsh-subprocess-local）：子进程 spill 目录被外部清理 → spillAll（packages/subprocess/subprocess-local/src/spawn.ts:156）写 stdout.log 时 ENOENT 未捕获 → 整个 dsh web 崩溃（比你的 fail-closed 更严重，是进程级可用性事故）；
• windows-acl 沙箱临时目录被外部清理后不会自动重建，沙箱命令持续报错 #3203（你，Windows 10，windows-acl 沙箱）：沙箱临时授权目录被清理 → 沙箱命令 fail-closed 直到重启。

共同根：运行期持有的进程私有临时目录对外部清理无防护。Windows 磁盘清理/第三方清理工具是常见触发源。修复模式应该统一为"在目录被消费的边界处遇缺失即重建"——你的补丁就是沙箱侧的实例；#3190 侧 spillAll 应在 ENOENT 时重建 spill 目录（或捕获降级），而不是让未捕获异常炸掉整个进程。

4. 通用加固建议（家族级）：这两个子系统之外，任何 mkdtempSync/私有 %TEMP% 子目录的长期持有者都有同类风险——可考虑在 dsh-doctor 加一条 Windows 运行时检查（列出 %TEMP%\dsh-* / dsh-subprocess-* 的持有者与缺失状态），或至少把"外部清理后自愈"写进沙箱/子进程模块的契约。你的验收条件（删除后下一次调用自动恢复、无需重启）应该就是这个家族的验收标准。

两报都带完整复现 + 根因 + 修复草案，质量很高。#3190 值得从这边链接过去（同族），若你愿意也可以顺手在 #3190 贴你的补丁模式作为参考。

[MMiao79]

谢谢回复，在 #3190 贴补丁为参考我没啥问题，只要不显得多余就好（已贴）。