[Bug] fork 会继承源会话 fork 点的下一条输入，新会话第一次输入执行的是它

[MObBBBBBB]

[Bug] fork 会继承源会话 fork 点的下一条输入，新会话第一次输入执行的是它

以下内容由我发现并书写要点，由 deepseek v4.1 flash 结合历史记录总结并润色得来。

环境：DSH Desktop 0.1.5-rc.2（桌面端构建，web profile）/ Windows 10

现象

从会话中间 fork 出新分支后，源会话 fork 点的下一条输入会被新会话一起继承，并在新会话第一次输入时被执行 —— 我看到的不是自己刚发的那句话对应的回答，而是「先跑了另一段 prompt」。我真正发的那条被挤到它后面，进入排队队列。

触发条件只有一条：fork 点不在最后一条消息上。 与源会话是否出错、是否卡死，以及那条输入在源会话里是否已经执行过，全都无关（后两点我都在桌面端实测确认过）。

我被迫补发说明、或直接终止该轮才能把会话拉回来；而 fork 最需要被用到的场景恰恰是最容易落在会话中间的场景。

实际经过（含事件证据）

原谅我无法附上我的对话历史，下面是 AI 总结的事件记录。

事件序号 / 时间轴来自两个会话的 session.v3.jsonl.zstd。

源会话（0a77ac23 的父会话）：

时间	seq	事件	说明
09-19 09:22:00	2292	turn/end turn 52（completed）	会话正常收尾，进入空闲
09-20 15:56:29	2293	session/end-seed	我在源会话仍处于空闲时做过一次 fork
09-20 15:57:34	2294	agent/inbox/spliced target=next-turn	我发出下一条输入，进入排队队列 —— 本条证据的起点
——	——	（此后源会话再无 turn/start）	这次它没被执行；但按实测，执行过也一样会被带
09-20 16:36:28	2295	session/end-seed inherited:true	我在这时又 fork 了一次

fork 出来的新会话（0a77ac23，即「dsh 基础介绍与用法」）：

时间	seq	事件	说明
09-20 16:39:30	2297	agent/inbox/spliced target=next-turn start=1	我发出第一条新消息（说明这条分支的来历）
09-20 16:39:30	2298	turn/start turn 53	这一轮开始
09-20 16:39:30	2299	agent/inbox/spliced 移除 1 条	排队队列被清了一次
09-20 16:39:30	2301	user/message	执行的却是源会话 seq 2294 的那条输入
09-20 16:39:33	2307	agent/inbox/spliced target=next-step	我真正发的那条说明，这时才被重新注入
09-20 16:39:36	2314	user/message	它才落定

两条消息的 rpcId 完全相同 —— seq=2301 的 user/message 与源会话 seq=2294 的 agent/inbox/spliced 都是 9b475cc4-b958-4917-8a98-acbc3a727ec1。这不是我重复发送，而是同一条输入被跨会话执行了。

机制

fork 会把源会话在 fork 点上的输入队列一起复制，其中包含 fork 点之后加入的那条输入 —— 无论它在源会话里是否已经被消费。新会话第一次输入触发轮次启动时，队列里那条先于新输入被取出执行，新输入则要再等一次队列处理才落定（上表 seq 2299 → 2307）。

所以这不是「残留未消费队列」的问题。 上表那条输入在源会话里确实没被执行过，但我复测发现，即使一句输入在源会话里已经正常执行完，fork 之后它仍会被带过去。按「未消费」来描述是错的，准确的说法是：fork 复制输入队列时，把 fork 点之后的输入一并复制了。

影响

• fork 作为恢复手段不可靠。 fork 最常见的用途是「上一个会话坏了，从坏点之前分叉继续」，而这个动作天然落在会话中间 —— 也就天然会带上后面那条输入。
• 我看到的结果是错乱的。 新会话第一轮回答的是一个自己没打算在这里问的问题，会以为发错了、或以为 fork 没生效。
• 补救动作又被搅一次。 我补发的说明不会立刻生效，还要再被队列的取消 / 重新注入逻辑处理一遍（上表 seq 2299 → 2307）。

建议

1. fork 时不要继承 fork 点之后的输入。 新会话应只继承 fork 点之前已经落定的历史，排队队列从干净状态开始。
2. 若出于设计必须保留，至少在 fork 完成时提示：fork 点的下一条输入被带上了、来自什么时间点、将如何处理。
3. 轮次结束时，把这一轮没有取用的排队输入明确交还给用户（重新排到队首，或提示已丢弃），而不是让它继续留在队列里 —— 它留在原会话也许无害，一旦被 fork 复制就会在新会话里被执行。

我这边可以做的

我不是 DSH 的开发者，只是碰到这个问题的用户。但如果方向被认可，我可以尝试改一下 fork 的输入队列复制逻辑（也就是让 fork 时不再把 fork 点之后的队列条目复制进新会话）。

我能定位到相关代码路径并给出草案，但需要熟悉这块实现的人确认设计意图 —— 因为"fork 应该继承多少状态"可能是有意为之的取舍，我不想凭空猜。

