v2.1.201: turn/message desync with background agents — assistant turn starts before queued message delivery; queued user message silently removed

Environment

• Claude Code 2.1.201 (regression appeared immediately after claude update from 2.1.198; all sessions below ran on 2.1.201 within the following ~90 minutes)
• Linux WSL2 (6.6.87.2-microsoft-standard-WSL2), CLI entrypoint, permissionMode: default

Summary

After updating to 2.1.201, three consecutive sessions in the same project showed progressively worse message-delivery / turn-sync corruption whenever background agents (Agent tool, run_in_background) + queued user messages were involved. Evidence below is from the session .jsonl transcripts (timestamps preserved; sanitized excerpts available on request).

1. Assistant turn starts before the triggering message is dequeued

A background agent finished and its task-notification was enqueued at 22:33:16. The assistant was only woken 15 minutes later, and the transcript records, in this order:

assistant (thinking)  ts=22:48:04.353
assistant (thinking)  ts=22:48:14.260   <- file order AFTER the dequeue line below, timestamps out of order
queue-operation dequeue ts=22:48:25.110
assistant text        ts=22:48:25.059  "…waiting for the verification result"
user (task-notification) ts=22:48:25.128

The assistant produced its reply before the notification content landed as a user line, so it answered blind ("still waiting for the result") even though the result had been queued 15 minutes earlier.

2. Queued user message silently removed

While the assistant was mid-turn, the user typed a short message:

{"type":"queue-operation","operation":"enqueue","timestamp":"...T23:12:32.802Z","content":"<short user message>"}
{"type":"queue-operation","operation":"remove","timestamp":"...T23:15:22.962Z"}

The message never appears as a user turn anywhere in the transcript. From the user's perspective, their input vanished without a trace. The remove coincides to the second with an unrelated Write tool call in the assistant's ongoing turn.

3. Out-of-order timestamps in the transcript

See block in (1): line order assistant(22:48:04) -> dequeue(22:48:25.110) -> assistant(22:48:14).

4. Phantom task artifact with garbled name

The session's tasks dir contains byshsdhyy.output (garbled name, not the usual agent-id format, hardlink count 2) whose content is a full copy of a project file that a subagent had read. No corresponding tool call, task id, or notification exists in the transcript.

5. Same version, earlier session: permission prompts auto-interrupted

In the immediately preceding session, every tool permission prompt was interrupted right around the approval keypress (recorded as request-interrupted each time), making the session unusable. The session was abandoned after 4 minutes.

Downstream effect (why this matters)

With inputs delivered late / out of order / dropped, the model started answering the wrong turns and confabulating to reconcile the inconsistent history: it claimed the user said "continue" (they hadn't — no such turn exists), and later claimed it had launched a subagent ("I started X, waiting for completion") when no corresponding tool_use exists anywhere in the transcript. One assistant message also contained stray Cyrillic characters ("фе") mid-Japanese-text. The user's live experience was multi-minute dead air, replies mismatched to their messages, and finally an unrecoverable session.

Repro context (not minimal, but consistent)

• Startup command that launches a background subagent via the Agent tool, while the user (voice-typed input) sends additional messages before the notification is consumed.
• 3 sessions in a row on 2.1.201 exhibited some subset; the last one all of 1-4.

Happy to provide sanitized transcript excerpts (queue-operation lines, system turn_duration lines, tasks-dir listing) on request.