[Bug] dsh-workspace-changes 快照无上限堆叠：rc.2 单日 103 个 / 25.79 GB 写满系统盘，rc.3 仍可复现

[Icey0111]

组件：@deepseek-ai/dsh-workspace-changes 0.2.1-rc.2（事发时）／0.2.1-rc.3（复现确认）
平台：Windows 11（10.0.26200.x）｜Desktop nightly（generic → download.deepseek.com/dsh-desk/feeds/win-x64/）

现象

%TEMP% 下会持续生成 dsh-workspace-changes-<6位> 目录，每个目录是工作区的一份全量副本（内部是 objects/ 内容寻址库）。没有总量上限、没有 TTL、跨快照不去重、会话结束后也不回收。
实测（2026-10-24，同一台机器）：

时间	目录数	占用	备注
00:36 → 01:52（约 80 分钟，rc.2）	103	25.79 GB	256 GB 系统盘被写到 0 字节可用
重装后 76 分钟（rc.3，干净环境）	7	2,117 MB	约 1.7 GB/小时，工作区仅 500 MB

关键证据（当时会话日志原文）

C: is completely full (0 bytes free). Total 256GB.
Temp is full of DSH workspace-change snapshots (dsh-workspace-changes-*) ...
Hundreds of them, ~400-700MB each, totaling ~27GB. Those were created today (2026/10/24 00:36 onwards).
103 snapshot dirs, 25.79GB, all created today within the last ~80 minutes.
Clearly a leak — each workspace edit creates a full snapshot dir and never cleans up.
Freed 25.79GB, now 27.76GB free.

跨快照不去重（真实全量复制，非硬链接）

抽查两个快照中同一相对路径的文件：

rel: objects\00\3e25a335456a33fb59ab4dc62f252da2e5b594
A: File ID is 0x0000000000000000004b000000008d69
B: File ID is 0x000000000000000000c2000000009d75
links A: 1

File ID 不同、硬链接数为 1 → 每个快照都是物理全量副本；SHA-1 去重只在单个快照内部生效。

复现

1. 用一个数百 MB 的目录作为工作区；
2. 正常多轮对话（含少量读写/命令）；
3. 观察 %TEMP%\dsh-workspace-changes-*：每轮新增一个目录，大小≈工作区，旧的不消失，磁盘可用空间线性下降。

期望

1. 硬上限：每个工作区快照总占用设上限（如 2 GB 或磁盘可用空间 5%），超出 LRU 淘汰，接近上限提示；
2. 跨快照去重：同一工作区共用一个对象库 + 引用计数（或硬链接/reflink），边际成本≈变更量；
3. TTL / 会话结束回收；
4. 可配置（开关、上限、保留时长、存储位置——不要默认放系统盘）；
5. 大工作区保护：超过阈值提示或降级为只记录元数据。

影响（为什么建议优先修）

系统盘归零不只是"占空间"：磁盘满之后用户/agent 唯一能做的就是"清理"，而当清理由 LLM agent 执行时，一次通配符/路径写错，删除目标就会从"某个缓存目录"变成"整个盘根"。本机已经因此发生过一次误删（E: 根目录被按字母顺序递归删除，人工介入后停在 M）。
只要系统盘不归零，这条链就不会启动——所以"硬上限 + 写满前阻断"比去重/TTL 更关键。

补充

用户为了不让它写满盘，只能自己注册计划任务（DSH-Workspace-Snapshot-Cleanup，每 15 分钟）定期删 %TEMP%\dsh-workspace-changes-*——这类自救不应该由用户承担。