[BUG] /rewind interactive picker stops accepting keyboard input in 2.1.118
Status Fixed / completed
Reported on v2.1.118
Maintainer reply ✓ Yes — mhegazy
Workaround ✓ Mentioned in thread ↓
Activity 5 comments · opened Apr 23, 2026 · closed Apr 23, 2026
💡 Likely answer: A maintainer (mhegazy, contributor)
responded on this thread — see the highlighted reply below.
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?
The /rewind command's interactive picker renders but does not respond to any keyboard input after updating to 2.1.118. Was working correctly on 2.1.117.
What Should Happen?
Expected behavior: Picker accepts keyboard input and allows selecting a checkpoint to rewind to.
Actual behavior: Picker renders but is completely unresponsive to input.
Error Messages/Logs
Steps to Reproduce
- Run claude code in terminal
- Have a conversation with some history
- Type /rewind and press Enter
- Interactive picker appears but ignores all keyboard input (arrow keys, Enter, Escape)
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.117
Claude Code Version
2.1.118
Platform
Claude Code
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Environment:
- Claude Code: 2.1.118
- Terminal: Kitty
- OS: Linux
- Shell: bash/zsh
5 Comments
Same here on iTerm2. Plus the terminal tab becomes unusable. Only option is to close it.
This is a meaningful regression because
/rewindis one of the explicit recovery/control commands users reach for when they need to navigate session history safely. If the picker renders but accepts no keyboard input, the visible control exists without being operable.That is worse than a missing feature because it invites the user into an interaction that cannot complete. The 2.1.117 → 2.1.118 regression note is also valuable: this sounds like a focus/input-handling break rather than a conceptual problem with the command itself.
In practice, a dead interactive picker turns a recovery mechanism into a trap surface. The user can see the rewind UI, but cannot actually use it.
Adding a launch-path bisection from my repro (Windows 10, VS Code integrated terminal, CC 2.1.118, bash/Git Bash):
| Launch method | Rewind behavior |
|-|-|
|
claude→/resume(picker from inside TUI) | Works ||
claude --resume <session-id>(explicit id) | Works ||
claude --resume(no id, launch-time picker) | Input deadlocked |Same underlying session file in all three cases. Only the bare-flag launch-time picker path breaks Rewind.
--resume <id>hydrates the session without ever showing the launch-time picker and is fine;/resumefrom inside a running TUI is also fine. So the bug is specific to the--resume-with-launch-picker startup path, which suggests the launch-time picker hydrates the session before the TUI input loop is fully wired and leaves the keypress handler in a bad state that only surfaces once Rewind is opened.Combined with #52329's
CLAUDE_CONFIG_DIRbisection (trigger lives in~/.claude.json, not session-history size), this narrows the repro further: it's the launch-picker path reading~/.claude.jsonstate during session hydration.Workaround until fixed: resume with an explicit id (
claude --resume <session-id>) or launch bareclaudeand use/resumefrom inside. Skip the bare--resumepicker.Thanks for reporting. Fix should be in tomorrows release.
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.