[Windows] Host process exits on uncaughtException (ENOENT) when the subprocess spill dir is deleted at runtime

[Dely0]

Summary

On Windows, if the per-process spill directory %TEMP%\dsh-subprocess-<random> is deleted while DSH is running (Windows Storage Sense does exactly this on a schedule via "Delete temporary files that my apps aren't using"), the next tool call whose output exceeds the in-memory cap kills the whole DSH host process:

• dsh-subprocess-local caches the spill directory path for the process lifetime — privateSpillDir() does defaultSpillDir ??= mkdtempSync(join(tmpdir(), "dsh-subprocess-")) (lib/index.js:648-651) and never recreates it.
• OutputCollector.spillAll() then calls openSync(this.spillFile, "wx", 384) (lib/index.js:716-717).
• With the directory gone, openSync throws ENOENT inside a stream 'data' handler (Socket.<anonymous>, lib/index.js:862), so it becomes an uncaught exception and the process exits with code 1.

To users it looks "random" because two conditions must coincide: the temp dir was swept and the current command's output is large enough to trigger spilling.

Environment

• @deepseek-ai/dsh 0.1.2-rc.1 (npm global, dsh web)
• Node.js v24.15.0
• Windows 10 Pro 22H2 (build 19045, x64)
• Tool: pwsh (Windows shell tool); any subprocess whose output spills shows the same failure

Stack trace (captured by an uncaughtException handler)

Error: ENOENT: no such file or directory, open 'C:\Users\<user>\AppData\Local\Temp\dsh-subprocess-EXGmcS\dsh-subprocess-13524-7-f2a0801cf513-stdout.log'
    at openSync (node:fs:561:18)
    at OutputCollector.spillAll (.../@deepseek-ai/dsh-subprocess-local/lib/index.js:717:19)
    at OutputCollector.push (.../@deepseek-ai/dsh-subprocess-local/lib/index.js:693:75)
    at Socket.<anonymous> (.../@deepseek-ai/dsh-subprocess-local/lib/index.js:862: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/stream_base_commons:189:23)

5 occurrences in 3 days, every one during a pwsh call with large output:

time (local)	command	spilled path
09-02 18:55:36	Invoke-WebRequest loop	...\Temp\dsh-subprocess-Pegvq0\...-148-2-....log
09-07 18:29:55	npm pack --ignore-scripts	...\Temp\dsh-subprocess-o9xYfd\...-2384-13-....log
09-08 09:35:25	Invoke-WebRequest loop	...\Temp\dsh-subprocess-ne7pjE\...-23568-2-....log
09-08 17:39:50	dotnet build Ant_XYXH.csproj	...\Temp\dsh-subprocess-Pprds5\...-14384-2-....log
09-08 18:36:31	dotnet build LS_LSJSX.Common.csproj	...\Temp\dsh-subprocess-EXGmcS\...-13524-7-....log

Corroborating signals:

• %LOCALAPPDATA%\Temp only ever holds the current process's dsh-subprocess-* directory; all older ones are gone — something sweeps them.
• Storage Sense is enabled on the machine (HKCU\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy: 01=1, 04=1). Its scheduled task ran at 16:48:48; the 17:39:50 crash followed ~51 minutes later.

Deterministic repro

1. Start DSH on Windows with the default temp dir.
2. Run a pwsh command whose output overflows the in-memory cap, so %TEMP%\dsh-subprocess-XXXXXX exists.
3. Delete that directory while DSH keeps running (Remove-Item -Recurse $env:TEMP\dsh-subprocess-*), or let Storage Sense do it.
4. Run another large-output pwsh command → DSH exits with code 1 and the ENOENT above.

Impact

The whole host dies mid-session: no tool error, no partial result, in-flight work is lost (any running session/agent dies with it). Users experience it as "DSH randomly crashes when using the shell tool".

Suggested fix (any one of these prevents the crash)

1. Recreate on demand: mkdirSync(dirname(this.spillFile), { recursive: true }) before openSync, or catch ENOENT and recreate the directory + retry once.
2. Do not cache forever: validate the spill directory (recreate if missing) instead of assuming it survives the process lifetime.
3. Degrade instead of dying: wrap the spill write in try/catch so a spill failure disables spilling (truncated output) rather than throwing out of a stream data handler.
4. Pick a less volatile default location: on Windows os.tmpdir() is routinely swept by Storage Sense / Disk Cleanup; a directory under the DSH home would be safer.

Workaround we applied locally

• Point the DSH process's TEMP/TMP at a dedicated directory (%USERPROFILE%\.dsh\tmp) in the launcher. Verified that os.tmpdir() then resolves there (libuv on Windows reads TEMP, not TMPDIR), so the spill dir lives outside the swept %LOCALAPPDATA%\Temp.
• Turn off Storage Sense's "Delete temporary files that my apps aren't using" (StoragePolicy value 04 = 0).

---

中文摘要：Windows 上若 %TEMP%\dsh-subprocess-*（子进程输出溢出目录）在 DSH 运行期间被删除（Windows 存储感知会定期清理「应用不使用的临时文件」），下一次大输出命令会在 OutputCollector.spillAll 的 openSync 抛 ENOENT，而该异常发生在 stream data 回调中，直接导致未捕获异常、整个 DSH 进程退出（code 1）。建议在 openSync 前递归重建目录，或把溢出写失败降级为「输出截断」而不是抛异常；另建议 Windows 下不要把溢出目录放在系统临时目录。

[RYun601]

补充确认：0.1.5-rc.2 仍可复现

环境：

• Windows 25H2，版本号 26200.9445，x64
• Node.js v24.18.0
• @deepseek-ai/dsh-subprocess-local@0.1.5-rc.2

使用隔离临时目录测试：删除该目录后触发大输出，两次测试均导致 Node.js 进程以退出码 1 终止。

Error: ENOENT: no such file or directory
    at OutputCollector.spillAll (...:766:19)
    at OutputCollector.push (...:742:75)
    at Socket.<anonymous> (...:981:14)