[Bug] dsh web crashes with ENOENT when external temp cleanup removes the subprocess spill dir

[changingwang]

@{title=[Bug] dsh web crashes with ENOENT when OS temp cleanup removes the subprocess spill dir (Windows); body=## Summary

dsh web crashes with an uncaught ENOENT when the OS (or any external tool) cleans %TEMP% while dsh is running. The private per-process spill directory created by dsh-subprocess-local disappears mid-run, so the next stdout write from a spawned subprocess fails hard and takes down the whole harness.

This is on Windows 11 24H2, node v24.18.1, dsh 0.1.0-rc.7.

Crash stack

node:fs:561
  return binding.open(
                 ^

Error: ENOENT: no such file or directory, open 'C:\Users\ROG\AppData\Local\Temp\dsh-subprocess-9NfESN\dsh-subprocess-24456-1-479a1218f020-stdout.log'
    at openSync (node:fs:561:18)
    at OutputCollector.spillAll (file:///D:/nvm/v24.18.1/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:417:19)
    at OutputCollector.push (file:///D:/nvm/v24.18.1/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:393:75)
    at Socket.<anonymous> (file:///D:/nvm/v24.18.1/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:562:14)
    at Socket.emit (node:events:509:28)
    at addChunk (node:internal/streams/readable:563:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:514:3)
    at Readable.push (node:internal/streams/readable:394:5)
    at Pipe.onStreamRead (node:internal/streams/base_commons:189:23)

Root cause analysis

1. privateSpillDir() (dsh-subprocess-local lib/index.js:348-350) lazily creates one mkdtempSync directory per dsh process under the OS tmpdir: %TEMP%\dsh-subprocess-XXXXXX.
2. OutputCollector.spillAll() (:417) calls openSync(..., 'wx') to append a spawned subprocess's stdout/stderr once the in-memory cap overflows.
3. The README explicitly states these directories are never deleted by the package: "Completed spill files are not deleted — bounded full-output recovery files (and the private per-process spill dir) accumulate under the OS tmpdir until something external cleans them."
4. If anything external (Windows Storage Sense, Disk Cleanup, CCleaner, or a user) deletes %TEMP%\dsh-subprocess-* while dsh is still running, the next openSync throws ENOENT and it is uncaught → the whole dsh process crashes. The session log is cleanly truncated mid tool-call; there is no error event written anywhere.

Repro steps

1. Start dsh web (any profile that spawns subprocesses / bash tools).
2. While it runs, delete the active %TEMP%\dsh-subprocess-* directory belonging to that process.
3. Ask the model to run any shell/tool command → crash with ENOENT.

Suggested fix

Make the spill path resilient to directory loss, e.g.:

• Wrap the spill openSync/writeSync in try/catch and lazily re-create the per-process dir on failure (fs.mkdirSync(dir, { recursive: true })), or
• Catch ENOENT in spillAll and degrade to in-memory tail (mark spillDisabled) instead of crashing, or
• Clean the spill directory on a graceful exit so long-running installs don't accumulate, and tolerate a missing dir as a no-op.

Happy to provide more detail or test a patch.; category_ids=System.Object[]}.body

[zoahdev]

对照当前 main HEAD 99f6f02 核验，你的行号与根因全部成立：

• packages/subprocess/subprocess-local/src/spawn.ts:89-92 — privateSpillDir() 懒创建并缓存在模块级 defaultSpillDir；
• spillAll()（156-173）在首次溢出时 openSync(..., 'wx', 0o600)（169 行），目录被外部删除后必然 ENOENT；
• push()（131-153）对 spillAll 调用没有任何 try/catch，异常沿 socket data 处理器一路冒到 uncaught —— 和你的堆栈完全对上。

补充三点：

1. 仓库里已经有现成的降级模式，建议复用而不是新造

spillDisabled 标志 + discardSpill()（176-197）已经存在，且它对 closeSync/unlinkSync 的失败是容忍的（catch 后保留/忽略）。最小补丁可以只在 push() 里包一层：

if (!this.spillDisabled && (overflows || this.spillFd !== undefined)) {
  try { this.spillAll(chunk) } catch (error) {
    if (error?.code === 'ENOENT' || error?.code === 'EPERM') {
      this.spillDisabled = true // degrade to in-memory tail, keep the harness alive
      // log once
    } else throw error
  }
}

这对应你建议里的方案 2，改动面最小；spillDisabled 之后 spillAll 不再被调用，语义与 maxSpillBytes 超限后的路径完全一致。如果还想保留 spill 能力，可以再 mkdirSync(this.spillDir, { recursive: true, mode: 0o700 }) 重试一次，但不要用 mkdtempSync 换新目录——换目录会让已创建但未溢出的子进程失去引用路径，反而不一致。

2. 崩溃点不止 openSync

writeSync（172 行）在 fd 已打开的情况下同样会抛。Windows 上删除打开中的文件通常会失败（所以报告里的堆栈停在 openSync），但 POSIX 上 unlink 后 fd 仍有效、writeSync 正常——真正的跨平台场景是：目录被删后新子进程首次溢出时 openSync 抛（Windows 与 Linux 都会）。所以 try/catch 包住整个 spillAll 调用（而不只是 openSync）是对的。

3. 回归测试建议

tests/spawn.spec.ts 已有 ENOENT 相关用例（78 行附近），建议扩展一条：收集器开始接收后删除 spill 目录，再 push 超过内存上限的数据，断言不抛异常且内存 tail 仍被保留、lossy 读取正常。这样"外部清理者中途删目录"这个场景就有测试钉住，而不是靠 README 的"不清除"约定。

另外你的方案 3（退出时清理）不解决中途删除问题，作为补充可以但别当主修复——README 明确设计为"完成即保留、由外部清理"，所以对目录消失的容错才是正解。

[MMiao79]

类似情况的另一种参考：

建议修复（已本地应用并通过 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 生命周期）