Version line

v2 — Go rewrite (1.x), main-v2 (active development)

Exact version

Reasonix v1.16.2 渠道：stable / 平台：windows-amd64 安装包大小：19.1MB 下载时间：2026-07-05 01:49

What happened?

问题表现
无限 recovery 链：每次恢复只带回文件级上下文（README 等），之前工具调用的结果全部丢失，导致每轮恢复都在重新开始（读文档 → 分析 → 准备改代码 → 再次崩溃），无法落地任何代码修改。

锁文件不清理：每次 crash 后留下 .lock、.lease.lock、.lease.json 空文件，session 结束后仍不自动清除。目前积压了约 15 个锁文件。

.display.json 残留 orphan 条目：recovery 会话已删除后，.display.json 仍保留其条目，需手动清理。

归档脚本误删有用会话：archive_recovery_sessions.py 因逻辑问题把原始会话和当前会话也误移入 .trash/，需额外编写恢复脚本。

Steps to reproduce

Steps to reproduce（复现步骤）：

新建一个 Reasonix 会话（desktop 或 CLI），选择 deepseek-v4-flash 模型
在会话中进行多轮正常的代码工作，例如：读取文件 → 分析代码 → 编辑文件 → 运行 bash 命令（git、python 等）
当会话进行到一定轮数（我们当时约 10-15 轮）或上下文达到一定量时，Reasonix 突然 crash
Crash 后自动恢复，弹出提示：「当前会话来自保存冲突恢复。继续前建议与原会话对比」——点继续
恢复后的会话上下文丢失：之前做的工具调用结果全部不在，只有 README 等文件级上下文还在
继续工作，再次 crash → 再次恢复 → 形成 recovery 链（我们最多记录了 8 层嵌套 recovery）
查看 sessions 目录（~/AppData/Roaming/reasonix/projects//sessions/），可见：
大量嵌套 recovery 会话文件（...recovery-xxx-recovery-yyy-recovery-zzz.jsonl）
大量空锁文件（.lock、.lease.lock、.lease.json，0 字节）
.display.json 中残留已不存在的 recovery 会话条目
在一次正常对话（00:48 开始）中，Reasonix 反复崩溃后自动恢复，形成连环 recovery 链：
原始会话 (20260705-004847)
└─ crash → recovery-166dbad729f1cc2f
└─ crash → recovery-3e55339878b8793c
└─ crash → recovery-1b25102ad26a2014
└─ crash → recovery-fda47a5c1e731ddf
└─ crash → recovery-c82e5dc190661d31
└─ crash → recovery-cfc9276e42655dc3
└─ crash → recovery-9ac53bb7ec683cf3
└─ crash → recovery-c40aec22f494f0b7
后续 deepseek-v4-flash 模型会话也出现了同样的 recovery 链（5 层嵌套 recovery）。

OS / platform

版本 Windows 11 专业工作站版 版本号 25H2 安装日期 ‎2025/‎4/‎25 操作系统版本 26200.8737 功能包 Windows 功能体验包 1000.26100.334.0

Relevant logs or output

从实际观察中，我总结了以下可粘贴的日志：

没有找到 Reasonix 的系统 crash log（可能在 daemon 进程里）。不过可以从**用户实际看到的现象**来写这一节，可粘贴的日志如下：

---

**Relevant logs or output**

1. **崩溃恢复后提示**（每次打开 session 时弹出）：

恢复分支：当前会话来自保存冲突恢复。继续前建议与原会话对比。


2. **触发 sandbox 阻止清理残骸时的错误**：

error: bash sandbox requested but unavailable on this platform; refusing to run unconfined


3. **清理脚本运行报错**（锁文件被并发删除导致）：

FileNotFoundError: [WinError 2] 系统找不到指定的文件。
: '...sessions\\...recovery-xxx-recovery-yyy.jsonl.lease.lock'


4. **sessions 目录状态**（一个正常项目应有的文件数约 3-5 个，实际膨胀到 40+）：

$ ls sessions/ | wc -l
> 40+

# 典型的 recovery 链文件名
20260705-004847.553147000-session-recovery-166dbad729f1cc2f
  -recovery-3e55339878b8793c
  -recovery-1b25102ad26a2014
  -recovery-fda47a5c1e731ddf
  -recovery-c82e5dc190661d31
  -recovery-cfc9276e42655dc3
  -recovery-9ac53bb7ec683cf3
  -recovery-c40aec22f494f0b7.jsonl    ← 8层嵌套

# 残留的空锁文件示例
*.lock         (0 字节)
*.lease.lock   (0 字节)
*.lease.json   (439 字节)

# .display.json 中残留的 orphan 条目
"topic_20260705-020638_...": "恢复分支",
"topic_20260705-020926_...": "恢复分支 · 恢复",
"topic_20260705-020927_...": "恢复分支 · 恢复",
"topic_20260705-020930_...": "恢复分支 · 恢复",


5. **一个 recovery 会话的 telemetry 数据显示在崩溃前已完成大量工作但全部丢失**：

{
  "usage": {
    "promptTokens": 4255010,
    "completionTokens": 16180,
    "totalTokens": 4271190,
    "requestCount": 38,
    "elapsedMs": 235536,
    "sessionCost": 0.26
  }
}
// 38 次 API 请求、¥0.26 的成本，全部因 crash 丢失