[FEATURE] Add PostRewind hook event — plugins lose state consistency on /rewind

Resolved 💬 2 comments Opened Mar 17, 2026 by Glucksberg Closed Apr 14, 2026

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)
Note: This was previously discussed in #18858, which was auto-closed by the stale bot and then locked before it could be reopened. Resubmitting with the same context.

Problem Statement

When a user runs /rewind, the conversation state rolls back — but no hook event fires. This means any plugin that tracks session activity (memory, timeline, audit, analytics) is left with "ghost" records that reference messages and tool calls that no longer exist in the active thread.

Concrete example with claude-mem:

  1. User submits a prompt → UserPromptSubmit fires → plugin records the prompt
  2. Claude responds with tool calls → PostToolUse fires → plugin records observations
  3. User runs /rewindnothing fires → plugin still shows the now-undone activity
  4. The user's timeline/history now contains entries for work that was erased

There is no reliable way to detect this from the plugin side. The conversation state changed, but the plugin was never notified.

Proposed Solution

Add a PostRewind hook event (analogous to PostToolUse, UserPromptSubmit, etc.) that fires after /rewind completes:

export type PostRewindHookInput = BaseHookInput & {
    hook_event_name: 'PostRewind';
    user_message_id: string;        // The message ID that was rewound to
    rewound_message_ids: string[];   // IDs of messages that were undone
    files_changed?: string[];        // Files affected by the rewind
};

The SDK already has SDKControlRewindFilesRequest internally, so the rewind context is already being tracked — this just needs to be exposed as a hook event.

Alternative Solutions

| Approach | Problem |
|----------|---------|
| Poll the transcript file | Race-prone, inefficient, transcript format is not stable |
| Ask users to manually notify the plugin | Poor UX, nobody will remember |
| Detect via missing tool_result | Unreliable, doesn't cover all rewind scenarios |

A proper hook event is the clean, reliable solution that fits the existing architecture.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

  1. A user is working with a memory plugin (claude-mem) that records observations from each tool call
  2. The user makes a mistake and runs /rewind to undo the last few turns
  3. Today: The plugin still shows the undone observations — confusing, potentially causing the model to reference stale context
  4. With PostRewind: The plugin receives the hook, soft-deletes the affected records, and the timeline stays consistent

This applies to any plugin maintaining state: memory systems, audit logs, analytics dashboards, session replays, etc.

Additional Context

  • Previous discussion: #18858 (auto-closed by stale bot, then locked)
  • The existing hook infrastructure (UserPromptSubmit, PreToolUse, PostToolUse, Stop) already covers the lifecycle — /rewind is the only state-changing operation without a corresponding hook
  • As the plugin ecosystem grows, this gap will affect more authors

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