长会话内存增长的两条通道：request/header 重复写入、workspace-changes 快照无回收（第二条已附 PR）

[chenxixian]

长会话内存增长的两条通道：request/header 重复写入、workspace-changes 快照无回收

其中第二条我已经提交修复 PR：chenxixian#3 （基线 dsh-v0.2.2-rc.2，10 文件以内，附测试）。第一条属于日志格式语义变更，不适合直接给 patch，先在这里说明机制并提建议。

环境

项	值
DSH	0.2.0-rc.2（首次崩溃）/ 0.2.1-rc.5（复核环境）
Node	v24.20.0（arm64）
系统	macOS 26.6.2，Mac17,3（M5），16 GB
启动方式	dsh web --no-open（未设置 NODE_OPTIONS）

两次进程级崩溃，都是 V8 老生代耗尽后 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory：

次序	存活时长	Mark-Compact 后保留	默认堆上限
1	666,556,712 ms（7.71 天）	3972.8 MB（仅回收 11.8 MB，mu=0.123）	4288 MB
2	62,900,471 ms（17.47 小时）	4297.6 MB	4288 MB

node -e "require('v8').getHeapStatistics().heap_size_limit" 在 16 GB 机器上实测 4288 MB。桌面版已经通过 PR dsh-tauri#703 下发 --max-old-space-size，dsh web 目前没有（dsh-app-boot@0.2.2-rc.2 无相关代码）。

问题 1：request/header 的去重粒度失效

真实会话（解压 220 MB / 65,540 帧）的事件构成：

事件类型	体积	占比	帧数	单帧均值
assistant/message	74.4 MB	33.8%	7,209	10.3 KB
request/header	70.3 MB	31.9%	1,032	70 KB
system/message	35.0 MB	15.9%	1,035	34 KB
tool/result	17.6 MB	8.0%	8,207	2.1 KB
tool/call	7.2 MB	3.3%	8,126	0.9 KB
user/message	4.5 MB	2.0%	2,833	1.6 KB

按 reason 拆开 1,032 条 request/header：

reason	帧数	占比
series	932	90.3%
change	74	7.2%
resume	25	2.4%
initial	1	0.1%

对应 packages/core/agent-loop/src/agent.ts 的 buildRequest()：headerEquals(baseline, header) 的去重只在同一 series 内有效；一旦 startsSeries 为真（每轮交互几乎都会开启新 series），代码走 else if (startsSeries) 分支，无条件把完整 header 再写一遍，尽管此时 headerEquals 判定它与 baseline 完全相同。所以问题不是「没做去重」，而是「去重粒度对不上实际交互节奏」。

后果是双层的：磁盘上一份会话被这些重复帧撑到 220 MB；内存里每一份都会成为独立的 JS 对象并被 snapshot 整体持有（实测物化系数 2.1×，约 4,696 字节/帧；190 MB 解压会话常驻约 408 MB），同时每次请求还要把整个 transcript 再序列化一次——第二次崩溃的栈正是 Runtime_StringSplit → Factory::NewArray 分配失败。

建议：reason: "series" 的帧不重复携带完整 header，只携带对上一份 header 的引用（内容哈希 / 上一帧 seq），或者只带差异。这能把它在该会话里的占比从 31.9% 压到不足 3%，同时消除每次请求的重复反序列化。我知道这会改日志格式语义，所以先提出来讨论，不塞进 PR。

同类问题在 openai/codex#30932（"huge rollout dominated by repeated compacted records" 导致 resume 时 OOM）已经出现过。

问题 2：dsh-workspace-changes-* 快照无回收 → 已提 PR

指标	实测
残留目录数	236 个（六周累积）
合计体积	40.7 GB
单个目录最大	2.5 GB，66,284 个文件
副本形式	stat -f '%l' → links=1，实体副本而非硬链接
活跃日新增	12–18 个
连带效应：fseventsd 常驻内存	2.41 GB（killall fseventsd 后回落 4.6 MB）

原因很直接：scratch 目录只在 Session disposal 时删除，而 OOM / crash / kill 的 Host 永远不会 dispose，于是这些目录在临时根目录里永久堆积，没有 TTL 也没有容量上限。

PR chenxixian#3 的做法：scratch 目录创建时写一个写明所属进程的 lease 文件；插件加载时扫描临时根目录，所属进程已退出的目录一律回收，没有 lease 的（旧版本写出的）按新的 orphanTtlMs（默认一周）回收，所属进程仍存活的一律不动，所以并发 Host / Session 共用临时目录也安全。pnpm vitest run packages/deliverables/workspace-changes 通过 10 文件 / 65 测试。

这和 0.2.2-rc.2 已经引入的「归档会话默认清理符合条件的 Git 工作树」是同一个形状——「teardown/reload 时回收」这个机制只是没覆盖到 scratch 目录。

fseventsd 被 inode 事件风暴撑大这件事另有同类案例：abiosoft/colima#1569、Apple Developer Forums #849819。在 16 GB 机器上，4.3 GB JS 堆 + 2.4 GB fseventsd 会把物理内存吃到只剩 30%，反过来让 OOM 更早发生，而 OOM 又正是产生这些残留的原因——一个闭环。

第三条建议（不打算单独提 PR）

dsh web 也下发 --max-old-space-size，直接复用桌面版 PR dsh-tauri#703 的策略（物理内存的一半、钳到 [2048, 8192]、NODE_OPTIONS 优先）。现在 web 模式下用户必须自己设环境变量，否则会撞在 4288 MB 的默认上限。

顺带一个更省事的告警点：会话解压体积超过阈值（比如 100 MB）时，在加载时打一行 warn 或给 UI 提示「该会话已超健康体积，建议拆分」，把发现时间从崩溃提前到崩溃前几小时。

本机对账摘要

项	数值
默认堆上限	4288 MB
两次崩溃点	3972.8 MB / 4314.9 MB
最大会话	73 MB 压缩 / 220 MB 解压 / 65,540 帧
request/header	1,032 帧 / 70.3 MB（31.9%），其中 series 932 帧（90.3%）
system/message	1,035 帧 / 35.0 MB（15.9%）
两者合计占比	47.8%
物化系数	2.1×（4,696 字节/帧）
scratch 残留	236 个 / 40.7 GB；最大单目录 2.5 GB / 66,284 文件
fseventsd 峰值 / 清理后	2410 MB → 4.6 MB

数据来自本机实测（zstd -dc、vmmap、top、stat、du），会话内容已脱敏，只提供计数与字节数。