按官方贡献指南，目前不接受外部 PR，所以我会把这些以补丁 / 思路的形式发在 Discussions 里，直接提交 PR 就不必了。需要的话我可以先交一份最小验证（怎么稳定复现、以及改动前后的事件对比）。不保证效果。

相关

• 我遇到这个问题的场景：内容审核 400 会永久废掉整个会话 —— 需要「撤销被拒内容并继续」的回滚能力。那个 issue 里 fork 是唯一可用的恢复手段，而本 issue 说明这个手段本身也不干净。
• Discussion #4952 — Follow-ups queued during an active turn are never admitted after the turn ends
• Discussion #465 — 中止运行后，已被 claim 进当前轮的队列消息不会被重新排队
• Discussion #728 — Subagent 返回的消息会出现在主对话框的排队队列中

以上三条覆盖的都是「队列结算」，没有一条覆盖 fork 继承 —— 本 issue 的新意是「输入队列被跨会话复制」。

[argszero]

Your diagnosis is correct, and the cause is one line of code — which also means this is already fixed upstream. Details below, in the order that makes the fix obvious.

1. The mechanism, one line

0.1.5-rc.2's SessionCommandController.fork picked the log prefix to copy like this (packages/api/session-controller/src/commands.ts):

let cut = SessionLogOffset(boundary.seq + 1)
while (cut < source.events.length && source.events[cut]?.type !== 'turn/start') {
  cut = SessionLogOffset(cut + 1)
}

boundary is the selected turn/end; the loop then walks the cut forward, over every between-turn event, until it meets the next turn/start — or, if there is no next turn/start, to the end of the log. That second branch is exactly your case: the source session was idle, no further turn ever started, so the cut ran to the log tail and swept in the agent/inbox/spliced insertion at seq 2294.

The tail copy exists because between-turn state (title, model selection) was meant to travel with the fork. But a pending input is durable state committed to the log before the turn/start that consumes it, so that same window contains the input's insertion while its claim/removal happens inside the next turn — which the loop stops before. The seed therefore carries an insert with no removal, and the child rebuilds its inbox from the copied prefix: one pending entry, addressed to the source session's next turn. The child's own first message is spliced behind it (start=1 in your table), the turn starts, the inherited entry is claimed first, and it is what the model is asked to answer.

Your correction to your own wording is also right, and for the same reason: the loop only ever looks at event types. It cannot know whether the input was consumed in the source, so "whether it had already run" genuinely does not matter — the insertion is copied either way. "Unconsumed queue" is the wrong description; "the cut advances past the selected turn/end" is the right one.

2. Why "don't copy the queue" is the right conclusion but the wrong placement

Upstream fixed it at the cut, not at the queue:

const cut = SessionLogOffset(boundary.seq + 1)

Your suggestion 1 states the outcome this produces; the placement is what matters, and the design note records why the two queue-side shapes were rejected:

• Stop only at the next inbox event — an event-type exception still copies unrelated state after the selected turn and would force the controller to classify plugin-owned events.
• Copy the tail and clear the child's inbox — clearing adds child events to cancel input that lies outside the requested prefix, while still inheriting other state from after the selected turn.

So the rule became: no event after the selected closing event belongs to the seed — queued input, titles and model settings alike.

3. It is already fixed, and your build is the last one before the fix

Three commits on 2026-09-11 (Dudu-0223), merged as PR #4001 (f74d625e5a):

• 896a6c3e47 fix(session): stop forks at the selected turn end (first cut at it)
• 0f8552df7f fix(session): retain fork tail until the first inbox change (intermediate)
• 973bea8204 fix(session): use the selected turn end as the fork cut (the version that shipped — it deletes the advance loop)

Design record: .agents/notes/implemented/bug-fix/2026-09-11-session-controller-fork-turn-cut.md. Its Problem section is your report, stated in the same shape: "Extending a completed-turn fork through the following between-turn events can copy the next input's insertion without its later removal."

Tag containment, verified per tag:

tag	date	contains the fix
dsh-v0.1.5-rc.1 / rc.2	2026-09-10	no
dsh-v0.1.6-alpha.1	2026-09-15	yes (first release)
dsh-v0.1.6-alpha.2	2026-09-17	yes

Your build was cut the day before the fix. The regression vector added with it is your scenario almost literally — packages/api/session-controller/tests/session-fork.host.spec.ts completes a turn, appends a queued input with source.inbox.append('next-turn', message('B')), forks with the omitted / past-end anchors, continues the child with C, and asserts the child's user messages are exactly ['A', 'C'] and inheritedEventCount === boundary + 1. On 0.1.5-rc.2 that vector cannot pass; on the 0.1.6-alpha.x line it does. The Web branch-action snapshot covers the same seed through the UI path.

4. What to do, and what is honestly still open

Upgrade to a 0.1.6 build and re-run your event comparison — the child's first turn should contain only your own first message. Two caveats worth attaching to that:

