workspace-changes leaks its per-session scratch dir in TEMP when dispose() never runs (60 GB observed)

[liceses]

Summary

@deepseek-ai/dsh-workspace-changes creates one mkdtemp scratch directory per Session under the system temp root. dispose() removes it, but when a session ends without reaching dispose() (crash, force-quit, kill, update/restart) the directory is left behind forever, and nothing sweeps orphans on the next start.

On this machine it has accumulated to 60.45 GB across 131 orphan directories / 302,971 files, out of a 168 GB %TEMP%.

Environment

• OS: Windows 11 (x64)
• dsh: 0.1.7-rc.2 (desktop + CLI)
• package: @deepseek-ai/dsh-workspace-changes@0.1.7-rc.2
• install: C:\Users\ROG\AppData\Roaming\npm\node_modules\@deepseek-ai\dsh

Evidence

Read-only inventory of %TEMP% (168.68 GB / 748,655 files total):

bucket	size	dirs	files
dsh-workspace-changes-*	60.45 GB	131	302,971
browser automation profiles (my own test scripts, not dsh)	82.89 GB	803	347,420
misc	12.87 GB	1,490	96,174
other tools	12.47 GB	4	2,090

dsh-workspace-changes-* specifics:

• 131 directories, oldest 2026-09-29 20:31, newest 2026-10-20 00:12
• per-directory 1.1 – 6.8 GB, up to 14,901 files each
• layout: <scratch>/objects/… and, for non-git workspaces, <scratch>/captures/…

Root cause (code references)

packages/deliverables/workspace-changes, lib/index.js:

• :808 — this.scratch ??= mkdtemp(join(this.env.tempRoot, "dsh-workspace-changes-"))
• :639 — doc comment: "Temporary directory holding this Session's snapshot objects, scratch indexes, and captured copies."
• :781 — async dispose() { this.lifetime.abort(); this.records.clear(); await this.chain; if (this.scratch !== void 0) await rm(await this.scratch, { recursive: true, force: true }); }

So the lifetime is exactly "until dispose() runs". Any path that skips it leaks a multi-GB directory:

• process crash / OOM
• force quit (taskkill /F, Task Manager, restart during app update)
• SIGKILL when shutdown times out

There is no orphan sweep at startup and no size cap on a scratch directory.

Amplifier: non-git working directories

For a cwd that is not a git repository, the recorder falls back to whole-file captures (captures/, :692 and :891, bounded per file by maxFileBytes). A few-hundred-MB non-git workspace therefore produces GB-scale scratch per session. The project I was working in was non-git for its first two weeks, which matches the largest directories.

Repro

1. start dsh in a non-git directory with a few hundred MB of files;
2. do a few turns;
3. force-kill the process (taskkill /F);
4. %TEMP% keeps a dsh-workspace-changes-* directory that is never removed.

Count them (read-only):

$t = $env:TEMP
(Get-ChildItem $t -Directory -Force |
  Where-Object Name -like 'dsh-workspace-changes-*').Count

Suggested fixes (any of these stops the growth)

1. Startup GC — on provider init, sweep tempRoot/dsh-workspace-changes-* older than N days that are not owned by a live process. Writing an .owner file (pid + boot id + start time) into each scratch makes "live" checkable without heuristics.
2. Stable namespace — create scratch under tempRoot/dsh/workspace-changes/<uuid> so the sweep target is a single directory and cannot touch unrelated temp entries.
3. Best-effort exit cleanup — process.on('exit') / SIGINT handler that removes the scratch synchronously, plus mark-and-sweep on next start if that fails.
4. Size cap — a maxScratchBytes limit that stops capture (or warns) when one scratch exceeds, say, 512 MB.
5. Maintenance command — e.g. dsh doctor that lists orphan scratch dirs (size, age) and prunes them with dry-run default.

Notes

• No user data is affected; this is purely temp scratch.
• Only the workspace-changes leak is reported here. The browser-profile bytes in the table come from my own automation scripts and are not a dsh issue.

[PerryLink]

Confirmed at master, and the shape is the same one you measured on 0.1.7-rc.2, so this is not a version artefact.

packages/deliverables/workspace-changes/src/recorder.ts:269-271:

private scratchDir(): Promise<string> {
  this.scratch ??= mkdtemp(join(this.env.tempRoot, 'dsh-workspace-changes-'))
  return this.scratch
}

one per Session, created on first use, and :243-247 is the only remover:

async dispose(): Promise<void> {
  ...
  if (this.scratch !== undefined) await rm(await this.scratch, { recursive: true, force: true })

index.ts:110 routes that through the recorder's disposer and :154 subscribes it to session/disposed. Everything you list — crash, force-quit, kill, an update that restarts the process — is a path where that callback never runs, and there is no sweep on the next start.

Two things worth adding to the report.

The sibling leak has a better handle than this one. packages/subprocess/subprocess-local/src/output.ts:206 names spill files dsh-subprocess-<pid>-<counter>-<random>-<label>.log, so a startup sweep can decide liveness from the pid in the name. The workspace-changes directory has no pid, so an age-based sweep is the only option without adding one — which is a reason to add the pid (or an owner file) now rather than after the name is in users' temp roots.

The per-directory sizes in your inventory say where the bytes are: 1.1-6.8 GB and up to ~15k files each, with the layout being objects/ plus captures/ for non-git workspaces. capture.ts copies file contents into captures/ bounded by maxFileBytes per file, so one session that touches a few large binaries produces a multi-gigabyte directory. That matters for the fix because a sweep threshold in days will not help a machine that runs one session a week on a 6 GB tree; the cap that actually bounds the leak is maxFileBytes times the number of captures.

If you want a minimal fix to propose: record the pid (or the process start time) in a file inside the scratch directory at creation, and sweep dsh-workspace-changes-* at startup for directories whose owner is not alive. That is the same information the spill files already carry in their names.