Mid-turn user messages lack reply-target identity — crossed replies are unattributable in orchestration-heavy sessions

Problem

Claude Code models a conversation as a single linear turn stream. User messages sent while a turn is running are spliced into the running turn (surfaced alongside the next tool result) with no identity and no reply-target reference. In sessions with long-running background agents, user replies race with task notifications and streamed assistant output — producing "crossed replies": an utterance that answers assistant state N arrives at state N+1, and neither the model, the user, nor the transcript can express which state it responded to.

Reproduction sketch

1. Start a session; launch one or more background agents (Agent tool, run_in_background).
2. While the assistant is mid-turn (streaming, or between a task-notification turn), send a short corrective message.
3. The message is surfaced mid-turn as an annotation to the running turn.
4. If the assistant's response and the user's next message cross, there is no way to establish which assistant message the user was replying to.

Observed repeatedly in a single multi-hour orchestration session with parallel background agents — a user message was composed before seeing the assistant's latest state, but was indistinguishable in the transcript from a reply to it.

Impact

• The model cannot disambiguate crossed replies at inference time — misattribution risk on corrective/approval messages, which are exactly the highest-stakes user utterances in agentic sessions (approvals, "stop", scope corrections).
• Transcript-mining tooling (session-history analysis, decision/intent recovery) cannot recover reply edges; adjacency is the only heuristic and it is wrong under concurrency.
• Interface artifacts compound it (e.g., Ctrl+C's dual clear-input/interrupt meaning depends on the same invisible turn state).

Request

Message identity and a reply-target edge in the transcript format itself (e.g., message IDs in the session JSONL plus an optional reply_to field for user messages), with a minimal CLI affordance to set it, so both the model and downstream tooling share the structure.

Anticipated responses, addressed

• "Threading exists in Discord/other surfaces" — session-level or community-level threading does not address in-conversation message identity; the failure is within a single session's turn stream.
• "Use the desktop/companion UI" — the transcript format is the only substrate shared by every consumer (headless CI, SDK harnesses, --agent sessions, SSH terminals); an optional surface does not fix the conversation model. A UI-layer fix leaves the transcript flat, so the model still cannot see reply structure — it decorates the problem rather than fixing it.

Related issues

Found during duplicate search — none is a full match, but flagging for triage:

• #68756 — closest match. Reports the recorded transcript order of mid-turn user messages being inverted relative to authoring order, and separately proposes a "Reply to this message" UI anchor as one candidate fix. That issue's core defect is ordering/timestamps in already-captured data; this issue is about the absence of any identity/reply-target field in the data model at all, with emphasis on the model's real-time inference-time disambiguation (not just post-hoc transcript reading).
• #63190 — proposes deferred/queued messages (hold mid-turn input until end of turn). A different mitigation; doesn't address attribution once a message is delivered mid-turn, and crossed replies can still occur across ordinary turn boundaries.
• #58336, #49179 (closed as duplicates) — general "message threading / reply anchoring" feature requests, without the concurrency/misattribution framing specific to orchestration-heavy agentic sessions.

Environment

• Claude Code 2.1.207
• OS: macOS 26.5.2 (Darwin)