claude-in-dsh 1.3.0

新增

• 上下文占用圆环：输入框下方显示当前对话占了模型上下文窗口的多少（算法与 waku 一致：最后一次调用的 input + cache_read + cache_creation + output ÷ 该模型 contextWindow），70%% 转黄、90%% 转红，悬停看具体 token 数。

变更

• 粘贴图片按 dsh 原生样式预览：从一行文字提示改成 dsh 附件栏同款的 64px 缩略图（16px 圆角、卡内删除键），并移到输入框上方那条独立带里（conversation.input.dock），与 dsh 自己的附件栏同一位置。
• 侧栏 Claude 标记不用先点开：引擎索引原先只统计活着的 agent，所以一条 Claude 对话要被打开过才显示 ✳。现在插件持久化的每会话引擎归属也计入（实测 5 行会话、一条未打开、5 个标记）。
• 导入的对话继承自己的权限档和模型：Claude transcript 里记着 permissionMode 和 model，导入时读进会话设置；此前导入的老会话打开时也会补上。否则导入后停在默认的「监督 · 每个工具问我 / Claude 默认」，下一轮就会用一个你没选过的权限档跑起来。

claude-in-dsh 1.2.0

彻底解决「消息发出去了、Claude 也在跑，但 dsh web 上就是不显示、刷新也没用」这一类问题。

根源

补写内容（导入回填、断档补播、终端侧镜像、编号修复）此前自己编轮号。三种方案，三种撞法：

• 高位段（1000000+）→ dsh 后续的真实轮次比它小，而 dsh 会丢掉倒退的轮次（实时看得到、刷新就没）；
• 挂进已有轮次 → updates 在窗口内、它的 turn/start 在窗口外 → received an update before its start Match；
• 自建 turn 1 → 和 dsh agent 的第一轮撞号 → 同一轮出现两个 turn/start。

修法

让 dsh 来开这一轮：内容先排队，用一条内部载体消息唤醒 agent，dsh 分配下一个轮号并进入 pre-step，插件把内容写进这个轮号后直接结束该轮——不调用模型、不消耗额度。载体消息不写进转录、也不发给 Claude。轮号完全由 dsh 维护，重号／倒退／缺 start 三种情况都不可能再发生。

顺带

• 导入不再截断：原先超过 240 条只回填最近部分，现在整段导入（实测 187 条消息的对话完整回填）。

实测：整段重新导入 → 无「历史加载失败」→ 内容完整 → 刷新后仍在；探针确认投影落在 dsh 分配的轮号内（turn/start {turn:4} 由 dsh 写，内容在 step 1）。

claude-in-dsh 1.1.5

症状：转录里刷出几十行红色的「这次调用没有等到结果（上一次运行被中断）」。

原因：1.1.4 的重复守卫做过了头——它把重复的工具结果也一并跳过了。但常见情况恰恰相反：调用早已实时渲染在日志里，而投影带来的正是它缺的那个结果。结果被跳过后调用永远处于未应答状态，随后轮次开始时的收尾逻辑会把整个会话里所有未应答的调用一次性标红。

修复：只跳过日志里已经有结果的调用结果；投影不再对整个会话做收尾，只关闭它自己开出且确实没等到结果的调用。实测同一段对话重新导入，红行 3 → 0。

claude-in-dsh 1.1.4

症状：会话打不开，报 tool-call toolu_… received more than one start Match（internal），整段历史加载失败。

原因：补写内容（断档补播、导入回填）时重新发出了日志里已经存在的 tool-call 编号。dsh 的会话装配拒绝同一个调用出现第二次 start，于是整条历史加载失败。1.1.1 之前的补播会重放已经渲染过的内容，正是这样制造出重复——在一条真实会话里查到 21 个。

修复：补写前先收集日志里已有的调用编号，已存在的调用及其结果一律跳过；本次投影自己写出的编号也记入，避免同一批内重复。

claude-in-dsh 1.1.3

症状：在 dsh 里发了消息，回复实时能看到，一刷新（或切走再回来）就没了、加载不出来。

原因：插件给投影内容（导入回填、断档补播）自己编了高位轮号（1000000+），本意是避开实时轮次。但 dsh 的 agent 用的是构造时从日志读出的内存计数，不会跟着高位段走，于是日志里的轮号变成 1, 2, 3, 1000001, 4, 5, 6, 1000002, 7, 8 这种倒退序列——而 dsh 的历史装配会丢掉倒退的轮次。

