[FEATURE] Show which actions /rewind cannot undo

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

Checkpoints restore files that Claude edited, so rewind feels like a complete undo. But some actions in the same stretch of the session are not reverted:

• git commit and git push
• files changed through Bash rather than the edit tools
• database migrations, package publishes, deploys
• MCP tools with side effects (creating a Jira issue, sending a message, writing to an API)

After rewinding, the conversation and my local files say "this never happened", while the remote branch, the database or the issue tracker say it did. Nothing in the UI warns me about the difference.

Proposed Solution

1. Classify each tool call as reversible (edits covered by checkpoints) or not reversible:

• Bash commands that write outside checkpoint tracking or talk to the network, such as git push or npm publish.
• MCP tools not marked readOnlyHint: true. MCP tool annotations already include readOnlyHint and destructiveHint, so servers can declare this themselves.

1. Mark it in the rewind picker. Turns containing irreversible actions get a marker. Choosing a point before them lists what will not be undone:

> Rewinding past this point will not undo:
> • git push origin feature/login (3 commits)
> • 2 files changed by Bash (scripts/gen.sh)
> • mcp__jira__createIssue → PROJ-412

1. Optional extra confirmation when rewinding past a destructive action.

Alternative Solutions

• Remembering what happened: this works in short sessions, but not after a long or compacted one.
• PreToolUse hooks that log side effects: possible, but the rewind UI can't show those logs, which is where the information is needed.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. Claude implements a change, commits, pushes, and opens a ticket through an MCP tool.
2. I don't like the approach and rewind to before the implementation.
3. The picker warns me that the push and the ticket will remain.
4. I rewind anyway, and then ask Claude to force-push the branch back and close the ticket. Without the warning, a stale branch and a wrong ticket would have stayed behind unnoticed.