[BUG] Queued message is dequeued while a tool call is still in flight and silently discarded — no user record, no UI signal (2.1.227 desktop; distinct from the turn-end variant #85603)

Environment

• Claude Code 2.1.227 (also reproduced on 2.1.219), entrypoint claude-desktop
• macOS (Darwin 27.0.0)

Summary

A message typed while a tool call is in flight is popped from the prompt queue (queue-operation / dequeue) while the tool is still running, and is then discarded — no user record is ever written, the model never sees it, and the UI shows nothing. The session continues normally afterwards, so there is no crash, no disconnect and no turn boundary to blame. The user's only recourse is to notice the silence and retype.

This is distinct from the already-known turn-end variant (#85603, #82772): here the queue is popped mid-tool-execution, not at end_turn, and no Stop hook is involved.

Cleanest specimen (session c092ebf7, 2.1.219, 2026-08-04)

A docker buildx Bash call was in flight from 06:58:21 and did not return until 07:06:45.

06:58:21.257  assistant   tool_use  Bash              <- in flight from here
07:04:37.593  queue-operation enqueue  "why is this taking so long"
07:06:35.346  queue-operation dequeue                 <- tool STILL running
                                                      -- text never appears again in the file
07:06:38.945  queue-operation enqueue  "is it stuck"
07:06:43.062  queue-operation dequeue                 <- tool STILL running
                                                      -- text never appears again in the file
07:06:45.092  user  tool_result
07:06:45.093  user  [Request interrupted by user for tool use]
07:06:46.831  queue-operation enqueue  "is it stuck"  <- user types it a THIRD time
07:06:46.831  queue-operation dequeue
07:06:46.835  user  "is it stuck"                     <- only this one lands
07:07:08.236  assistant  "Not stuck - that was a docker buildx run, takes a few minutes,
                          you interrupted it."

The queue was empty before each enqueue, so the enqueue→dequeue pairing is unambiguous. The user typing the identical text three times, and the assistant's reply only addressing the third, is independent behavioral confirmation that the first two never reached the model.

Still present on 2.1.227 (session 3f887417, 2026-08-14)

05:57:20.884  assistant  tool_use  Bash (a `gh run list` polling loop)   <- in flight
06:01:32.425  queue-operation enqueue  "any progress?"
06:02:25.809  queue-operation dequeue        <- tool still running; text never appears again
06:02:30.444  queue-operation enqueue  "/compact"
06:02:34.085  user  tool_result  is_error  (interrupt)
06:02:34.091  queue-operation dequeue
06:02:34.096  user  <command-name>/compact</command-name>   <- this one lands

Why this is a drop and not a user-initiated cancel

queue-operation has a third operation, remove, which is what a user-cancelled queue entry produces — and it carries the content field:

{"type":"queue-operation","operation":"enqueue","timestamp":"…21.375Z","content":"btw, …"}
{"type":"queue-operation","operation":"remove", "timestamp":"…23.490Z","content":"btw, …"}

The same desktop sessions log remove frequently (c092ebf7: 462 enqueue / 368 dequeue / 94 remove; 3f887417: 76 / 56 / 20), so removal is recorded distinctly in these builds. Every case reported here is enqueue → dequeue with no remove, and the text appears nowhere else in ~/.claude/projects/ — not as a user record, not inside any compaction summary, not in any other session file.

Frequency

Reconstructing the queue FIFO across every local session transcript (excluding slash commands and <task-notification> payloads):

• 5829 plain-text queued deliveries
• 21 silently dropped (0.36 %), across 12 distinct sessions, 2026-07-02 → 2026-08-14, several unrelated project directories, all entrypoint=claude-desktop, versions 2.1.197 → 2.1.227

Classifying each drop by whether a tool_use was still open at the moment of the dequeue splits them cleanly into two shapes:

| shape | tool in flight at dequeue | stop_hook_summary right after | count | newest build |
|---|---|---|---|---|
| A — this report | yes | no | 8 | 2.1.227 |
| B — turn-end | no (lag ≈ 0 s) | yes | 8 | 2.1.222 |

Shape B matches #85603 / #82772 and is not the subject of this report; I mention it only so the two are not conflated. Shape A's newest occurrence is on 2.1.227, i.e. after #82772 was closed.

Expected

A dequeued message must either be delivered or be visibly retained in the queue. Popping it while the turn cannot accept it, and discarding it, loses user input with no signal in the UI and no trace in the transcript beyond an orphaned dequeue.

Related

• #85603 — turn-end variant (end_turn, Stop hooks fired), TUI. Same outcome, different trigger point.
• #82772 (closed 2026-08-01) — instant enqueue→dequeue→nothing, VS Code extension. Shape B locally stops after 2.1.222, consistent with that fix; shape A does not.
• #73118 — queued messages lost on disconnect. No disconnect here; the session continues normally.
• #71726 — feature request for mid-turn injection. Orthogonal: the problem is not that delivery waits, it is that the message is removed from the queue and dropped.