Messages sent while a turn is running never become user turns: nothing renders in the transcript, and an attached image can be stripped before the message is queued

Messages sent while a turn is running never become user turns: nothing renders in the transcript (the send looks lost), and an attached image can be stripped before the message is queued

Environment

• Claude Desktop 1.30096.5 (macOS, Darwin 27.0.0, Apple Silicon)
• Claude Code 2.1.229 (binary spawned by CCD)

All timestamps below are UTC, as recorded in the transcript.

Summary

If you send a message while the assistant is mid-turn (running tools), the message reaches the model — but it is never written to the transcript as a user turn. It is persisted only as an attachment record of type queued_command. Nothing appears in the conversation: no bubble, no pending indicator, no error. The composer just empties. From the user's side the send looks lost, so you retype it, while the model has in fact already received it.

Separately, in one send out of the nine I captured, an image the user had attached was not carried with the message. The text went through, the image did not, and the user reported it reappearing in the composer afterwards.

Steps to reproduce

1. Ask for something that runs tools for a while.
2. While it is still working, type a message and press Enter.
3. Observe the transcript — and compare against what the assistant subsequently says.
4. Repeat with an image attached (paste a screenshot, then Enter).

Expected

The message appears in the transcript as a user turn, the way it does when sent between turns — ideally marked as queued/injected. Whatever the model receives, the user should see.

Actual

• Nothing renders. The composer clears and the transcript is unchanged.
• The model does receive the message.
• In one of nine captured sends, the attached image was not included.

Evidence

From one session transcript (~/.claude/projects/<project>/<session>.jsonl).

Queue accounting

queue-operation totals:  enqueue=24   dequeue=15   remove=9      (24 = 15 + 9)

The two paths are cleanly separable, and the books balance:

• the 15 dequeue operations each correspond to a human user record — these are sends made between turns, and they render normally;
• the 9 remove operations each correspond to an attachment record of type queued_command — these are the mid-turn sends, and none of the nine has a corresponding user record.

Side by side, one of each:

19:05:54.238  queue-operation  enqueue
19:05:54.272  queue-operation  dequeue
19:05:54.287  user             "依旧如此，"                <- between turns; renders

19:06:05.425  queue-operation  enqueue
19:06:07.679  queue-operation  remove
19:06:05.425  attachment       queued_command             <- mid-turn; no user record, nothing renders

(The attachment record is appended after the remove but carries the enqueue timestamp, so ordering by timestamp is not monotonic here.)

The model does receive them

Two independent checks, since "the assistant mentioned it later" is weak on its own in a session that was grepping its own transcript:

• The text of the 19:06:05 message first appears in the file in its own queue-operation / attachment records. The first assistant message to quote it verbatim is at 19:06:52, and every tool result before that point is free of that text — so it did not come from a file read.
• After the 18:41:25 mid-turn send (which carried two images), the assistant's reasoning at 18:41:42 describes the content of those screenshots. So images on this path reach the model too, when they are carried.

The nine mid-turn sends

timestamp     images  line chars  media types
18:41:25.030    2       90339     image/webp, image/png
18:53:12.641    1       65049     image/webp
18:53:56.433    1       19624     image/webp
19:06:57.570    1       82342     image/png
18:56:15.798    0         555
18:57:55.658    0         586
18:58:47.932    0         568
19:06:05.425    0         558     <- user had attached an image to this one
19:09:47.742    0         564

Four of the nine carried images without trouble, so this path clearly supports images. Of the five text-only records, four were genuinely text-only sends. The fifth, 19:06:05, is the defect: the user attached an image to it (they were sending a screenshot specifically so the assistant could look at it) and reported that after pressing Enter the image reappeared in the composer.

attachment.prompt is polymorphic

Text-only sends store a bare string; sends carrying images store an array of content blocks. Both shapes occur in this one session.

Carrying an image (19:06:57) — the array has exactly two elements, an image block and a text block:

"attachment": {
  "type": "queued_command",
  "prompt": [
    { "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": "<81656 chars>" } },
    { "type": "text",  "text": "…" }
  ],
  "commandMode": "prompt",
  "origin": { "kind": "human" }
}

The failing send (19:06:05) — prompt is a bare string despite an image having been attached:

"attachment": {
  "type": "queued_command",
  "prompt": "现在这个会话就是，我发了看不见",
  "commandMode": "prompt",
  "origin": { "kind": "human" }
}

One further data point on where the image is lost: queue-operation.content is null for sends that carry images (checked at 18:41:25 and 19:06:57) and a plain string for text-only sends. For the failing 19:06:05 send, the enqueue record already has content: "现在这个会话就是，我发了看不见" — i.e. by the time the message was enqueued it already looked like a text-only message. That places the loss at or before enqueue rather than in transport, though the transcript alone cannot pin down which component drops it.

I could not isolate a trigger for the image case — four sends in the same session carried images fine and only this one did not. A race between the paste finishing and Enter being pressed is a plausible guess, but I have not verified it, and this is a single failing sample.

Note on the rendering claim

I can show that mid-turn sends produce no user record and that nothing appears in the UI. I have not inspected the renderer, so "the transcript is drawn from user records, which is why these never appear" is my inference from the correlation, not something I verified.

Why this matters

The two defects compound. Because nothing renders, the user assumes the send failed and sends again — so the model receives the same instruction twice. And when the image is the message ("look at this screenshot"), the assistant answers about text alone while the user believes it is looking at a screenshot it never received.

Related

• #86614 — queued messages dropped mid-tool. Adjacent but distinct: there the message is genuinely lost; here it is delivered to the model, it just never becomes a visible turn.