[Bug] 分叉（fork）会继承父会话"已入队未执行"的消息并在子会话自动重跑，且没有任何干预窗口

[ruoqidezhishi]

Issue type: Bug（行为 + 可见性）
Component: @deepseek-ai/dsh-api-session-controller（Host 侧 fork()）；次要：dsh-client-ui-chat / dsh-client-ui-conversation
Version: @deepseek-ai/dsh 0.1.5-rc.1（npm latest/next），会话格式 V3
Platform: Windows / Node v24.19.0（与平台无关，纯逻辑缺陷）

---

TL;DR (English)

SessionController.fork() seeds the child with every event between the boundary turn's turn/end and the next turn/start. That interval contains agent/inbox/spliced (target: "next-turn") — a user message the parent had already submitted but not yet executed. So the child silently inherits it and runs it as its own next turn, re-executing the same user message in both sessions.

The user cannot intervene: the queue panel (QueueDock) is fed by the live control stream and renders nothing for a cold session, while any moment the session becomes live the inherited item is already consumed as FIFO head and becomes an immutable historical user/message (DSH has no edit entry point for historical messages).

---

1. 根因

SessionController.fork() —— @deepseek-ai/dsh-api-session-controller/lib/types/commands.js（约 L187–L275）：

// L211-218
const lastSeq = source.events.at(-1)?.seq ?? -1;
const anchoredBoundary = atSeq === undefined
    ? undefined
    : source.events.find(event => event.type === 'turn/end' && event.seq >= atSeq);
const boundary = anchoredBoundary
    ?? (atSeq === undefined || atSeq > lastSeq
        ? source.events.findLast(event => event.type === 'turn/end')
        : undefined);
if (boundary === undefined) { /* throw 'session/fork-unavailable' */ }

// L224-227  ← 问题所在
let cut = SessionLogOffset(boundary.seq + 1);
while (cut < source.events.length && source.events[cut]?.type !== 'turn/start') {
    cut = SessionLogOffset(cut + 1);
}

// L239-253
await this.ctx.agents.create({
    sessionId: childId,
    seed: source.events.slice(0, cut),      // ← seed 里含排队消息
    inheritedEventCount: cut,
    meta: { /* ... */ parentSession: source.header.id, isSeeded: true },
    /* ... */
});

那个 while 循环的设计意图是合理的：把 turn/end 之后、下一个 turn/start 之前的包级状态事件一并继承，否则子会话会丢失权限/沙箱/标题等状态：

区间内的事件	语义	是否应继承
permission/preset、sandbox/mode、approval/policy	状态	✅ 应继承
session/title	状态	✅ 应继承
agent/inbox/spliced（target: "next-turn"）	待办动作	❌ 不应继承

缺陷本质：切点逻辑没有区分事件语义，把"状态"和"待办动作"一视同仁地塞进了 seed。

2. 用户可见症状

1. 子会话"自带"一条用户消息并自动执行 —— 意外产生一轮对话、意外消耗 token。同一条消息在父、子两个会话里各执行一次。
2. 无法编辑、无法删除、无法阻止 —— 见 §4，不存在任何可干预窗口。

3. 复现步骤

条件：在下一轮消息已提交、但尚未执行完毕的时刻分叉。

1. 完成第 N 轮对话（turn/end turn=N）。
2. 发出第 N+1 轮消息（它先以 agent/inbox/spliced {target:"next-turn"} 入队，随后才产生 turn/start turn=N+1）。
3. 在第 N 轮尾部点"分叉"按钮（客户端 forkAt(closing.finalNode.seq)）。
4. 打开子会话 —— 第 N+1 轮的那条消息被继承并在子会话中重新执行。

触发条件极窄但完全确定性：atSeq 落在第 N 轮内 → boundary = 第 N 轮 turn/end → cut 推进到第 N+1 轮 turn/start 之前 → 恰好吞掉那条 agent/inbox/spliced。

4. 为什么用户"看不到也改不了"

这里有两条互不相通的数据通路，它们的错位才是问题最糟的部分：

通路 A（分叉复制）：持久化日志 → seed 里含 agent/inbox/spliced → 会执行。

通路 B（队列面板）：运行时 live agent → 独立 control 流 → 客户端 SessionQueueMirror：

• dsh-api-session-controller/lib/types/client/sessions/session.js L387：

  "queue state belongs to the independently reconnecting control stream and remains untouched."

• replaceControl(queue) → queueMirror.replace(queue)；服务端数据由 control.js 的 queueItems(agent) 生成，直接读 live agent 的 inbox。

• 冷会话没有 live agent → control 流没有 queue 数据 → 客户端 queue 为空 →

  dsh-client-ui-conversation/lib/client.js L14096：

  if (rowCount === 0) return null;   // 整个面板不渲染

• 而 README 明确：history pages / log following 可以在不激活 Agent 的前提下进行。

