Cursor's checkpoint system exists to protect your work during an agent session. In this report, it did the opposite: it ran git stash immediately followed by git reset HEAD on its own, mid-session, with no prompt — and the agent kept working on the now-clean tree without noticing anything had changed.

What the source says

Per the Cursor forum report: during a roughly 2.5-hour, 30-plus-generation agent session on Linux (Cursor 2.6.21), investigating a bug after a prior 25-plus-file refactor, the reflog shows a stash created one second before a reset: moving to HEAD event. No user-initiated git action triggered it, no "Overwrite uncommitted changes?" dialog appeared, and nothing showed up in the Git extension's own log. 45 modified files — 641 insertions, 183 deletions — of uncommitted work vanished from the working tree.

The reporter caught it from the reflog in time and recovered the work from the dangling stash commit before garbage collection could remove it. They also ran a controlled test to rule out context-summarization as the trigger. In a reply on the thread, Cursor staff member Mohit called it "not expected checkpoint behavior," confirmed "an internal workspace operation ran destructive git commands without prompting," and described it as "a known issue class that our team is actively investigating" — without confirming what triggers it or when a fix is coming.

What it doesn't establish

No root cause has been confirmed, by Cursor or the reporter. This is one reported case, not a demonstrated reproduction anyone else can run on demand — "actively investigating a known issue class" is Cursor's characterization, and the thread doesn't show how often this fires or for whom. Nothing was permanently lost here, but only because the reporter happened to check the reflog before GC ran.

Why it matters anyway

A checkpoint system that silently stashes and resets your tree is supposed to be your safety net, not a second way to lose work. If you use Cursor's agent for long sessions on Linux, know that git reflog is your recovery path if a stash ever disappears before you notice it was taken — Git typically keeps a dangling commit around for a window after a drop, not forever.

Scored 4/10 (medium) on severity: narrow scope (one working tree, one developer, one session), fully recovered, realized but not widely reproduced, no lasting impact in this case. Full scoring and source: https://www.stupidllm.com/incident/STUPID-2026-0162/