Rewind UX: code+conversation rewind should not be default and needs confirmation
Status Closed — not planned
Maintainer reply None cached
Activity 7 comments · opened Feb 21, 2026 · closed May 15, 2026
Problem
The rewind feature currently defaults to reverting both conversation history and file changes. This is a dangerous default — an accidental click silently reverts working code with no warning or confirmation dialog.
Steps to reproduce
- Use Claude Code and make file changes during a session
- Click the rewind button
- The first/primary option reverts both code and conversation — easy to trigger unintentionally
Expected behavior
- Rewind conversation — first/default option (low risk, only affects chat history)
- Rewind code + conversation — secondary option, behind a confirmation such as: "This will also revert changes to N files. Are you sure?"
Impact
Users can lose working code they intended to keep, thinking they were only rolling back the chat. The destructive option being the easiest to trigger is a real footgun — especially for users newer to the rewind feature who may not realize the distinction.
Having "rewind everything" as the default is roughly equivalent to putting rm -rf as the first option in a context menu. The safe action should be the default; the destructive action should require explicit confirmation.
Thank you kindly.
7 Comments
Strong +1, and I want to add a specific failure mode not yet mentioned: the menu options shift position depending on context.
When there are no code changes to restore, the destructive options disappear and the numbering collapses. This means a user who builds muscle memory around "press 2 for conversation-only" will occasionally hit the wrong option when the menu renders differently. The positions are contextual, but the finger habit is not.
Personally, I use source control for all code rollbacks — I never want Claude Code to revert my files. My ask would be some form of config or user preference option.
The current UX punishes users for building habits, which is the opposite of how a frequently-used menu should work.
+1 (also submitted feedback)
Just got bit by this AGAIN. What a silly default.
This event should be gated to prevent accidental user action, and should confirm their intentions before proceeding. Or at least provide a way to undo such a destructive action.
This feature is very poorly-implemented.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This was closed as not planned but the underlying footgun is still present as of v2.1.159: "Restore code and conversation" remains the default rewind action and applies on
Enterwith no confirmation and no blast-radius preview. I've filed a fresh, consolidated report with reproduction steps and concrete implementation avenues (confirmation gate, reordering the default, a settings flag, a rebindable/disableable Esc Esc, and an env-var stopgap) in case it can be re-triaged: #64615.Yep. Turns out a problem doesn't fix itself just because a GitHub Actions bot closes the issue as stale.
I haven't been bitten by it lately, but boy is it a bad UX decision to make.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.