Session transcript orders mid-turn user messages after the assistant reply, inverting authoring order

What's wrong

When a user sends one or more messages while the assistant is still generating a turn (thinking / composing / running tools), those messages are delivered to the assistant mid-turn — but in the recorded session transcript (.jsonl) they are ordered after that turn's assistant reply, even though they were authored before the reply was emitted. The transcript's linear order therefore doesn't reflect authoring chronology.

(Filed via gh rather than the issue form, so the template fields are inline below.)

Steps to reproduce

1. Start a session and ask for something that takes a while to respond (a long reasoning task, or a multi-step tool-using task).
2. While the assistant is still working, send one or more follow-up messages.
3. Let the turn complete, then open the session transcript (.jsonl).
4. Inspect the ordering of those follow-up messages relative to the assistant reply.

Observed

The follow-up user messages appear after the assistant's reply, despite being authored during the assistant's turn (before the reply was emitted). With a burst of several messages, the relative user/assistant ordering is scrambled. The assistant does receive them mid-turn (surfaced as "user sent a new message while you were working"), so nothing is dropped — the issue is purely the recorded order.

Expected

Transcript ordering should reflect authoring/receipt time: a user message authored during a turn should appear before the assistant reply emitted after it.

Likely mechanism (inferred)

The assistant turn appears to be committed to the transcript at the position where it began (pinned to turn-start), so when it's emitted it lands before any user message authored during that turn.

Impact

• The transcript is the source of truth for reconstruction. Tools that read it chronologically — summarization, memory-consolidation / replay, audits — mis-attribute timing and causality (a reply can appear to precede the message it was responding to).
• Users reading back their own session see their comments appearing after replies they actually preceded — confusing.
• Any "what was said in what order" analysis over the log is unreliable for turns with mid-turn input.

Suggested fixes

1. Transcript ordering (log side): order events by authoring/receipt timestamp rather than turn-start position — or record per-event timestamps so consumers can re-sort.
2. Reply-to-anchor (UI / input side): the per-reply menu already offers Fork conversation / Rewind code — add a "Reply to this message" entry alongside them that anchors a reply to that specific message inline (no fork, no rewind, conversation stays linear). The message then carries an explicit anchor, so grouping and ordering become deterministic instead of inferred from timing. Reuses the existing menu — a small addition, not a new UI.

Environment

• Claude Code — VS Code native extension anthropic.claude-code v2.1.177 (darwin-arm64); bundled claude --version reports 2.1.161
• VS Code 1.123.2 (commit 3c631b164c239e7aeaaae7c626b46c527b361af2)
• Platform: Claude subscription (OAuth)
• OS: macOS, Apple Silicon (arm64)
• Terminal: VS Code integrated terminal (bash)
• Regression: not sure (haven't confirmed behavior in earlier versions)

Related

• #54031 — "Queued-message ordering is undocumented and appears LIFO in practice" (closed; nearest cousin, about processing order)
• #62311 — "Distinguish an explicit user interrupt (Esc) from a message that merely arrived mid-turn" (open)
• #52509 — "Messages typed during Thinking aren't delivered until Escape" (open)

This issue is specifically about the recorded transcript order — mid-turn user messages logged after the reply — which those three don't cover.