Composer 2 deleted pending changes

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I asked Composer 2 to group the UI, styles and table related changes to make a PR, it did it alright, but ended up deleting the rest of the changes, lost 3/4 of the progress of that thread.

Steps to Reproduce

No idea, have a mix of 20 changed files with part of it being UI changes to target, then ask it to make a PR with only the UI changes.

Expected Behavior

Stash the changes or make a backup branch, then cherry pick the changes we want to commit.

Operating System

Windows 10/11

Version Information

Version: 3.3.22 (system setup)
VSCode Version: 1.105.1
Commit: 38a27120cfc7419a5efa38420665eaeeed1e7b30
Date: 2026-05-07T07:47:13.552Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Composer 2

For AI issues: add Request ID with privacy disabled

a4ae4ba1-0540-4d13-b038-f23f3668c090

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

Was this on me for how I asked to make that PR?

6

Hey, thanks for the report. To answer your question right away: no, this isn’t on you. Asking for make a PR with UI/styles only is totally valid. What should’ve happened is the model would’ve stashed the rest or created a backup branch before doing a selective commit, like you described in expected behavior. What happened is the git workflow didn’t preserve the non-targeted uncommitted work. I get how frustrating it is to lose 3/4 of your thread progress.

First, let’s try to recover it, there’s a good chance:

  1. Run git reflog in the repo root. It shows recent HEAD states. Find the entry before the commit, then run git checkout <hash> -- . or create a branch from that state.
  2. Run git stash list. If the agent did stash instead of resetting, your changes might be there.
  3. Run git fsck --lost-found. It can show dangling commits and blobs. Sometimes your work is there even after a reset.
  4. In Cursor, run Cmd/Ctrl+Shift+P then Local History. VS Code keeps local file snapshots, this can help recover specific files.

For next time, to avoid this:

  • Before asking the agent to do anything with git, especially selective commits, run git stash yourself or git checkout -b backup-<date>. It takes 5 seconds and saves you.
  • Say it clearly in the prompt: stash everything else before committing, restore after. The model follows better when the instruction is direct.
  • Don’t auto-run destructive git commands. Review them before approving.

On the behavior itself: models are iterating on handling git more safely and not deleting non-targeted work, and the team is working on it. I added your case with the Request ID to the existing tracker for this issue, but I can’t give an exact ETA.

Let me know if you manage to recover anything via reflog or Local History.

8

I’m past the recovery at this point, used a different solution, a better solution at the end.