[FEATURE] Add option to rewind conversation without creating a fork

[Henry-Jessie]

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

The current rewind functionality (accessed via Esc + Esc or /rewind) automatically creates a conversation fork every time a user restores to a previous point. This design leads to rapid accumulation of conversation branches in the session history, especially when users frequently experiment with different approaches or need to backtrack due to errors.

This creates several problems:

1. History clutter: Each rewind operation adds a new fork to the conversation history, making it increasingly difficult to navigate and find specific conversations when using -resume.
2. No option for simple undo: Sometimes users just want to undo recent changes and continue from an earlier point without preserving the current branch. The mandatory fork means you can never truly "go back" - you're always creating a new parallel timeline.
3. Cognitive overhead: Users must mentally manage an ever-growing tree of conversation branches, even when many branches represent dead ends or experimental paths that are no longer relevant.

The current interface shows: The conversation will be forked but provides no option to opt out of this behavior. This is particularly problematic during iterative development where rewinding 3-4 times in a session quickly creates 3-4 unnecessary conversation branches.

Proposed Solution

Add a fourth option to the rewind menu that allows users to restore conversation state without forking. The enhanced rewind menu would look like:

❯ 1. Restore code and conversation
  2. Restore conversation only  
  3. Restore code only
  4. Restore conversation only without forking (discard current branch)

When option 4 is selected:

• The current conversation state from the rewind point onwards is discarded
• The conversation continues directly from the selected checkpoint
• No fork is created in the history
• This behaves more like a traditional "undo" operation

Alternatively, this could be implemented as a modifier or flag:

• A prompt asking "Create a fork? (Y/n)" before executing the rewind
• A configuration setting: rewind.autoFork: true/false in .claude/config.json
• A command-line flag: claude --no-fork-on-rewind

Alternative Solutions

Current workaround: I have to manually track which fork is the "main" conversation thread and ignore the accumulated branches, but this becomes unwieldy after multiple rewind operations in a single session.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Scenario: Debugging a complex refactoring task

1. I'm working with Claude to refactor a module, building up 30-40 minutes of valuable context about the codebase
2. Claude suggests an approach using async/await and implements it (checkpoint A)
3. I realize this approach has issues, so I use rewind to go back and try a different pattern
   • Current behavior: Fork is automatically created, now I have 2 conversation threads
4. The second approach also doesn't work, I rewind again to checkpoint A
   • Current behavior: Another fork is created, now I have 3 conversation threads
5. I try a third approach, which finally works
   • Current behavior: I now have 4 different conversation forks in my history, but only one is actually relevant

With the proposed feature:

• At step 3, I select "Restore without forking"
• The failed async/await attempt is discarded
• At step 4, I again select "Restore without forking"
• The second failed attempt is discarded
• My session history remains clean with only the successful path preserved
• When I use --resume later, I see a single coherent conversation thread instead of multiple dead-end branches

This is especially valuable during exploratory coding sessions where I might rewind 5-10 times before finding the right solution.

Additional Context

Technical considerations:

• This feature should be optional and configurable to preserve backward compatibility for users who prefer the current fork-always behavior
• The default behavior could remain unchanged to maintain existing UX expectations
• Clear warning/confirmation for the destructive operation would be important for user safety