[BUG] Windows: "Waiting for input" banner on New Session — dismissing it removes the source session from Recents (data survives on disk but is hidden)
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?
Banner disappears, but session A is simultaneously removed from the Recents sidebar.
Restarting the app does not restore it to Recents.
Session A's .jsonl transcript under ~/.claude/projects/<project-hash>/<session-A-id>.jsonl remains fully intact on disk — only the UI listing is affected.
What Should Happen?
Dismissing the "waiting for input" banner should not delete or hide the originating session from Recents. The banner's × button should only dismiss the notification itself, not affect the session it refers to.
If hiding/archiving the session on dismiss is intentional behavior, there should at minimum be a way to restore it from the UI — currently the only way to recover it is via claude --resume <session-id> from a terminal, which most users would not discover on their own.
Error Messages/Logs
Steps to Reproduce
Have an active session mid-conversation (session A).
Click "New Session" while session A is still open.
A notification bar appears: the session you navigated away from is waiting for your input.
Click "New Session" again — same banner reappears.
Click the × (dismiss) on the banner.
<img width="1857" height="146" alt="Image" src="https://github.com/user-attachments/assets/db8fc5a8-2c16-4439-9562-4aab54529cec" />
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Latest Claude Desktop, but Claude Code version is 2.1.187.
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
No data loss confirmed — claude --resume <session-id> loads the session fine. This is a Recents-listing bug, not a persistence bug.