Remote-SSH disconnect/reconnect on a Linux GCP VM physically deleted files ~2 seconds after cursor-server restart. Local History records the operation as source: "Undo Create Diff". In this incident, gitignored sandbox markdown/scripts were emptied; large artifacts in the same folder survived. The blast also listed tracked files across the workspace. This matches the known SSH file-deletion cluster Cursor staff have already acknowledged. I’ve hit the same class of bug before on normal git-tracked paths, including files I edited by hand (not only Agent output / gitignored dirs).
1785335101745 → 2026-07-29T14:25:01.745Z (≈2s after remoteagent start).
The same burst also targeted 51 other files beyond the active chat — older sandbox write-ups, tracked files like file1.json / file2.config, and paths under a second repo on the same remote. Those were not permanently lost: after a second reconnect (~14:30) they were back on disk, byte-identical to the Local History “Undo Create Diff” snapshot, and git-tracked ones still match HEAD (clean). Only the new gitignored sandbox/…-thing Agent creates stayed deleted until manual restore. So the blast radius is workspace-wide Agent history, not “just this chat” — even when content is later rewritten back.
Anonymized path list + copied remoteagent.log available if useful.
Impact
Critical data loss on reconnect: not limited to Agent-only or gitignored paths. I’ve previously seen the same failure on regular tracked files and on files I manually edited.
Gitignored paths are an extra footgun (no git restore), but tracked deletes still burn uncommitted work and show up as D with the index left intact.
In this incident, Local History still had content, so recovery was possible — but only after noticing and digging under ~/.cursor-server/data/User/History/.
Asks for engineering
Does reconnect incorrectly apply an agent checkpoint / “Undo Create Diff” against a stale snapshot?
Please never push deletes to disk for files outside the active turn without confirmation — including tracked and manually edited files.
Multi-ExtensionHost reconnect race (called out in related threads) still reproduces on 3.13.10.
Treat any reconnect-time unlink of workspace files as a hard bug; warn or require confirmation before deleting from disk.
Steps to Reproduce
Lose connection to remote SSH, reload connection, have files randomly deleted en masse Russian roulette-style
Expected Behavior
No files altered or deleted on reload of connection to remote SSH
Operating System
Linux
Version Information
Cursor IDE, Cursor server 3.13.10 (commit 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0)
What you’re describing isn’t intended behavior, and it’s not something you misconfigured. Files shouldn’t be touched or removed on a reconnect/reload. You’re right that this is something we’re already tracking on our side, and I’ll make sure your report and logs get added to what the team has. I don’t have a timeline to share, but I’ll post here when there’s an update.
For recovery and to protect work in the meantime:
Anything that stayed deleted (your gitignored sandbox/… files) can be restored from Local History - either the per-file Timeline view in the editor, or the on-disk snapshots you already found under ~/.cursor-server/data/User/History/.
Tracked files are recoverable with git restore . / git checkout -- <path>, since the git index stays intact.
Because gitignored paths have no git safety net, the safest guard right now is to keep a copy of important untracked working dirs (sandbox/, .env, etc.) outside the repo, and to commit often — even throwaway WIP commits are fine.
One thing that would genuinely help: you offered the anonymized path list and the copied remoteagent.log - yes please, if you can share those here. The reconnect-window server log is the piece we most want to line up against the deletion burst.
Thanks Mohit for letting me know what some mitigation strategies are! I can try to provide whatever I can to help with fixing this issue. I hope the attached is useful!
remoteagent.log excerpt:
2026-07-29 14:24:59.508 [info] Extension host agent started.
2026-07-29 14:24:59.754 [info] Deleted marked for removal extension from disk charliermarsh.ruff /home/user/.cursor-server/extensions/charliermarsh.ruff-2026.62.0-linux-x64
2026-07-29 14:24:59.763 [info] Deleted marked for removal extension from disk anthropic.claude-code /home/user/.cursor-server/extensions/anthropic.claude-code-2.1.214-linux-x64
2026-07-29 14:25:00.042 [info] [127.0.0.1][fcca106c][ManagementConnection] New connection established.
2026-07-29 14:25:00.233 [info] [127.0.0.1][04952117][ExtensionHostConnection] New connection established.
2026-07-29 14:25:00.249 [info] Getting extensions control
2026-07-29 14:25:00.440 [warning] [typescript-language-features]: Couldn't find message for key configuration.tsserver.experimental.useBundledNode.unifiedDeprecationMessage.
2026-07-29 14:25:01.438 [warning] [typescript-language-features]: Couldn't find message for key configuration.tsserver.experimental.useBundledNode.unifiedDeprecationMessage.
2026-07-29 14:25:03.250 [error] Error getting extensions control manifest Timeout getting extensions control
2026-07-29 14:25:03.599 [info] [127.0.0.1][04952117][ExtensionHostConnection] <2531753> Launched Extension Host Process.
Today faced this issue and lost sensitive data.
Cursor client disconnected overnight; remote kept the old session in reconnection grace.
Next day the Windows client reconnected automatically.
Within a few seconds of reconnect, Cursor rewrote on the order of ~100–200 files across multiple trees that had been open/dirty in that session (not a full repo checkout).
The burst lasted ~7 seconds.
Local History entries lined up with the file mtimes. Sources were mostly normal saves, plus several Undo Create Diff snapshots (same source string as in this thread).
Since your Local History has snapshots for the rewritten files, you should be able to recover:
Local History: select an affected file → open the Timeline view (bottom of the Explorer) → restore the version from just before the reconnect. On the remote host the snapshots also live under ~/.cursor-server/data/User/History/ (each folder’s entries.json maps them back to original paths).
Tracked files: git checkout -- <path> (git index stays intact) - avoid a blanket git restore . if you have other edits to keep.
Going forward: keep important untracked/gitignored files outside the repo and commit often, so there’s always a fallback.
This isn’t intended behavior and isn’t anything you misconfigured - it’s the same issue this thread is tracking, and we’ve let the team know. I’ll post here when there’s an update.
If you can share your Remote - SSH and Extension Host (Remote) logs from around the reconnect (you’re on Windows, which is a useful new data point), that’d help a lot.
The remoteagent.log window (extension host starting at 14:24:59, right before the 14:25:01 burst) lines up cleanly with the Undo Create Diff timeline you documented, and the anonymized path list + burst JSON make the pattern really clear. I’ve passed all of it along to the team to add to what they have here. I’ll follow up on this thread when there’s an update.
Hi Mohit,
Thanks for the reply. yes was able to recover few files from local history from ~/.cursor-server/data/User/History/. There were no local history snapshots for many files.
Please find the attached log files.
My Remote SSH session timed out, I hit reconnect, and right after that a bunch of files were gone from the Linux server.
It wasn’t anything the agent was asked to delete. Looking at Local History, there was a burst of "Undo Create Diff" entries at the same second as the reconnect (~/.cursor-server/data/logs/20260807T091312/ → Extension host started, then History snapshots within ~2 seconds).
Luckily Grok (agent in the chat) noticed the files were missing and managed to restore them from ~/.cursor-server/data/User/History/. Without that we’d have been in worse shape.
Just adding another data point: reconnect → mass delete via Undo Create Diff. Happy to share log snippets if useful.