[Bug] Mid-turn messages stored as queued_command attachments disappear after app restart

Bug Description
Messages sent mid-turn (queued while Claude is working) disappear from the transcript after an app restart Summary If I send a message while Claude is still working on the previous turn, the message renders in the conversation as expected and Claude does receive and act on it. But after quitting and reopening the desktop app, that message is gone from the transcript — no bubble, no trace in the UI. The rest of the conversation is intact; only the mid-turn messages vanish. The data is not lost. It is on disk in the session transcript, but stored under a different record type than a normal user message, and the UI's rehydration path appears to only rebuild bubbles from type: "user" records. Steps to reproduce 1. Send a prompt that takes a while (long tool-using turn). 2. While Claude is still working, send another message (text and/or an image). 3. Observe: the message appears in the conversation, and Claude responds to it. Correct. 4. Quit the app (Cmd+Q) and reopen it, then open the same session. 5. The mid-turn message is no longer displayed anywhere in the transcript. Expected The message is my turn in the conversation and should be restored on reload, like any other user message. Actual It is visible only in the live session. After a restart it is not rendered at all — the transcript reads as if I never sent it, and Claude's reply to it has no visible prompt. Evidence from the transcript file In ~/.claude/projects/<project>/<sessionId>.jsonl, a normal message is written as {"type":"user", "message":{"content":[...]}}. A mid-turn message is instead written as: {"type":"attachment","attachment":{"type":"queued_command","prompt":[{"type":"image",...},{"type":"text","text":"..."}]},"timestamp":"...","parentUuid":"..."} The text and any attached images are fully preserved there. It is only the display that drops it. Note the record is attached to a tool_result line with the same timestamp, rather than existing as its own user turn. This is not new or version-specific. Across my own history I found 41 sessions containing such records, spanning 2026-07-04 to 2026-08-01 and app versions 2.1.197 through 2.1.220 — the same pattern throughout. Of those queued records, roughly half are real messages I typed and half are system-generated notifications, which suggests the record type is shared between user input and internal events. Impact - The conversation becomes hard to follow on re-read: Claude answers something that is not visible, so the reasoning looks unprompted. - Anything that consumes these transcripts (exports, archives, tooling, my own scripts) silently misses those turns unless it specifically knows to read queued_command attachments. In my case 49 of my own messages were missing from a local archive I build from these files, and I only noticed by accident. - Mid-turn messages are often the important ones — corrections and course changes sent precisely because the current turn is going the wrong way. Suggestion Either render queued_command attachments as user turns when rebuilding a session, or write the queued message as a normal type: "user" record once it is delivered, so that the on-disk shape matches what actually happened in the conversation. Environment - Claude Code 2.1.220 (sessions observed on 2.1.197 – 2.1.220) - Claude desktop app on macOS 26.5.2 (Apple Silicon) - Reproduced consistently, not a one-off

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.220
• Feedback ID: a323d788-1515-482c-ab42-39675364a8ee

Errors

[]