• The prefix-internal case is deliberately not redefined. The note's Consequences say it outright: "events already inside the selected prefix retain their ordinary replay semantics; this decision does not redefine pending input inserted before the selected closing event." Input inserted before the selected turn/end — a mid-turn followup() landing next-turn, a steer()/inject() parked in next-step when the turn ended — still replays into the child on 0.1.6 too. Since you report that an already-executed input is also carried, the decisive evidence for a follow-up is the seq comparison: whether the inherited agent/inbox/spliced insertion sits below or above the seq of the selected turn/end. Above the cut belongs to the fixed case; below it is the by-design remainder, and a fresh report with that one comparison would be a genuinely new data point rather than a re-report.
• For pre-fix builds, a stopgap exists. 0.1.5-rc.2 desktop builds (and every published 0.1.5) still carry the loop, so we published @argszero/cordis-plugin-fork-inbox-guard@0.1.0 for exactly this symptom: mounted on the public agent/created event, it replays the child's inherited prefix with the same agent/inbox/spliced fold, intersects that with the child's live inbox (Inbox.nextStep / Inbox.nextTurn), and cancels the intersection identity by identity through Inbox.remove — never a blanket clear() — leaving one durable user-role notice naming what it dropped. That is the compensating-removal shape of your suggestion 3, applied to the child; it is a stopgap for older builds, not an alternative to the cut fix, and it needs a plugin mount.

5. Related threads

#7118, #6314 and #7175 are the same mechanism reported earlier (different builds, different session shapes) — worth checking so these converge instead of multiplying; #7118 is the one the note's decision is traceable against.

One note on your "相关" section: for the moderation-400 case you cite as making fork the only way out, the recovery no longer has to go through fork. @argszero/cordis-plugin-content-exists-risk@0.1.0 targets it directly — the provider's original rejection message still rides in the terminal error frame of the stream (only the error code is flattened to a generic INVALID_REQUEST), so the rejected content can be identified by message and re-sent with adjacent-character spacing: it changes what is sent, never what is stored, and the log keeps the original record. Mentioning it only because your report's motivation was that fork was the sole escape hatch from a poisoned session.

[MObBBBBBB]

是我粗心，报之前没看最新版本。不过我这边不打算切alpha，alpha太不稳定，等0.1.6出rc再更新。等rc更新我尝试之后再看问题有没有消除，之后再看这个贴子怎么处理，谢谢你的指正。

[Darkfeast-x]

0.1.7-alpha.2 依然存在

[Darkfeast-x]

遇到这个bug后问的ai

Q:
https://github.com/deepseek-ai/deepseek-harness/discussions

比如一个会话中有5轮对话 我从第2轮分支出新的会话 但是新的会话会附带第3轮的

查找有无类似的问题

A:
有，而且找到了与你描述几乎一致的反馈，不止一条。

最相关的讨论

讨论	与你遇到的问题的对应关系
#7309：fork 会继承源会话 fork 点的下一条输入，新会话第一次输入执行的是它	最贴近你的情况：从会话中间分支，新会话会带上分支点的下一条用户输入。作者明确表示，即使那条输入在原会话里已经执行完，也仍会被带过去。报告环境是 Windows 桌面端 0.1.5-rc.2。
#6749：“在新对话分支”会把原对话分支点之后的输入回放，是 bug，还是可以调？	给出了直观例子：原历史为 [q1,a1,q2,a2]，从 a1 分支，看起来只有 [q1,a1]；但输入新问题 q3 后，却先重放 q2，再处理 q3。
#7118：session/fork 继承下一轮输入，导致子会话出现幽灵排队消息	有事件日志和代码分析：从第 N 轮分支时，错误地复制了第 N+1 轮用户输入的入队事件，却没有复制它后续的出队事件。

为什么会多带一轮？

根据上述讨论中的分析，旧实现不是严格复制到“第 2 轮结束”，而是继续复制到“第 3 轮开始之前”。

第 3 轮用户输入的入队事件，恰好记录在第 3 轮正式开始之前，因此被一起带进新会话。你发送新消息后，它可能先执行原来的第 3 轮输入，把你的新消息挤到后面。

所以这些报告主要涉及的是多带入下一轮的用户输入，并可能重新执行，不一定是直接复制了下一轮完整的问答。

修复状态

• 据 #7309 的回复，该切点问题已在上游修复，首个包含修复的版本是 0.1.6-alpha.1；0.1.5-rc.2 尚未包含。
• #7118 的报告者 确认，升级到 0.1.6-alpha.2 后，“多带下一轮输入”的问题消失。
• 但还有一个区别：如果消息在所选轮次结束前就已排队，它仍可能随分支继承；该讨论指出，这种情况不在上述切点修复的覆盖范围内。

结论：你的现象已有高度一致的报告。优先看 #7309 和 #6749；是否已被你当前版本修复，还需要核对版本，以及第 3 轮输入是在第 2 轮结束前还是结束后提交的。