Feature Request: Add redoable parameter to control permanent message deletion after revert #4681

Problem Statement

Currently, the OpenCode SDK provides session.revert() and session.unrevert() methods for reverting messages, but reverted messages remain in the session history and can be restored. There are use cases where we need to permanently delete messages after reverting them, without the ability to restore them later.

Current Behavior

// Current API only allows reverting (hiding) messages
await opencodeClient.session.revert({
  path: { id: sessionId }
});

// Reverted messages can always be restored
await opencodeClient.session.unrevert({
  path: { id: sessionId }
});

Proposed Solution

Add an optional redoable parameter to the revert API that controls whether the message should be permanently deleted or just reverted:

// Proposed API with redoable parameter
await opencodeClient.session.revert({
  path: { id: sessionId },
  body: {
    redoable: false  // When false, permanently delete the message after reverting
  }
});

API Specification

Request Body Schema

interface RevertRequestBody {
  redoable?: boolean;  // Default: true (current behavior)
  // When true: Message is reverted but kept in history (can be restored)
  // When false: Message is permanently deleted after reverting
}

Behavior Details

1. When redoable: true (default):

   • Current behavior is maintained
   • Message is marked as reverted in session state
   • File changes are reverted using Git
   • Message can be restored using session.unrevert()
   • Session maintains revert state with messageID, snapshot, and diff

2. When redoable: false:

   • Message is first reverted (file changes rolled back)
   • Message is then permanently removed from session history
   • No revert state is maintained in the session
   • session.unrevert() has no effect (nothing to restore)
   • Frees up memory/storage by removing message content

Use Cases

1. Privacy/Security: Permanently remove messages containing sensitive information that was accidentally shared
2. Session Cleanup: Remove failed attempts or experimental messages to keep session history clean
3. Memory Management: For long-running sessions, permanently delete old messages to reduce memory footprint
4. Compliance: Delete messages that may contain data that must be purged per regulatory requirements

Implementation Considerations

• Ensure Git operations complete successfully before permanent deletion
• Consider adding a confirmation mechanism for permanent deletions in the TUI
• Update event system to emit appropriate events (message.deleted vs message.reverted)
• Document that permanent deletion is irreversible

Related Issues

• Add a way to delete message parts and messages in the sdk #3033 - Add a way to delete message parts and messages in the SDK
• [bug] /undo removed the last message, but didn't revert the code edit. #2642 - /undo removed the last message, but didn't revert the code edit
• Undo command doesn't allow editing reverted message like keyboard shortcut #3901 - Undo command doesn't allow editing reverted message like keyboard shortcut
• feature: ability to rewind #338 - Feature: ability to rewind

Backwards Compatibility

This change is fully backwards compatible:

• The redoable parameter is optional with a default value of true
• Existing code using session.revert() without the parameter continues to work as before
• Only clients explicitly setting redoable: false get the new behavior

Alternative Approaches Considered

1. Separate deleteMessage() method: Would require two operations (revert then delete)
2. Permanent flag in revert path: Less flexible than body parameter
3. Config-level setting: Less granular control per operation

Additional Context

This feature would be particularly useful for AI coding assistants and development environments where users need fine-grained control over their conversation history and the ability to permanently clean up their sessions.