修复：投影不再新建轮次，直接挂在日志里编号最高的那个轮次之后（用更高的 step 号），轮号序列完全交给 dsh 维护。已验证：此前丢失的回复恢复显示，且刷新后仍在。

对已经被旧编号搅乱的会话，打开时会尽量把滞留内容补回；若轮号已多处倒退（append-only 日志无法原地修复），插件会在日志里说明并建议重新导入该 Claude 对话——Claude 侧 transcript 完整，重新导入即得干净副本。

claude-in-dsh 1.1.2

修复 1.1.1 收紧回收阈值后暴露的问题：broker 被回收（或被外部杀掉）后，插件内存里的 run 还活着并被下一轮复用——reader 在 tail 一个已删除的日志，writer 的 cat > .../in 把 fifo 路径重建成普通文件，prompt 写进去就没了，轮次永远等不到回应。这就是「重启 dsh 后老对话发消息没反应」。

现在复用 run 之前先 kill -0 校验 broker 还在；不在就丢弃并按 --resume 重新拉起 Claude。实测：杀掉 broker 后下一条消息 6 秒答复，且重新拉起的进程仍能准确复述前两轮内容。

claude-in-dsh 1.1.1

两个 bug 修复，都来自本机实测。

卡片永远停在「等待输出…」

跟工具本身无关。attach.json 里的读取偏移只在优雅 detach 时写，dsh 被直接杀掉（pm2 restart）后偏移是陈旧的；下次补播就把已经实时渲染过的一整段又投影一遍。于是同一个工具调用在日志里存在两份——一份在实时轮次、一份在高位历史段——而 dsh 是按位置把结果配到调用上的，实时那张卡片永远等不到自己的结果，真正的回答落到了历史段里。

两道保险：读取端在每个轮次边界落盘偏移；补播前用工具调用 id 与转录已有内容对齐，重叠部分直接跳过。

挂机的 Claude 进程占内存

一个闲置的 Claude 是一整个 Node 进程。原来 6 小时才回收，在 2GB 的机器上意味着 6 个停着的会话占着 639MB。现在：空闲阈值 45 分钟、扫描周期 10 分钟、dsh 里已不存在的会话闲置 5 分钟即回收、正在跑轮次的会话永不回收。实测一次释放 465MB（639 → 174MB）。上下文不丢：下次发消息按 --resume 重新拉起。

升级

curl -fsSL https://raw.githubusercontent.com/GeekRicardo/claude-in-dsh/main/install.sh | bash
bash scripts/safe-restart.sh

claude-in-dsh 1.1.0

围绕导入本机 Claude 对话和粘贴图片两条主线，外加 dsh 重启期间不丢内容。完整条目见 CHANGELOG。

主要变化

• 粘贴图片：Claude 会话里粘贴图片不再被 dsh 的「当前模型不支持图片」挡下。图片存成 dsh 原生附件（转录里直接显示），原始字节以 stream-json image block 随下一条消息送给 Claude，输入框下方有待发提示。
• 导入的对话带完整历史：整段 transcript 投影成 dsh 原生事件（消息、工具卡片、subagent），标题取 Claude 对话自己的标题，重启后仍可加载；面板支持按标题和对话内容搜索（命中显示片段）、返回箭头、导入进度、以及「正在使用中」的分支提醒。
• 断档补播：dsh 自己被重启（对话里执行 pm2 restart 之类）会中断它自己的轮次，但 broker 保住了 Claude 进程；断档期间已完成的输出会补播进转录，不调用模型、不消耗额度。
• scripts/safe-restart.sh：重启 dsh 前先确认没有进行中的 Claude 轮次。多个 agent 共用一台机器时，盲目重启就是对方对话里 TOOL_OUTCOME_UNKNOWN 红卡的来源。
• 模型选择器显示进程实际运行的模型（claude-opus-5[1m] → Claude Opus 5 (1M)），不再是笼统的「跟随 Claude 自己的设置」。

验证状态（如实说明）

粘贴图片、导入历史与搜索、断档补播、safe-restart 都在本机真实 dsh 会话里跑通了（Playwright 驱动）。导入对话的增量同步只验证了一半：偏移记录与分叉判定已验证，"终端侧续写后镜像进 dsh" 那一遍还没端到端跑过。

升级

curl -fsSL https://raw.githubusercontent.com/GeekRicardo/claude-in-dsh/main/install.sh | bash
bash scripts/safe-restart.sh   # 或 pm2 restart dsh-web