Forking a running session replays its pending prompt in the child

[antst]

In DSH 0.1.5-rc.2, forking a running source session at its latest completed
turn does not produce a child containing only that completed history. The
child also inherits the inbox insertion for the source's in-progress prompt
and begins answering that prompt.

Reproduction

1. Create a session and complete one turn.
2. Submit a second prompt to a model backend that remains running long enough
   to invoke another SessionController operation.
3. Call sessionController.fork with atSeq equal to the first turn's
   turn/end sequence.
4. Inspect the child session before submitting any child-specific prompt.

Actual: the child contains the second prompt's agent/inbox/spliced insertion
and starts a turn for it. The caller cannot clear the inherited item before it
runs because the child id is returned only after agent creation and
publication. A caller intending to ask an isolated side question therefore
gets an unwanted answer to the source's open prompt first.

The fork code selects the completed boundary at
packages/api/session-controller/src/commands.ts:225-242, then advances its
cut from turn/end + 1 until the next turn/start at commands.ts:243-245.
That range includes the durable inbox insertion immediately before the open
turn. The whole prefix is passed as the child seed at commands.ts:257-275.
Agent-loop reconstructs inbox state from that seed while creating the child at
packages/core/agent-loop/src/index.ts:764-800, and publishes the prepared
agent before returning at index.ts:824-828.

Expected: SessionController should support an exact completed-boundary fork
that excludes later inbox splices. This could be an explicit fork option, or
the running-source case could stop the seed at the selected turn/end rather
than advancing across pre-turn inbox events.

Target: DSH Discussion (Bug)

[argszero]

Your report is accurate, precisely cited, and — for the version you tested — already fixed. Three things worth having: the fix that landed (with the version boundary), the window the fix deliberately leaves open, and a plugin that covers that window plus older releases.

1. The code you cited is the pre-fix shape; it changed on 2026-09-11

At dsh-v0.1.5-rc.2 (tagged 2026-09-10) packages/api/session-controller/src/commands.ts reads exactly what you describe:

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

At HEAD (ddefc45fbc) the loop is gone and the cut is the closing event itself:

const cut = SessionLogOffset(boundary.seq + 1)

That change is 973bea8204 "fix(session): use the selected turn end as the fork cut" (Dudu-0223, 2026-09-11 15:09 +0800), the third of a three-commit sequence with 896a6c3e47 and 0f8552df7f, and it comes with a design note: .agents/notes/implemented/bug-fix/2026-09-11-session-controller-fork-turn-cut.md. Its Problem paragraph is your bug report in one sentence — "Extending a completed-turn fork through the following between-turn events can copy the next input's insertion without its later removal."

Version boundary: the fix is in dsh-v0.1.6-alpha.1 (2026-09-15) and dsh-v0.1.6-alpha.2; it is not in dsh-v0.1.5-rc.2, which predates it by a day. So if you retest on a 0.1.6 line, steps 1–4 should already behave as your "Expected".

Your second proposed shape is the one that landed ("the running-source case could stop the seed at the selected turn/end rather than advancing across pre-turn inbox events"). The note also records the alternative the maintainers considered and rejected — "Copy the tail and clear the child's inbox" — with a reason worth knowing before proposing it again: "Clearing adds child events to cancel input that lies outside the requested prefix, while still inheriting other state from after the selected turn." A side effect of the chosen shape, which the note states plainly: the seed now also excludes later titles and model settings, not only queued input.

2. The fix closes the between-turn window. The during-turn window stays open — same symptom

The note's Consequences carve this out explicitly: "Events already inside the selected prefix retain their ordinary replay semantics; this decision does not redefine pending input inserted before the selected closing event."

That is reachable, and it is a one-line change to your reproduction. The durable inbox splice is written at submit time, not at claim time:

ReactLoopAgent.followup   packages/core/agent-loop/src/agent.ts:137
  → send                  :128   this.inbox.splice(resolvedTarget, Infinity, 0, [message])
  → ReactLoopInbox.splice packages/core/agent-loop/src/inbox.ts:167  → mutate
  → session.append('agent/inbox/spliced', …)   inbox.ts:235

So a prompt submitted while the selected turn is still running is appended at a seq below that turn's turn/end, i.e. inside cut = turn/end.seq + 1. The child's inbox is reconstructed from that prefix exactly as in your case, and the child answers it first. Where your repro waits for the first turn to complete before submitting, the residual case submits during it and forks at that same turn/end.

Honesty about evidence: I verified this by reading the sources above, not by running it — the machine I had gives me a source checkout without node_modules, so no execution. Treat §2 as a source-level reading; §1 is a diff between two tags.

The existing coverage matches the carve-out: packages/api/session-controller/tests/session-fork.host.spec.ts:92-135 parametrizes all four anchors (message, turn-end, omitted, past-end) and asserts the next input is excluded, but every vector appends B only after await source.whenIdle(), or via source.inbox.append between turns. Nothing appends B mid-turn. If a maintainer wants the residual pinned as intended behaviour (or as a bug), that is the missing vector — and it would make the note's carve-out an executable fact rather than prose.

3. A plugin, for the residual window and for pinned versions

For anyone on ≤ 0.1.5-rc.2, or hitting §2: @argszero/cordis-plugin-fork-inbox-guard (npm i @argszero/cordis-plugin-fork-inbox-guard) works on the child side. It registers a synchronous agent/created handler, folds the copied prefix (session.inheritedEventCount — the same number the fork passes as cut) over agent/inbox/spliced to derive which identities the prefix explains, intersects that set with the child's live inbox, durably removes the intersection, and leaves a transcript notice naming what was canceled and from which parent.

Two things about it that matter here. The gate is session.header.isSeeded (guard() in src/index.ts), and sessions.fork sets isSeeded: true in the child's meta (commands.ts:259-268) — so fork children are covered, not only subagent seeds. And the race at agent/created is winnable because the framework awaits serial agent/created listeners before releasing queued work (packages/core/agent/src/index.ts:175-176, awaited at :547) — which is also why "the caller cannot clear the inherited item before it runs" holds for a caller after fork returns but not for a creation-time listener.

Scope, stated plainly: upstream's seed-side fix is the better shape and the note explains why; this plugin is a mitigation for (a) releases that predate it and (b) the §2 window, not a competing design. On 0.1.6-alpha.1+ it is correctly a no-op for the between-turn case, because the prefix no longer contains that splice. Ignore it if it does not apply to your setup.

[antst]

Confirmed on 0.2.1-alpha.2: the fork cut uses the selected turn end (dsh-session buildForkSeed, lib/index.js:925-934); the residual case, a prompt spliced before that turn's turn/end, still replays, so our client keeps refusing /btw during a running turn. Thank you.