session/fork inherits the next turn's inbox insert → phantom queued input in the child

[qf0421]

Summary

session/fork with an atSeq inside a non-final turn produces a child whose inbox contains a phantom queued input: the child inherits the parent's agent/inbox/spliced insert for the next turn's user message, but not the turn/start / inbox remove that consumed it. The child is idle (no turn starts on seed), so the queued item never runs and cannot be explained from the child's own transcript.

Version: @deepseek-ai/dsh 0.1.5-alpha.2 (dsh-api-session-controller).

Reproduction

1. Session with ≥ 2 completed turns, each started by a normal user message (inbox → turn).
2. session/fork { sessionId, atSeq: <seq of turn N's turn/end> } where turn N+1 exists.
3. Inspect the child: inheritedEventCount covers seq up to just before turn N+1's turn/start; the last inherited event is agent/inbox/spliced { target: "next-turn", inserted: [<turn N+1 user message>] }. The child shows one pending queued input and never runs it.

Concrete log tail from a parent (turn 10 → 11):

seq 188 turn/end            {turn: 10}
seq 189 command/run         permission
seq 190 command/done
seq 191 agent/inbox/spliced target=next-turn inserted=[user message for turn 11]   <- inherited
seq 192 turn/start          {turn: 11}                                              <- NOT inherited
seq 193 agent/inbox/spliced target=next-turn removedCount=1                         <- NOT inherited

Forking at atSeq: 188 yields a child with inheritedEventCount: 192 (seq 0–191), then session/end-seed, session/title.

Cause

packages/api/session-controller (lib/index.js, fork()):

const boundary = source.events.find(e => e.type === "turn/end" && e.seq >= atSeq) ?? ...;
let cut = SessionLogOffset(boundary.seq + 1);
while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut++;

Advancing cut up to the next turn/start is presumably meant to carry over inter-turn housekeeping (session/title, feedback/*, session/end-seed, command/*), but it also swallows the agent/inbox/spliced insert that precedes every user-initiated turn/start. Since the matching removal is emitted after turn/start, the child's inbox fold ends with an unconsumed item.

The same applies to a steer queued mid-turn N that is later promoted to turn N+1 (next-turn insert inside turn N, removal after turn/start N+1).

Expected

A fork through turn N should have an empty inbox. Either:

• stop the cut at boundary.seq + 1 and let housekeeping events be re-derived, or
• keep advancing but skip agent/inbox/spliced (allow-list only the housekeeping types), or
• after seeding, emit a compensating agent/inbox/spliced removedCount for any items the seed leaves pending.

Workaround (client side)

After fork, inspect the child's inbox projection and cancel inherited items, or send a new message (the phantom item runs first).

[argszero]

The diagnosis holds. Two things I can add: where it stands upstream (your version still has the advance loop; master does not), and one cross-line correction that changes how option 3 has to be written.

The loop is gone from master, and it is gone from 0.1.6-alpha.1 on

Your version ships exactly what you quote — I installed the published artifact and read it:

// node_modules/@deepseek-ai/dsh-api-session-controller/lib/index.js:684-685 (0.1.5-alpha.2)
let cut = SessionLogOffset(boundary.seq + 1);
while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1);

The same loop is in 0.1.5-alpha.1 and 0.1.5-rc.2 — all four published 0.1.5 releases. Master now has only the first line: packages/api/session-controller/src/commands.ts:243 is const cut = SessionLogOffset(boundary.seq + 1);, with the boundary chosen as the first turn/end at or after the anchor (:228-231). That change is f74d625e5a (merge of PR #4001, branch fix/session-fork-boundary), written up as .agents/notes/implemented/bug-fix/2026-09-11-session-controller-fork-turn-cut.md, and the first release containing it is 0.1.6-alpha.1 — its published controller has const cut = SessionLogOffset(boundary.seq + 1); and no loop. So your option 1 is what upstream did; your option 2 (an allow-list of housekeeping types) is the alternative that note rejects, on the grounds that an event-type exception still copies unrelated state changes after the selected turn and forces the controller to classify plugin-owned events.

If you are following #6314 — same mechanism, reported there from the client side on 0.1.5-rc.2 — the "master still has the loop as of 2026-09-13" claim in that thread is stale: the fix landed 2026-09-11.

What the fix deliberately leaves

The note is explicit: "Events already inside the selected prefix retain their ordinary replay semantics; this decision does not redefine pending input inserted before the selected closing event." So the case you report — input queued for the turn after the selected one — is closed for controller forks from 0.1.6-alpha.1, while input already pending inside the selected turn still replays: a followup() issued during it (send(msg, 'next-turn', true)) or a steer()/inject() parked in next-step when it ended. Two forks of the same session can therefore still differ by what was queued while the selected turn was running.

A cross-line correction that matters for option 3

"After fork, inspect the child's inbox projection and cancel inherited items" is not sufficient as written, because the inbox does not reconstruct from the same events on every line:

line	how the Agent builds its inbox	a seeded child's inbox
0.1.2-rc.1, 0.1.3-alpha.2	new Inbox(session, …) folding session.ownEvents() — the suffix after the inherited prefix	empty; the phantom never appears
0.1.5-*, 0.1.6-*	the inbox projection over the session's events	holds the inherited insert

I measured that with the real registry, the real agent factory and the real projections on all eight published lines, creating the child exactly as fork() does (seed + inheritedEventCount + meta.isSeeded) and reading the child's inbox before any plugin runs. On 0.1.2/0.1.3 the same copied prefix that produces your seq 191 shape leaves the child's inbox empty — the same prefix, two different children, decided by the inbox implementation rather than by the cut.

So a compensating removal has to be "the identities the child's inbox actually holds and the copied prefix explains": intersect the prefix fold with the public Inbox.nextTurn / Inbox.nextStep reads, and cancel only the intersection. Cancelling from the prefix fold alone would append a durable removal and announce a drop on a line where nothing was ever queued.

Option 3 is implementable with public API

The vantage is a documented invariant rather than a race: agent/created is dispatched inside AgentRegistry.create() before session/fork returns the child id, and AgentFactory.createAgent awaits serial listeners before releasing queued work. One caveat for anyone writing it — on 0.1.2–0.1.5 that event is an un-awaited emit dispatch carrying only { agent } (from 0.1.6 it is an awaited serial dispatch carrying source too), so the listener has to finish its work inline. Inbox.remove(messageId) then durably records one agent/inbox/spliced { outcome: "canceled" } per item, which is exactly your third bullet.

I packaged that as @argszero/cordis-plugin-fork-inbox-guard@0.1.0 — npm, MIT:

npm install @argszero/cordis-plugin-fork-inbox-guard

- insert:
    - id: fork-inbox-guard
      name: '@argszero/cordis-plugin-fork-inbox-guard'

It emits one durable notice at the child's first admitted step naming what it dropped (mode: observe reports without cancelling; announce: false cancels silently).

Source and the full evidence trail: https://github.com/argszero/cordis-plugin-fork-inbox-guard

To be clear about what it is: a compensating control, not the fix — it does not change what a fork copies. On 0.1.5 it covers the case you report; on 0.1.6 and later it covers only the carve-out above. Its evidence is 32 behaviour tests against a real @deepseek-ai/cordis context plus 14 packaging tests, the behaviour suite re-run against each published line from the registry with the installed versions asserted to equal the probed ones, and a real-harness probe per line answering control / subset / treatment / inertness — the per-line table is in the README.

[qf0421]

Thanks @argszero — confirmed on our side.

• Upgraded to 0.1.6-alpha.2 (not alpha.1: on the registry its sub-packages already resolve to alpha.2 via ^0.1.6-alpha.1, and dsh-agent@alpha.2 requires system-prompt ^0.1.6-alpha.2, so a plain alpha.1 install of a plugin package hits ERESOLVE). _forkSeed now cuts at boundary + 1 with no advancing loop — the next-turn phantom is gone.

• The inside-turn case is real for us: our client queues input during a running turn (session/updateQueue steer/remove), so a fork through that turn inherits the insert without its consuming splice. We compensate client-side rather than with a Host plugin: right after session/fork, open session/follow on the child with maxMessages: 1, read projections.values.inbox from the opening snapshot (in 0.1.6 the inbox is a durable wire projection, so no need to intersect prefix folds with reconstructed state — the Host hands you the effective pending lists), then session/updateQueue { kind: "remove" } for every id in next-turn and next-step. The Host records each as an outcome: "canceled" splice, so the cancellation is durable and any client fold drops the item. session/queue-item-not-found is treated as already done. A session that hasn't accepted a prompt can't legitimately hold pending input, so removing everything is safe. Same idea as your cordis-plugin-fork-inbox-guard, just done from the caller side for hosts we don't ship plugins into.

• Unrelated to the fork but worth knowing for anyone on this thread upgrading a hand-written typert contribution: 0.1.6 changed strict codecs from { schema } to { create: () => schema }. validateCodec rejects the old shape and the whole namespace silently never registers — no error surfaced at boot, only "no active Remote method exports this endpoint" at call time.

Happy to close this from my side once the inside-turn case has an upstream issue to track — do you know if one exists, or should I open it?