Queued prompts which are sent and queued after there are no available tokens for the current session, are deleted when the desktop app closes, even though draft (not sent) prompts survive

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Hello,

I'd like to report a problem with the Claude desktop app (Code tab, Windows 11 Pro) that cost me two to three hours of work.

What happened

On the night of 24 to 25 September 2026 I had reached my usage limit, which was due to reset at 03:10 (Europe/London). At about 01:00 I queued two long prompts in one of my Code conversations, so that they would run as soon as the limit reset. They were detailed instructions covering many changes to a project I am building.

At 02:00 Windows restarted for a scheduled update. I schedule updates for that hour precisely so they don't interrupt anything important which at the time I was working with Claude I had not realised there is a pending Windows update. When I reopened the app in the morning, both queued prompts were gone. They were not in the conversation, not in the prompt box, and not recoverable anywhere.

What I found afterwards

With Claude's help I checked the conversation records and the app's local storage:

The prompts were never written to disk. The conversation file shows nothing between the last reply at 23:49 and the next morning. The app held them only in memory, and the restart deleted them.
Pressing Enter made my text less safe than leaving it unsent. Text sitting in the prompt box survives a restart, because the app keeps it as a draft. But once I pressed Enter to queue it, the draft was cleared and the text existed only in memory. I pressed Enter precisely to keep it safe.
The app can already recover from a restart in a different case. In another conversation that night, a job was cut off mid-way by the usage limit at 23:55. When I reopened the app at 07:49, it automatically resumed that conversation with "please try again". So an interrupted session survives a restart, but prompts queued while already at the limit do not.

Thank you,
Adam Statyris

Proposed Solution

What I'm asking for

Save queued prompts to disk the moment they are queued, and keep them until they are actually delivered (or allow them to be sent to the server and queue there until tokens are reset).
When the app reopens, restore any undelivered queued prompts and send them, or at least show them, the same way an interrupted session is already resumed.
Show queued prompts in the conversation as "queued, not sent yet", so it is clear they have not reached the conversation.

This is plain text and should cost almost nothing to store, but losing it is very costly. Thank you for your understanding.

Alternative Solutions

Allow queued prompts to be sent to the server and queue there (instead of the local computer) until tokens are reset.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_