session/undo and session/redo requests

[r1bilski]

Since the operation of undo and redo involves rewriting history by removing or appending user messages in the conversation, it's not really possible to implement it through simple commands.

A solution would be to have session/undo and session/redo requests that would require the client to remove / append user's message after a successful response.

[htahaozlu]

Following up on this since it's been quiet. I think undo/redo can be expressed as a thin client-side layer on top of a more general rewind primitive, rather than as its own protocol surface.

Concretely, if the protocol provides session/rewind { sessionId, toMessageId }, a client wanting undo/redo UX keeps its own stack of (sessionId, messageId) pairs and calls session/rewind to move between them. The agent doesn't need to track an undo/redo stack itself, which keeps its state model simple and avoids ambiguity around what "redo" means after the user has typed a new prompt post-undo.

This also unifies a few scattered conversations:

• Discussion #239 — "Restoring a checkpoint and an earlier point in the conversation"
• This thread — session/undo and session/redo
• The use case behind editing a previously sent user message and re-running

All three reduce to "discard messages after a chosen point, optionally with a fresh prompt at the new tail." A single session/rewind method (plus an session/edit_prompt convenience for the edit-and-re-run case) covers them.

I've drafted an RFD along these lines, and I left a longer comment on #239 with the proposed shape. If others here agree this consolidation makes sense, I'll roll the redo concern into the RFD's FAQ and credit this thread for the prompt.

If you specifically need an agent-side undo/redo stack (e.g., for an agent that has internal state changes beyond the user-visible conversation), that would be a different proposal and worth a separate RFD.