anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:38:31 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:38:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @khanhduyvt0101 on GitHub (Nov 24, 2025).

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

  • #3033 - Add a way to delete message parts and messages in the SDK
  • #2642 - /undo removed the last message, but didn't revert the code edit
  • #3901 - Undo command doesn't allow editing reverted message like keyboard shortcut
  • #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.

Originally created by @khanhduyvt0101 on GitHub (Nov 24, 2025). ## 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 ```typescript // 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: ```typescript // 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 ```typescript 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 - #3033 - Add a way to delete message parts and messages in the SDK - #2642 - /undo removed the last message, but didn't revert the code edit - #3901 - Undo command doesn't allow editing reverted message like keyboard shortcut - #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.
yindo commented 2026-02-16 17:38:31 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 24, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #3033: Add a way to delete message parts and messages in the sdk - Proposes a method to delete message content, which is related to your use case of permanently removing messages

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 24, 2025): This issue might be a duplicate of existing issues. Please check: - #3033: Add a way to delete message parts and messages in the sdk - Proposes a method to delete message content, which is related to your use case of permanently removing messages Feel free to ignore if none of these address your specific case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3079
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?