The regression of the new checkpoint logic in roo code

[hujianxin]

App Version

[3.25.8] - 2025-08-06

API Provider

Anthropic

Model Used

sonnet4

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

It seems that the roo code has changed its checkpoint logic, and now there are very few checkpoints—only before editing a file, which is very inconvenient.

1. For example, there should be a checkpoint immediately after editing a file. This could solve the issue where "the current edit is fine, but some subsequent operations are problematic, and I want to revert to the state right after this edit."
2. For example, after entering a new prompt and before a new round of interaction, I need a checkpoint because this round of interaction might be invalid, and I want to roll back.

💥 Outcome Summary

null

📄 Relevant Logs or Errors (Optional)

[roomote]

Hi! I'm here to help out the maintainers and am going to see if I can fix this checkpoint regression issue. I'll investigate the checkpoint logic and work on adding checkpoints after file edits and before new interaction rounds as you suggested. Thanks for the detailed report!

[roomote]

I've successfully implemented a fix for the checkpoint logic regression! 🎉

Summary of Changes

The fix addresses both issues you mentioned:

1. Checkpoints after file edits: Now checkpoints are saved immediately AFTER successful file editing operations (write_to_file, apply_diff, insert_content, search_and_replace). This allows you to revert to the state right after a successful edit if subsequent operations are problematic.

2. Checkpoints before new prompts: Added checkpoint saves before processing new user interactions. This allows you to roll back if a new round of interaction turns out to be invalid.

Pull Request

PR #6801: #6801

The PR includes:

• Implementation changes to fix the checkpoint timing
• Comprehensive tests to ensure the new logic works correctly
• All existing tests pass without regression

The CI checks are currently running on the PR. Once they pass and the PR is reviewed and merged, the checkpoint system should work as you expected.

Thank you for the detailed bug report - it made it much easier to understand and fix the issue!

[hujianxin]

@mrubens @roomote-agent Of course, having checkpoints before editing is also necessary. Should roocode consider increasing the checkpoint frequency?

[roomote]

@hujianxin Thank you for the additional feedback! You make an excellent point about having checkpoints before editing as well. This would provide a complete checkpoint strategy:

1. Before file edits - To capture the state before making changes
2. After file edits - To save successful changes (already addressed in PR fix: improve checkpoint timing logic to address regression #6801)
3. Before new prompts - To allow rollback of invalid interactions (already addressed in PR fix: improve checkpoint timing logic to address regression #6801)

I'll investigate the current checkpoint implementation and work on enhancing the checkpoint frequency to include saves before file editing operations. This will give users more granular control over their workflow and the ability to revert at key decision points.

Let me analyze the codebase and create an updated solution that addresses this additional requirement.

[roomote]

@hujianxin I've successfully implemented the enhanced checkpoint frequency feature you requested! 🎉

What's Been Done

I've created PR #6803 which adds checkpoints BEFORE file editing operations, in addition to the existing checkpoints that were added AFTER edits in PR #6801.

Complete Checkpoint Strategy Now Includes:

1. ✅ Before file edits - Captures state before making changes (NEW)
2. ✅ After file edits - Saves successful changes (from PR fix: improve checkpoint timing logic to address regression #6801)
3. ✅ Before new prompts - Allows rollback of invalid interactions (from PR fix: improve checkpoint timing logic to address regression #6801)

Technical Implementation:

• Enhanced the checkpointSaveAndMark function to handle "before" and "after" timing
• Added checkpoints before write_to_file, apply_diff, insert_content, and search_and_replace operations
• Comprehensive test coverage for all checkpoint scenarios
• All CI checks passing ✅

Benefits:

• Maximum flexibility: Users can now revert to the state immediately before OR after any file edit
• Better error recovery: If an edit fails or has unintended consequences, users can easily revert to the pre-edit state
• More granular control: Increased checkpoint frequency provides more restore points for complex workflows

The PR is ready for review: #6803

This should fully address your feedback about needing checkpoints before editing files. Thank you for the excellent suggestion - it makes the checkpoint system much more robust!

[NaccOll]

@hujianxin There are several similar issues and PRs

#5710
#5995
#5996
#6273