[bug]dsh-0.1.3-alpha.1崩溃后重启无法恢复会话

[tyzamTsing]

win10下dsh oom异常退出，异常前执行grep等操作，重启dsh后处于pending状态，估计是等待操作完成？继续会话没有响应，直到若干时间（超时）后恢复处理

[argszero]

先给版本背景：0.1.3-alpha.1 是 master 开发线（刚发），这类崩溃恢复问题在 alpha 上出现不意外——但你这个报告的形状值得拆开看，因为它牵涉两个不同阶段。

dsh 对"中断"是分阶段的（源级）

进程崩溃时会话里可能有两种未完成状态，恢复机制不一样：

1. LLM 流中断——packages/core/agent-loop/src/agent.ts 有专门的 interrupted-block 收尾：stream abort 时把已生成的 content 以 interrupted: true 的 assistant/message 落库（:387-400），下次 resume 从这个锚点继续。这条路径是设计好的。
2. 工具调用执行中崩溃——assistant/message 已带 tool_calls 落库，但 tool 的 result 事件没来得及产生（进程死了，执行方也随之消失）。这属于另一阶段：resume 时如果逻辑在等一个"永远不会来的完成信号"，就会表现为你说的 pending 直到超时才恢复。

你描述的"OOM 前在执行 grep → 重启后 pending → 若干时间（超时）后恢复"更像第 2 种 + 一个等待侧的悬空。这与本仓库已知的"unbounded wait"家族同形（#5056：follow-stream 不随 session dispose 终止；#1607/#2544：主体缺席时 promise/stream 永不 settle）——OOM 恰好制造了"主体缺席"。

几个判别问题（能定位到具体机制）

1. 重启后 pending 的是整个会话（新消息都不动）还是某一条工具调用行？
2. OOM 前在跑什么类型的操作：bash/grep（输出量大不大？grep 大目录可能产生海量 stdout——这是 OOM 的候选触发点）、subagent、MCP 工具、还是文件操作？
3. 重启后开一个新会话能立刻正常工作吗？（能 = 问题在会话恢复路径，不能 = 更全局）
4. "超时后恢复"——恢复的是同一个会话吗？恢复时有没有报错/工具超时提示？大概多久？
5. Windows 事件日志里 OOM 是确认的"out of memory"还是进程被杀？dsh 日志在崩溃前最后几条是什么？

建议抓的东西

崩溃时刻的 dsh 日志尾部 + 重启后 pending 阶段的日志（工具超时/重试会打点）+ 崩溃前最后一条 tool 相关事件。有了 1-4 的答案，就能判定是"resume 阶段漏关了某种 in-flight 操作"（core 修，落点可能在 agent-loop 的工具执行恢复路径）还是"OOM 触发点本身要治"（grep 大输出缓冲——那是另一个修面，UI/工具输出有界化）。

如果你愿意，贴一下 pending 时的界面截图 + 崩溃前日志尾部，我可以按源把具体等待点找出来。