dsh-fork-inbox-guard
丢弃分叉会话继承的待处理提示，使分叉子会话响应你发送给它的提示，而不是源会话中无人认领的队列。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:azazo1/dsh-fork-inbox-guard#51f9e20a57802a28b78f18dba23435473469b4f9Fork Inbox Guard 以 dsh-fork-inbox-guard 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
DeepSeek Harness Host 插件: 分叉会话时丢掉子会话从源会话继承来的待领提示词, 让子会话第一个回合回答的是你刚发的那条.
源会话有一个回合正在跑 (或有排队消息) 时点 Fork, 然后在子会话里发一条新提示词, 子会话会先把源会话那条还没被消费的提示词执行一遍, 你自己的提示词被推到下一轮. 同一条命令可能被跑两次.
两个入口都会出现: 侧边栏会话行的 Fork session, 消息菜单的 Branch into a new conversation.
Fork 用源会话日志的一段前缀给子会话做 seed. 切点从边界的 turn/end 往后扫到下一个 turn/start, 于是 agent/inbox/spliced 的"插入"落进了 seed, 而把它取走的"领取"发生在下一个 turn/start 之后, 留在源会话里. 子会话的 inbox 投影就认为那条消息还挂着.
待领输入描述的是"某个 Agent 接下来要跑什么", 而那个 Agent 是源会话. 所以它是活状态, 不是历史, 不该跟着 seed 走.
插件在 agent/session-start 上判断: 这次启动是不是 startup (即 agents.create(), fork 的两条路径都走它), 会话头是不是带 seed (isSeeded), 以及 inbox 里是不是真有待领消息. 三条都成立才调一次 inbox.clear(), 并记一行 info 日志.
outcome: 'canceled' 的 agent/inbox/spliced, 子会话日志里留下"继承了但已作废"的记录, 而不是无声抹掉.resume 不动: 那些消息本来就是排给这个会话的, 是它自己的工作.覆盖的入口: 侧边栏 Fork, 消息菜单 Branch, subagent 的 fork provider, agent-team 的 context: 'fork' 队友, 以及裸 sessions.fork() 之后建起来的 agent.
在插件目录:
dsh plugin --profile web add "link:$(pwd)"
装完重启 dsh web. 卸载:
dsh plugin --profile web remove dsh-fork-inbox-guard
只影响 Host 半区, 不注册 Client 模块, 不需要重新构建前端.
最可靠的信号在子会话日志里: 分叉出来的会话会出现一条 agent/inbox/spliced, outcome 是 canceled, removedCount 是 1. 那条就是被丢掉的继承消息, 之后子会话第一个回合的 user/message 就是你新发的那句.
插件同时通过 ctx.logger 记一行:
fork-inbox-guard: dropped the pending inbox of seeded session "session-xxxx"
默认的 web profile 不装 console logger, 这一行不会打到终端; 需要看到它的话, 自行挂载 @deepseek-ai/cordis-plugin-logger-console. 没有这行说明这次分叉没有可丢的东西, 是正常的.
agent/session-start 的 source 取值, Agent.inbox 和 SessionHeader.isSeeded. Harness 的公开 API 在 1.0 之前不保证稳定, 升级 dsh 后请重跑 just test.