[BUG] Messages queued during a running turn are lost when the session exits and is resumed

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

If I type a message while a turn is running, it is queued ("Press up to edit queued messages"). If the Claude Code process then exits before that message is taken into a turn, and I resume the same session with claude --resume <session-id>, the message is gone: it is not shown as queued, the input box is empty, and it is not sent with the next message I submit.

The text is still on disk. The session transcript has a queue-operation record with operation: "enqueue" and the message in content, and no later dequeue or remove record for it. In the reproduction below, after the resume no further record refers to it.

A message from another local session (SendMessage) is lost the same way. In two tests against a local mock of the Messages API returning a captured weekly-limit 429, I saw this with a session waiting in the usage-limit retry wait (CLAUDE_CODE_RETRY_WATCHDOG=1): the peer message was queued and shown as › Message from @<sender>: …, the session was exited with /exit and resumed, and the message was gone (twice). The sender had been told the message was "in that session's inbox, not yet read by its Claude" and received no later notice.

What Should Happen?

A queued message that was never delivered should still be queued after a resume, since the transcript already records it.

I understand that a resume deliberately does not start a model turn on its own, and I am not asking for that to change. The message could stay queued (visible, and editable with Up as usual) and be sent with the next message I submit, rather than being auto-submitted at startup.

This would match the 2.1.285 fix for Remote Control messages ("losing a message still queued when the terminal quit (it now arrives on the next resume)") and the related 2.1.286 fix.

Error Messages/Logs

# Simplified records from the reproduction below (contents shortened):
{"type":"queue-operation","operation":"enqueue","timestamp":"...","content":"kiwi queued message: ..."}
# the process exits here; `claude --resume <session-id>` follows; one more message is sent and answered
# after this, no further queue-operation records and no delivery of the kiwi message

Steps to Reproduce

1. In an empty scratch directory, start claude.
2. Send a message that makes one long reply with no tool calls, for example: Without using any tools, write a 1200-word essay on the history of tide clocks.
3. Within a few seconds, while the reply is still being written, type kiwi queued message: reply with the word kiwi and press Enter. It shows as queued ("Press up to edit queued messages").
4. Before the reply finishes, end the process from a second terminal: ps -o pid,tty,command -ax | grep '[c]laude', pick the pid on the first terminal's tty, then kill -TERM <pid>. Claude Code prints claude --resume <session-id> as it exits.
5. Run that claude --resume <session-id> in the scratch directory.
6. Observe: no queued message is shown and the input box is empty. Send Reply with only the word ok.; it is answered, and the kiwi message is never delivered.
7. Optional: in the session's .jsonl under ~/.claude/projects/, the kiwi text appears once, in a queue-operation enqueue record, and no later record refers to it.

Notes: a reply that calls tools is not a good test, because a queued message is taken into the running turn at the next tool step (it then appears as delivered). The original typed-message occurrence and the controlled typed reproduction were both ended with SIGTERM and then resumed with claude --resume <id> in the same terminal. For the typed case I have not tested /exit, Ctrl+D, Ctrl+C or claude --continue; the peer case above was exited with /exit.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.291 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

The steps above were run with Haiku 4.5 against the real API, in a tmux pane, on 2.1.289 and again on 2.1.291 with the same result. The first occurrence was in Terminal.app: a longer-running session that exited on 2.1.285 and was resumed on 2.1.289, with two queued messages that Claude Code restored neither of (a script ended and resumed that session, and later pasted their text back in itself).

A limited look at the 2.1.289 bundle did not find where queue-operation records are read back on resume. I did not trace that path fully, so treat it as a pointer only.

I have not tested earlier versions and do not know whether this is a regression.

Related, on other surfaces: #97042 (desktop app, queued prompts deleted when the app closes) and #77010 (web, queued messages lost on session switch). A companion report, #100004, covers a message that had already become a user turn; this one covers messages that were never taken off the queue.