[Bug/hardening] Invalid mid-step session seeds survive agents.create and break TokenMeter replay

[iiijiashu]

Environment and symptom

• DSH Desktop 0.2.1-rc.2, Windows x64, v4 Zstandard JSONL sessions.
• The local custom dsh-session-admin 0.1.3 plugin implements /rewind using events.slice(0, cut) and agents.create({seed, inheritedEventCount: cut}). It can cut just before a user message within an open step. The official buildForkSeed already closes incomplete steps; the plugin currently bypasses it. We are fixing the plugin separately.
• A low-level seeded Session nevertheless accepted and persisted the malformed history. Subsequent TokenMeter replay fails with:

token meter: step/start at seq 2600 arrived before turn 8/step 1 ended

Anonymized event evidence

# Child A
2592 turn/start       turn=8
2594 step/start       turn=8 step=1
2595 session/end-seed inherited=true
2598 turn/start       turn=9
2600 step/start       turn=9 step=1  <-- throws
2601 step/end         turn=9 step=1
2602 turn/end         turn=9 reason=error

# Child B forked from child A
2550 step/start       turn=6 step=1
2551 session/end-seed inherited=true
2554 turn/start       turn=7
2556 step/start       turn=7 step=1  <-- throws again

The parent logs have matching closing events after the copied fork boundary. Two seeded children fail and a third has a similar open-step cut in a local scan. Only structural event metadata is included here; no conversation text, personal paths, or credentials.

Upstream hardening request

Current packages/core/session/src/fork.ts provides buildForkSeed(events, boundary) and adds synthetic step/end / turn/end. This report does not attribute the bug to stock session/fork; the entry point was third-party plugin code that called the lower-level constructor directly.

Please consider:

1. Validating step/turn balance across session/end-seed in seeded Session.create / agents.create, failing early with an actionable error.
2. Providing a documented safe low-level API for seeding from arbitrary event boundaries, or exposing the correct buildForkSeed usage prominently to plugin authors.
3. Adding regression tests for open-step cuts, in-flight tool calls, repeated rewind/fork, persisted replay and TokenMeter.
4. Documenting an authorized recovery path for already affected child histories without discarding messages.

See fork.ts and session README.

I can supply a synthetic minimal fixture if helpful.

[PerryLink]

Verified on 687f282e86 (0.2.1-rc.2), and the asymmetry you found is real: the closer exists, is exported, and is simply not enforced at the boundary.

The helper does exactly what you say

packages/core/session/src/fork.ts is 31 lines; :21-29:

export function buildForkSeed(events: readonly SessionEvent[], boundary: SessionSeqType): SessionEvent[] {
  ...
  return prefix.concat(openTurnClosers(prefix, { kind: 'forked' }))
}

:29 is openTurnClosers from packages/core/session/src/repair.ts:53 — the same function crash recovery uses (interruptedTurnClosers, :209, is a thin wrapper over it). So the closing logic is one shared routine, and buildForkSeed is a convenience wrapper around slice + that routine. Bypassing it bypasses the only thing that closes the tail.

It is also already public: packages/core/session/src/index.ts:27 re-exports buildForkSeed. So the plugin had a supported way in and did not use it — your separate plugin fix is the right primary action.

What the seed boundary does and does not check

packages/core/session/src/index.ts validates a seed per event, never as a sequence:

• :203 / :217 / :228 — event envelope shape
• :230 — validateSessionEventData(...)
• :253 / :258 / :263 / :266 — request/header fields
• :275 — assertMessageEventShape(...)
• :292 — settlement fields
• :306 / :313 — adapterDefaults

Every one of those is "is this event well-formed". Nothing asks "is the tail closed". So a seed ending immediately after step/start passes creation cleanly, gets persisted, and fails later — which is exactly the shape of your two children: the malformed history is durable, and the error only appears when something replays it.

The replay error is the one you quoted

packages/llm/token-meter/src/index.ts:268-271:

token meter: step/start at seq ${event.seq} arrived before turn ${state.stepStart.turn}/step ${state.stepStart.step} ended

with siblings at :280 (step/end … has no matching step/start) and :297 (assistant/message … has no matching step/start). All three are replay-time, after the bad log is already on disk.

Where a guard would go

The cheapest hardening is at seed ingestion, reusing what is already there: run openTurnClosers(seed, ...) over the borrowed prefix and, if it returns any events, either reject the seed (INVALID seed: open step/turn at inherited boundary) or append the closers the way buildForkSeed does. One function call, no new vocabulary — and it converts "silently accepted, fails on the next replay" into "rejected at creation, with the offending seq named".

Rejecting is probably the better default. Auto-closing a caller's arbitrary prefix hides the caller bug you just fixed, and the seed boundary is the last place where the caller is still identifiable.

One thing worth stating in the report

The inheritedEventCount value is not the problem by itself — the malformed prefix is. A guard keyed on the seed content covers both the plugin case and any future caller that assembles a prefix by hand, including ones that pass a correct count over a wrong boundary.