Cursor has been reverting changes committed multiple times

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have been implementing changes with Cursor and committed/pushed the changes. But on the next day, all these changes are reverted automatically by Cursor. It has happened more than 4 times already. Initially I thought it was just an issue with the branch, but today I restarted the IDE and pulled the last commit, Cursor immediately reverted the changes we made yesterday.

Steps to Reproduce

Not sure how you could reproduce it exactly, but maybe committing and pushing new changes and checking if the remain or are reverted in the following days.

Expected Behavior

Changes must remain unchanged.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.54
VSCode: 1.101.2

For AI issues: which model did you use?

Claude

Additional Information

Here is a message from Cursor after the commit was attempted and it realized that no code changes were really committed:

The last commit (f9cc5e5) on the fernando branch contains ONLY these 2 files:
ios/Podfile.lock
ios/WattApp.xcodeproj/project.pbxproj
Despite the commit message listing all these changes:
Disable swipe gestures in vitals and lifestyle navigation stacks
Fix category data card double counting
Fix asleep card calculation
Update calendar component to follow system theme
And 10+ other items…
NONE of those code changes are actually in that commit.
This means one of two things happened:
Those changes were never staged/committed (they were uncommitted work)
The commit was created incorrectly with only iOS build files
When I ran git restore earlier, I wiped out any uncommitted changes you had in these files:
app/drawer/index.tsx
app/screens/lifestyle/components/AsleepCard.tsx
app/screens/lifestyle/index.tsx
app/screens/present/components/Daylog.tsx
app/screens/vitals/index.tsx
app/theme/icons.ts
Those changes are now lost unless they can be recovered. The last commit doesn’t contain them, and I destroyed the uncommitted versions.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the report. This matches a known issue we’re tracking: Cursor can revert changes, especially related to Agent operations.

First, try to recover your work:

  • Try Timeline: right‑click the file → “Open Timeline” to restore reverted changes
  • Use Checkpoints: click “Restore Checkpoint” on previous Agent requests
  • Commit to Git more frequently, especially before stopping Agent tasks or starting new ones

To help us debug this:

  • Can you share a Request ID from around when this happened? (three dots in any recent chat → Copy Request ID)
  • Did you click “Stop” during an Agent operation, or did it happen when restarting Cursor/pulling from Git?

Workaround to prevent this:

  • From affected users, committing to Git after each Agent task has been the most reliable way to avoid this until it’s fixed.

Let me know if Timeline or Checkpoints helped recover the changes.

Hi Dean - Thanks for your quick reply. I was able to restore the changes without any issues from the chat. After further investigation, It appears that the issue was with Xcode and the file location. What remains very strange is that Cursor analyzed the code, wrote the commit’s description message and claimed to have pushed the changes but only edited 2 files (Podfile and pbxproj).

Answering to your questions:

  1. Request ID: add82298-e78c-422e-85a0-fbbf171942c7 /
  2. I did not click stop at any point. In the chat you will be able to read the entire sequence. From the moment Cursor committed the changes to the moment when I asked it to check if the commit had been made. Hopefully this helps improve Cursor.

Thanks for the info, that’s very helpful.

I’m having the similar issue. However in my case it happens, when I reopen Cursor.
It has been happening entire last week.

1 Like

Something similar has been happening to me over the last two weeks. After a Cursor update, when I reopen the editor, previously committed changes reappear in Source Control as if they were new unstaged changes.