Remote-SSH physically deletes recently-edited tracked files when a second client connects (server-side logs, v3.7.27)

Support Bug Reports
, ,
1

SUMMARY

On a Cursor Remote-SSH workspace, cursor-server physically deletes (unlink) a cluster of recently-edited, git-tracked files from the remote disk. I can reproduce it two ways:
A) when a second client connects / on reconnect, and
B) when I click Restore Checkpoint / revert on an old chat task.
In both cases the git index is left intact (files show as deleted “D” in git status), so this is NOT a git reset/checkout/stash. Something in cursor-server deletes files from disk directly.

Same pattern as previous reports, but I can add remote server-side logs with second-precise timing. This has happened 4+ times in about 3 weeks.

ENVIRONMENT

  • Connection: Cursor Remote-SSH, client to a Linux remote host
  • Remote OS: Linux 6.8.0-111-generic (Ubuntu), ext4
  • Remote cursor-server: cursorVersion 3.7.27, vscodeVersion 1.105.1, commit e48ee6102a199492b0c9964699bf011886708ba0, build 2026-06-10
  • Client app version: FILL_IN (Help → About)
  • Local OS: FILL_IN
  • Repo: single-root git workspace (rules out the multi-root theory)

IMPACT

Silent loss of on-disk source files, including uncommitted edits since the last commit. git restore only brings back HEAD, so post-commit work is lost unless it survives in Cursor Local History.

WHAT GETS DELETED

The same 5 git-tracked files from one feature area, deleted together - exactly the files I had just been editing:

web/components/GuandanHandColumns.vue
web/pages/games/card/guandan.vue
web/utils/guandan.ts
web/utils/guandanHandSmart.test.ts
web/utils/guandanHandSmart.ts

git status afterwards shows them as deleted “D” (worktree deleted, index/HEAD intact).

TRIGGER A - SECOND CLIENT CONNECTED, DELETION ~17s LATER

From the remote host log ~/.cursor-server/data/logs//remoteagent.log :

2026-06-12 01:50:57.849 [ManagementConnection] The client has disconnected, will wait for reconnection 3h before disposing…
2026-06-12 02:25:54.667 [ManagementConnection] Another client has connected, will shorten the wait for reconnection 5m before disposing…
2026-06-12 02:25:54.668 [ManagementConnection] New connection established.
2026-06-12 02:25:54.808 [ExtensionHostConnection] New connection established.
2026-06-12 02:25:54.815 [ExtensionHostConnection] <3559789> Launched Extension Host Process.
(files deleted around 02:26:11)

TRIGGER B - RESTORE CHECKPOINT / REVERT OF AN OLD TASK

Clicking Restore Checkpoint / revert on an older chat turn immediately deletes the same set of files (deletion observed at 03:00:19 UTC), even though those files are unrelated to that old task. git reflog shows HEAD did not move.

THIS IS NOT A GIT OPERATION

git reflog --date=iso - HEAD never moved around either deletion:

277d612 HEAD@{2026-06-11 23:25:07 +0000}: commit: …
578c9c3 HEAD@{2026-06-11 07:55:20 +0000}: commit: …
012c0a2 HEAD@{2026-06-11 04:11:55 +0000}: commit: …

No reset / checkout / stash. Files are removed from the worktree only; the git index/HEAD still contains them.

THIS IS NOT cursor-checkout / cursor-shadow-workspace

After earlier incidents I disabled both extensions (so they never activate). In the offending session’s ExtHost log neither activated - only the ones below did - yet files were still deleted:

02:25:59.246 _doActivateExtension anysphere.cursor-agent-exec (startup:true)
02:25:59.246 _doActivateExtension anysphere.cursor-polyfills-remote (startup:true)
02:26:00.132 _doActivateExtension anysphere.cursor-mcp (root cause: cursor-agent-exec)
02:26:01.595 activated success: anysphere.cursor-agent-exec
02:26:01.597 _doActivateExtension anysphere.cursor-commits / cursor-explorer / cursor-retrieval
(no cursor-checkout, no cursor-shadow-workspace)

So the root cause is deeper than those extensions - in cursor-server’s reconnect / checkpoint / workspace-sync path.

LIKELY MECHANISM

The deleted files are exactly the most-recently-edited / open-editor files (their Cursor Local History snapshots are timestamped 14 seconds before the deletion). Both the reconnect path and the Restore Checkpoint path seem to reconcile a recently-touched file set against a stale or empty snapshot, and push deletes to disk for files not present in that snapshot.

Request: please guard the reconnect and checkpoint/restore paths so that a missing or empty in-memory snapshot can never result in an on-disk delete.

REPRODUCTION

Trigger A:

  1. Open a Remote-SSH workspace, edit several files via agent/editor.
  2. Connect to the same remote workspace from a second client/device (or let the link drop and auto-reconnect) while the old session is still in its reconnection grace window.
  3. About 15-20s after the new ExtHost launches, the recently-edited tracked files are deleted; git status shows them deleted, git index untouched.

Trigger B:

  1. In the same workspace, open an older agent chat and click Restore Checkpoint / revert on one of its turns.
  2. The same recently-edited tracked files are immediately deleted from disk; git reflog shows HEAD did not move.

LOGS AVAILABLE ON REQUEST

Remote remoteagent.log, exthost remoteexthost.log, git reflog --date=iso, and the client Output panel → “Anysphere Remote SSH” channel.

7

Hi there - thanks for the thorough report. This seems like a bug on our side, not expected behavior, and your diagnosis holds up: it isn’t a git operation (index/HEAD and reflog are untouched), and it isn’t the cursor-checkout or cursor-shadow-workspace extensions. I’m making sure your report is captured with the cluster we’re tracking.

Recovering what was deleted:

  • Tracked files show as D with the index intact, so git restore . (or git checkout -- <path>) brings them back to your last commit.
  • Uncommitted edits since that commit and untracked files (e.g. .env) aren’t in git, but Cursor’s Local History often still has them. Open the Timeline view for a file (Explorer panel → Timeline section, or right-click a file → Open Timeline) to find and restore recent snapshots — you noted your Local History entries are timestamped seconds before the deletion, so they should be recoverable there.

Until the fix lands, a few ways to limit exposure:

  • Commit often, even WIP commits - git restore is the fastest recovery for tracked files.
  • Back up untracked files separately (a quick cp/rsync/cron snapshot of .env, vault/, etc.), since git can’t recover those.
  • Avoid “Restore Checkpoint” / revert on a turn that has uncommitted work you care about — that’s one of the triggers you identified.
  • After a freeze or disconnect, give it a moment before reloading, and avoid connecting a second client to the same remote workspace while the first session is still in its reconnection window.

If it happens again and you can grab the remoteagent.log and the “Anysphere Remote SSH” Output channel around the deletion timestamp, that’ll help us keep narrowing it down. Sorry you’ve hit this repeatedly.