结果：

会话状态	日志里有这条消息吗	队列面板看得见吗
刚分叉、未激活（冷）	✅ 有	❌ 面板根本不渲染
已激活（有权限请求/指令在跑）	✅ 有	⚠️ 但此时它已作为队首被 FIFO 消费成历史 user/message

而历史消息在 DSH 里没有编辑入口 —— 全库唯一的编辑能力是 queue.edit（"编辑排队消息"），它只作用于 placement === "queued" 的项。

→ 两个状态之间不存在可编辑窗口。

佐证：DSH 自己的失败文案 queue.editFailed = "编辑失败：这条消息可能已经开始发送。" 说明这类竞态是被意识到的，但防御只加在编辑路径上，没加在分叉路径上。

5. 实测证据（真实日志）

工作区 <workspace>，2026-09-10 21:26–21:43 (UTC+8)。日志 <DSH_HOME>/sessions/<workspace-slug>/<id>/session.v3.jsonl.zstd（多帧 zstd，需按 magic 28 B5 2F FD 分帧解压）。

父会话 session-05705bef…（6 轮）：

seq=252  turn/end turn=4
seq=253  agent/inbox/spliced  {target:"next-turn", start:0, inserted:[{content:[{type:"text",text:"<user msg>"}], id:"6ed2075c…"}]}
seq=254  turn/start turn=5
...
seq=260  turn/end turn=5
seq=261  agent/inbox/spliced  {target:"next-turn", start:0, inserted:[{content:[{type:"text",text:"<user msg>"}], id:"7362451f…"}]}   ← 已提交、未执行
seq=262  turn/start turn=6

子会话 session-f5b07ce6…（parentSession = 05705bef，inheritedEventCount = 262）：

seq=261  agent/inbox/spliced  {…同上，逐字节继承，id:"7362451f…" 原样保留…}
seq=262  session/end-seed {inherited:true}      ← 继承切点
seq=263  session/title {"… (1)"}
seq=264  agent/inbox/spliced  {start:1, inserted:[{"."}]}   ← 位置 0 已被继承项占据，故新消息插到 index 1
seq=265  turn/start turn=6
seq=266  agent/inbox/spliced  {target:"next-turn", start:0, removedCount:1, inserted:[]}   ← FIFO 消费队首
seq=268  user/message «<user msg>»              ← 执行的正是继承来的那条

同一批数据里另外两个切点（inheritedEventCount 可直接从投影缓存 identity 读出）：

子会话	inheritedEventCount	继承内容	后果
session-93312d71…	254	第 1–4 轮 + 第 5 轮排队消息（seq 253）	自己把该消息跑成 turn 5@257
session-f5b07ce6…	262	第 1–5 轮 + 第 6 轮排队消息（seq 261）	自己把该消息跑成 turn 6@265
session-9ecab245…	265	第 1–5 轮 + 两条排队消息	未激活，两条一直 pending

session-9ecab245 的投影缓存 inbox 行（冷 projection 里它在，印证通路 A 与 B 的错位）：

"next-turn": [
  { "content":[{"type":"text","text":"<inherited user msg>"}], "source":{"kind":"user","rpcId":"cbb9af3f…"}, "id":"7362451f…" },
  { "content":[{"type":"text","text":"."}],                  "source":{"kind":"user","rpcId":"ef41af61…"}, "id":"178959ce…" }
]

6. 建议修复（按推荐度排序）

A2（推荐，Host 侧）：保留 seed，但在子会话追加一条清理继承待办的动作

fork() 在 agents.create() 之后，检测 seed 中未消费的 inbox 项并追加：

agent/inbox/spliced { target: "next-turn", start: 0, removedCount: <继承的待办项数>, inserted: [] }

优点：同时保留包级状态（权限/沙箱/标题照旧继承），又不让待办动作跨会话复制；语义上也更正确——"新会话不应替父会话执行它没跑完的事"。

A3（次选，Host 侧）：把"队列非空"变成分叉的前置条件

在 fork() 里，若源会话 inbox.nextTurn/inbox.nextStep 非空，返回一个明确的错误码（复用 session/fork-unavailable 的形态，如 session/fork-queue-pending），由客户端提示用户"队列中还有未执行的消息，请先处理"。

不建议直接截断 cut —— 因为 cut 是连续前缀长度，截断会连带丢掉紧随其后的 session/title 等状态事件。

B（应与 A 同时做，Client 侧）：让不可用状态可见

dsh-client-ui-chat/lib/client.js L3667 已有"分叉不可用"机制：

branchUnavailable: data.branchUnavailable || hasLaterChatNode

把"队列有待执行消息"纳入该条件，按钮置灰并给出原因提示。当前的问题是：行为发生了，UI 却完全不解释。

附：一处值得一并审视的不一致

