Ability of Claude-Code for draft text to persist when switching between chats
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
When working across multiple chats simultaneously, I frequently switch between them to manage different tasks or contexts. If I've started typing a prompt in one chat and switch to another before submitting, the in-progress text is silently discarded. When I return to the original chat, my draft is gone with no warning or recovery option.
This happens in a natural multitasking workflow: start composing a prompt → realize I need to check or handle something in another chat → switch over → come back → draft is lost. The interruption itself is normal; losing the work is not.
The result is that I either have to submit incomplete prompts just to "save" them, keep a separate text editor open as a scratch pad, or re-type from memory — all of which break focus and add friction to an otherwise fast tool.
Proposed Solution
When I return to a chat where I had started typing but not submitted, my draft text should still be there — exactly as I left it. No extra UI, no buttons, no opt-in: just the input field retaining its content per-chat across navigation.
Ideally:
Each chat maintains its own independent draft state.
The draft persists as long as the session is open (tab/window not closed).
If the app is closed and reopened, restoring the draft would be a bonus but is not essential — session-level persistence is the minimum.
No confirmation or save action required from me — it should be automatic and invisible.
The interaction should feel identical to how browser address bars or most messaging apps (Slack, WhatsApp, Telegram) handle unsent text: you leave, you come back, it's still there.
Alternative Solutions
Alternatives considered:
Submitting a placeholder message (e.g., ... or hold) just to preserve context — but this pollutes the chat history and wastes a turn.
Keeping a separate text editor or sticky note open as a scratch pad for in-progress prompts — works but adds friction and breaks focus.
Copying the draft to clipboard before switching chats — easy to forget, and the clipboard only holds one thing at a time.
Avoiding multitasking across chats entirely and finishing one prompt before switching — not always practical when the workflow genuinely requires context-switching.
None of these are satisfying. They all require conscious extra effort to work around what should be automatic behavior. The core issue is that the workaround has to be remembered and executed before switching — but the need only becomes obvious after returning and finding the draft gone.
Priority
Medium - Would be very helpful
Feature Category
Interactive mode (TUI)
Use Case Example
_No response_
Additional Context
Similar features in other tools:
Slack — each channel/DM maintains its own unsent draft automatically; visible with a "Draft" label in the sidebar.
Telegram / WhatsApp — switching between conversations always preserves unsent text in each chat's input field.
Gmail — unsent replies are auto-saved as drafts per thread without any user action.
These are all standard expectations for any multi-conversation interface.
Technical considerations:
Draft state only needs to be stored in memory (per session), not persisted to disk — keeping it lightweight and avoiding any privacy concerns around unsubmitted text.
Each chat already has a unique ID/session handle, so keying draft state to that identifier should be straightforward.
No new UI surface needed — the existing input field behavior is all that changes.
Constraint worth noting:
This is specifically observed in the VS Code extension environment (Claude Code running inside VSCode on Windows 11). Behavior may differ in the CLI TUI or the web app — those haven't been tested for this specific issue.
<img width="1244" height="993" alt="Image" src="https://github.com/user-attachments/assets/aab97774-2274-4738-b6f5-80bbd5d66ba3" />
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