Cursor needs a clearer revert workflow, especially when using Multitask. Right now it is too easy to end up with several agent threads making changes across the same repo, but there is no simple “revert everything from this task/chat” button.A useful approach would be:
Show exactly which files were changed by each agent task.
Let users revert one task without affecting unrelated work.
Add a safe “discard all changes from this chat/task” option.
Make it obvious when multiple tasks are touching the same working tree.
This becomes especially important when experimenting with generated code. If the result is bad, reverting should be as easy as accepting the changes.it reverts other chats stuff as well and clears the git
@cursor team, please treat this as a high-priority issue. The current revert workflow can undo changes from unrelated chats and clear Git changes, creating a serious risk of lost work. Reverts must be scoped to the specific task or chat.
Hey, thanks for the feedback. Your per-task revert requests are solid. All four points make sense, and this isn’t the first time we’ve heard it. I won’t promise an ETA, but it’s on our radar.
About it reverting someone else’s changes and “cleaning git”, I get it. Losing work always hurts. Here’s what’s happening: in local Multitask, multiple agent threads work in the same shared working tree. Each chat’s checkpoints are per-file snapshots, and revert restores files to that chat’s state, overwriting what other threads may have written to the same files. That’s why it can look like “everything got rolled back”. This is a known limitation of the current architecture. The team is thinking about it, but there’s no dated fix yet.
What you can try to recover things right now:
Cmd+Shift+P → Local History. The IDE keeps recent local versions of files, and you can often pull lost edits from there
Run git reflog and git stash list in the terminal. If there were any commits or stashes, they might still be there
Check checkpoints in other threads. Sometimes you can restore a file from the snapshot of the chat that wrote it
For next time, to avoid this:
Commit more often, especially before starting parallel tasks. Then any revert is easy to undo
For truly parallel work in the same repo, use worktrees or parallel agents with separate branches. That keeps threads isolated so they don’t overwrite each other
Don’t run destructive agent actions like “revert all” on auto-run. Review them before you confirm
Let me know if you managed to recover anything via Local History, and I can help from there.
Cursor should make the revert workflow intelligent enough to detect overlapping edits before restoring a checkpoint. If another task has modified the same files, it should show a conflict preview and let the user choose which changes to preserve instead of silently overwriting unrelated work. Please add task-scoped reverts with file-level diffs and a safe recovery option.
Hey, thanks for clarifying. The idea of a conflict preview makes sense: when revert sees another task changed the same files, it would let you choose what to keep instead of silently overwriting. I noted it together with the other four points, it’s on the team’s radar. I can’t promise any timelines.
For now, since this can happen, the main way to stay safe is to commit more often before starting parallel tasks. And for truly parallel work in the same repo, use worktrees or parallel agents with separate branches so the flows are isolated and don’t overwrite each other.
If you managed to recover anything after my last message via Local History or git reflog, let me know and I’ll help you take it further.
