To answer your main question: this is not expected checkpoint behavior. Checkpoints are stored locally and separate from Git. They do not use git stash or git reset.
What you experienced appears to be a bug where an internal workspace operation ran destructive git commands without prompting. This is a known issue class that our team is actively investigating.
Recovery: If you haven’t already, your changes should be recoverable via git stash pop or git stash apply.
To help our engineering team pinpoint the exact trigger, could you provide a few details?
-
git stash listoutput — What does the stash entry look like? The stash message (if any) would help us identify which internal operation created it. -
Exact Cursor version — Menu > About Cursor > Copy. The specific build version matters for narrowing this down.
-
Was worktree mode active during the session? Check the environment dropdown at the bottom of the chat panel. Did it say “Local” or “Worktree”? Also, was there a branch icon visible to the right of the model picker?
-
Did you see or dismiss any “Overwrite uncommitted changes?” dialog at any point during the session? This dialog has a “Don’t show again for this agent” option. If clicked earlier, it could have enabled silent operations later.
-
Full
git reflogoutput around the incident — The 5-10 entries before and after thereset: moving to HEADline would help us see whether a branch checkout or other operation preceded it.
In the meantime, committing frequently during long agent sessions is the safest mitigation until this is resolved.