同为 projection，dsh-schedule 与 dsh-subagent 都显式跳过 seed 区间：

// dsh-schedule/lib/types/projection.js L55
if (event.seq < state.inheritedEventCount || event.type !== 'schedule/change') return state;
// dsh-subagent/lib/types/catalog.js L73
if (event.type !== 'subagent/catalog' || event.seq < state.inheritedEventCount) return state;

而 inbox 的 fold 不跳过，所以 seed 里的排队消息会进入运行时队列并被消费。这个不一致正是"日志里有、UI 里没有"的源头，建议明确 inbox 在 fork 语义下应遵循哪一种。

---

附：定位索引

位置	作用
dsh-api-session-controller/lib/types/commands.js L187–275	fork()，缺陷本体（L224–227 的 cut 推进）
dsh-api-session-controller/lib/types/control.js L151–172	queueItems() 读 live agent 的 inbox
dsh-api-session-controller/lib/types/client/sessions/queue-mirror.js L12–16	textOf()：content 含非 text 块 → null → 编辑按钮置灰
dsh-api-session-controller/lib/types/client/sessions/session.js L387, L422–427	queue 只由独立 control 流填充
dsh-client-ui-conversation/lib/client.js L14071, L14096, L14247	QueueDock；空队列直接 return null；编辑可用条件
dsh-client-ui-chat/lib/client.js L3664–3667, L8338–8346	分叉按钮：forkAt(closing.finalNode.seq)、branchUnavailable
dsh-client-ui-workspace/lib/client.js L73–75	会话列表「分叉会话」：不带 atSeq → 从最后一个已完成轮次分叉（带走全部历史）

相关讨论

• #6188 插话消息请显示是否已读取，并允许在读取前修改或撤回 —— 那条讲的是 steer 消息的读取状态与读取前撤回；本条讲的是 fork 切点把 pending 消息跨会话复制，属于 Host 侧 seed 语义问题。两者机制不同，但同属「待处理消息的可控性」。

说明：以上结论来自 0.1.5-rc.1 的发行包源码阅读 + 本机会话日志（session.v3.jsonl.zstd）逐事件核对，未在干净环境中做端到端跨平台复现。

[wufe8]

情况类似 同时再拉个相关讨论: [#6022 Bug] Forking a session inherits the parent's queued prompts — the child executes them on first submit — #6022

我遇到的情况比较类似 有个会话多次发送消息都变成了发排队消息 然而实际发出的是同会话中很早之前的信息 即使停止, 撤回, 修改均无效

下面是ai的分析文档:

dsh-seeded-session-phantom-pending-inbox-bug.md

[ruoqidezhishi]

Correction: an intervention window does exist — it is just undiscoverable

Follow-up to the original report. One conclusion in it was wrong, and it is worth correcting rather than leaving a misleading premise in the thread.

What the report got wrong. It states the user has no intervention window. That is incorrect. The window exists — it simply sits in a session state the UI never guides you into.

The three states. The queue panel is fed by the live control stream, so visibility depends entirely on whether the agent is alive — and being alive is not the same as having a prompt submitted:

Session state	Item in log	Queue panel visible	Editable / removable
Just forked, cold	✅ yes	❌ panel does not render at all	—
Live, but no prompt submitted (e.g. a permission/approval switch)	✅ yes	✅ yes	✅ yes — still the pending FIFO head
Prompt submitted (turn running)	✅ yes	✅ yes	❌ already consumed into a historical user/message

The middle row is the window.

Why a permission switch opens it. dsh-user-approval's ApprovalService.setPolicy(agent, policy) takes a live agent — its own doc comment reads "Switch one live agent's policy and queue the transition for its next model step". So toggling the approval policy (never ↔ ask) or the permission preset activates the session, which brings the independent control stream and the queue panel up, without submitting a prompt — therefore the inherited item is not consumed. dsh-permission-presets appends permission/preset through the same kind of path.

Reproduction (2026-09-11). Fork from a turn whose successor message is still queued → do not send anything in the child → toggle the approval policy once → the queue panel now shows the inherited message, and "Edit queued message" opens it with the full original text. Both Edit and Remove work from there. Sending a prompt first closes the window permanently.

What does not change. The root cause stands: fork()'s cut advance (commands.js L224–227) swallows agent/inbox/spliced (target: "next-turn"), so the child silently inherits a message the parent had already submitted and re-runs it as its own next turn — the same user message executing once in each session. The evidence in the original report (the three inheritedEventCount cuts 254 / 262 / 265, the start: 1 insertion proving the inherited item occupies FIFO index 0, the removedCount: 1, start: 0 consumption, and the cold projection's inbox row) is all unaffected. The fix proposals (A2: append a cleanup splice after agents.create(); A3: reject fork while the queue is non-empty; B: surface the state on both sides) are unaffected too.

