Working on three source files (remote ssh to the project), checked them in…later to find they had been deleted.
When asked what happened, Cursor replied:
“A Cursor/agent/tool operation was still running or resumed later and applied an old file state. Since those were the files in the active edit set, they were the ones affected.
A git restore/checkout-like operation ran later against the modified files. If something went wrong around symlinks or file state, it could leave touched files deleted”
No symlinks were associated with these files.
Easily recoverable as the changes had been checked-in
Hey, thanks for the report. I get that finding missing files is always stressful, it’s good they were committed and came back quickly.
A few questions so we can understand what exactly happened:
The form says Background Agent, but the description mentions Remote-SSH to the project. Was this a Cloud Background Agent started via cursor.com/agents, Slack, Linear, etc., or a local agent in the IDE connected to the project via Remote-SSH?
Was auto-run for shell or terminal commands enabled at the time of the incident? If yes, do you remember what prompt you gave the agent right before the files went missing?
If you still have it, the Request ID for that chat. Chat menu in the top right > Copy Request ID. That makes it much easier to trace what commands the agent actually ran.
Based on the pattern we’re seeing, the model mentioned a git restore/checkout-like operation in its own explanation. That matches other cases where the agent decides to run a destructive git command like git stash -u, git checkout, or git clean -f, without fully understanding the impact. We’re actively improving models to be more careful with destructive ops, but for now I’d recommend these safety practices:
Don’t leave auto-run enabled for shell commands on unfamiliar tasks
Review destructive commands before approving, especially git, rm, mv
For risky tasks, use Plan mode so you can see the plan first, then enable execution
Send over your answers and we’ll dig into what happened together.
It was a local agent in the IDE connected to the project via Remote-SSH.
Auto-run was enabled for terminal commands at the time of the incident. I don’t allow it to do rm commands or anything destructive. Things like grep and ls are auto-run. The prompt right before the deletion was doing a check in the database for the bisection jobs between mainline 5234 and 5246. Prompt was: “can you find all my job bisections for 5234-5246? there should be a few bisections, just need the job. Need to check the sql db for this”
Thanks for the info, especially the Request ID, that’s exactly what we need.
One interesting point: your prompt was about SQL and bisection jobs, you didn’t request any file or git actions. So the agent decided on its own to run some destructive git command in the background, and that’s what we want to dig into using the trace. The explanation the model gave you after the fact (git restore/checkout-like) is just its own guess, not a log of real actions, so we won’t rely on it. Using the Request ID, we’ll check which shell tool calls were actually made, and compare them with similar reports about Linux plus silent git ops. If we find anything concrete, I’ll come back to this thread.
A couple of notes about the allowlist for next time, so this doesn’t happen again:
In the allowlist for terminal auto-run, it makes sense to explicitly denylist not only rm, but also git stash, git restore, git checkout -- ..., git clean -f, git reset --hard. They aren’t always considered destructive in a general sense, but they can wipe your working files just as effectively as rm.
For tasks that don’t need shell access (SQL requests, investigation), you can keep auto-run off and approve commands one by one. It’s a bit slower, but no surprises.
The fact that everything was committed and you could restore quickly is good news. Models are learning to be more careful with destructive actions over time and the team is working on it, but for now the safer option is an explicit denylist for git commands that touch the working tree.