What should change is the framing. The defect is better described as "the intervention window exists but is undiscoverable" than "there is no window". That arguably makes the visibility half more important, not less: the only way to reach the window is a permission toggle — an action that has nothing to do with the message you are trying to edit, and that no user would think to try. branchUnavailable still only covers "this turn has later nodes"; it does not cover "the queue still holds an unexecuted message".

[Robin1987China]

你强调的「没有任何干预窗口」是关键判断 —— 从子会话被创建到用户第一次提交之间确实没有可操作的时机，所以清理只能发生在 agent/created。我在 master 上复现并验证了这一点。

已验证的修复：dsh-plugin-fork-inbox-guard

• npm：https://www.npmjs.com/package/dsh-plugin-fork-inbox-guard
• 源码 / 复现记录：https://github.com/Robin1987China/dsh-plugin-fork-inbox-guard （docs/verification.md）

我在 master aa8262ec091 上用真实的 sessionController.fork()（不是模拟）做了端到端复现，再挂上修复重跑：

运行	子会话 pendingNextTurn	子会话自有事件	父会话队列
未挂插件	含父会话排队消息 id	[]	未受影响
挂上插件	[]	一条持久 agent/inbox/spliced { removedCount: 1, outcome: "canceled" }	未受影响

关键代码路径（与各位的定位一致）

• packages/api/session-controller/src/commands.ts:243-246 — cut 从 boundary.seq + 1 一直推进到下一个 turn/start，把区间内的 agent/inbox/spliced 一起扫进子会话 seed
• packages/api/session-controller/src/commands.ts:263-268 — 该前缀作为 seed 与 inheritedEventCount，并打上 meta.isSeeded: true
• packages/core/agent-loop/src/inbox.ts:27-56 — inboxProjectionDefinition 折叠日志里全部 splice，完全不看 inheritedEventCount；而 packages/core/session/src/index.ts:607 其实已经在切点写了 session/end-seed { inherited: true } 标记，只是投影没读它

插件怎么修

在 agent/created 时，对 header.isSeeded 的会话，只重放 session.inheritedEventCount 之前的事件（按 inbox splice 规则折叠），得到「分叉那一刻正在排队」的精确 id 集合，再用 agent.inbox.remove(id) 持久地移除它们 —— 写入的是 agent/inbox/spliced，不是只改内存。子会话在切点之后为自己排队的新输入不受影响；非 seeded 会话一律不碰，所以 resume 回来的会话保留自己的队列。仓库里另有 12 个契约测试。

边界说明：这只是把解决方案打包成可挂载守护插件，不是上游补丁 —— bundle 补丁够不到 commands.ts 与 inbox 投影内部。真正的 upstream 修复仍应落在那处 cut 条件（或给 inboxProjectionDefinition 加 inheritedEventCount 判断）。在官方合入前，插件让现有部署立刻受益。

---

Verified fix: dsh-plugin-fork-inbox-guard

• npm: https://www.npmjs.com/package/dsh-plugin-fork-inbox-guard
• Source / raw reproduction transcripts: https://github.com/Robin1987China/dsh-plugin-fork-inbox-guard (docs/verification.md)

Reproduced end to end on master aa8262ec091 through the real sessionController.fork() (no mock), then re-run with the fix mounted:

Run	Child pendingNextTurn	Child own events	Parent queue
No guard	parent's queued id present	[]	intact
Guard mounted	[]	one durable agent/inbox/spliced { removedCount: 1, outcome: "canceled" }	intact

The relevant code paths are packages/api/session-controller/src/commands.ts:243-246 (the cut walks to the next turn/start, sweeping the agent/inbox/spliced into the seed), commands.ts:263-268, and packages/core/agent-loop/src/inbox.ts:27-56 (the projection folds every splice and never consults inheritedEventCount, even though packages/core/session/src/index.ts:607 already wrote a session/end-seed { inherited: true } marker at the cut).

The guard, on agent/created for a header.isSeeded session, replays only the events before session.inheritedEventCount, then durably removes exactly the identities that were pending at the cut. Input the child queued for itself after the cut is untouched, and non-seeded sessions are never touched.

Scope note: this is a mountable guard, not an upstream patch — a bundle patch cannot reach commands.ts or the inbox projection. The real fix still belongs in the cut condition above.

[Robin1987China]

补充：安装方式有更新。 这个修复现在也被 umbrella bundle dsh-community-fixes 收录 —— 它的目的就是免掉「每个修复各装一次、各挂一次」的麻烦：

dsh plugin --profile <你的 profile> add dsh-community-fixes

再把 dsh-community-fixes 加进该 profile 的 dsh.profile.bundles，一条线即可挂载全部已验证修复（每一个仍可在 profile 自己的补丁层里单独 disabled）。单独安装 dsh-plugin-fork-inbox-guard 依然有效。