Critical bug — Cursor SSH Remote physically deletes workspace files on disconnect/reconnect (3rd occurrence)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hiya,

I’m reporting a critical recurring data-loss bug in Cursor SSH Remote that has now happened three times. I’ve done enough investigation to describe it precisely.

Setup:

Two git repositories open simultaneously in the same workspace: ~/colony-os and ~/colony-dashboard
What happens:
I work in a Cursor SSH Remote session for 1–3 hours, making file edits
At some point Cursor becomes unresponsive (“unable to connect to client”) — likely triggered by a Tailscale/SSH hiccup (i often get prompted to reload the window)
I close and reopen Cursor
A large number of files are physically missing from disk on the remote machine
After reconnect, Cursor’s git extension shows two popups:

“The git repository at /Users/emiglio/colony-dashboard has too many active changes, only a subset of Git features will be enabled.”
“The git repository at /Users/emiglio/emiglio has too many active changes, only a subset of Git features will be enabled.”
Precise diagnosis (confirmed by checking git state after incident):

This is not about uncommitted changes. I have confirmed after the most recent incident:

Local HEAD = Remote HEAD — both repos are at the exact same commit as GitHub. No git reset occurred.
Git history is fully intact — all commits are present locally and on GitHub
git status shows ~75+ files marked D — present in the git index and on GitHub, but physically absent from the filesystem
Recovery requires only git restore . — which confirms the files are in the committed state, just deleted from disk

Conclusion: Cursor SSH Remote seems to be physically deleting files from the working directory without modifying git. This is not a git reset, not a checkout, not a stash. Something in Cursor’s SSH Remote reconnection/cleanup routine is running rm (or equivalent) on workspace files and leaving the git index intact.

Consistent symptoms across all 3 occurrences:

Always triggered by SSH/Tailscale disconnect followed by Cursor reconnect
Always affects a large subset of files (75+ in one repo, similar in another) — not all files
Always leaves git commits untouched
Dev server confirms files are genuinely absent from disk (not a display glitch)
The “too many active changes” git warnings always appear around the same time

Each time this happens, I lose my session of work and have to reconstruct it from scratch with an AI coding assistant. I am using Cursor specifically as an AI coding tool and each reconstruction session is starting to pile up in token usage.

For now I’ve added added a hard rule to make sure my agent backs everything up after every change

What I’d need from you:

Identify what process in Cursor SSH Remote is deleting files on workspace reconnect — specifically what runs when the “too many active changes” state is detected

In the meantime, is there a way to disable whatever cleanup routine is responsible?

Thanks!

Steps to Reproduce

Steps to reproduce (approximate):

Open two git repos in Cursor SSH Remote over Tailscale
Make a large number of file edits over a 1–2 hour session
Allow the SSH connection to drop (or force-quit Cursor)
Reopen Cursor and reconnect via SSH Remote
Observe that modified/created files from the session are missing

Screenshots / Screen Recordings

Screenshot 2026-03-08 at 13.26.17.png
Screenshot 2026-03-08 at 13.26.17.png776×950 129 KB

Operating System

MacOS

Version Information

Client machine: MacBook M1 on Sequoia (Cursor SSH client)
Version: 2.6.11
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z (4 days ago)
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0
Remote machine: Mac Mini M4, macOS Tahoe (26)
Connection: Cursor SSH Remote over Tailscale (local network)

For AI issues: which model did you use?

Sonnet 4.6 Thinking, sometimes temporarily auto-switches to Composer 1.5 if I’ve exceeded my limit. YOLO enabled

Additional Information

I also receive a persistent error: ‘The VSCode Remote Containers extension is not supported with the Anysphere Remote SSH extension.’ I have not yet switched to Anysphere Remote Containers. It is possible this extension conflict is contributing to the file deletion behaviour — VSCode Remote Containers may be running its own workspace cleanup logic that conflicts with Anysphere Remote SSH’s file management.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, thanks for the detailed report. This is a serious one, so let’s dig in.

First, an important step: uninstall the VSCode Remote Containers extension right away and switch to Anysphere Remote Containers (as suggested by the prompt you’re seeing). Running both at the same time can cause conflicts in workspace and file management, and that’s very likely part of what’s happening here.

A couple of things I’d like to clarify:

  1. How are the two repos opened? Is this a multi-root workspace (.code-workspace file), or two separate Cursor windows?
  2. macOS Tahoe (26) on the remote. Is this a beta release? If yes, filesystem-level issues could be involved.
  3. Can you grab the SSH logs next time this happens? Go to the Output panel (View > Output) and select Anysphere Remote SSH from the dropdown, then copy the full log.
  4. Could you share the full list of extensions installed on both client and remote? Run cursor --list-extensions in the terminal.

Also, next time, right after you notice the file deletion and before running git restore ., it would really help if you could:

  • Run ls -la in a few directories where files are missing (to confirm if they’re truly gone or if it’s a permissions issue)
  • Check ~/.local/share/Trash or the equivalent on the Mac to see if the files ended up there
  • Run ps aux | grep cursor to see which Cursor processes are active

In the meantime, besides switching the extension, you can also try keeping each repo in its own separate Cursor window instead of using multi-root. That should help confirm whether the multi-repo setup is part of the problem.

Let me know how it goes after removing the VSCode Remote Containers extension.

1 Like
4

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment:
Cursor IDE (latest version)
Remote connection via SSH
Linux host
Problem:
Files that were edited by Cursor AI agent get deleted from disk after SSH connection interruption and automatic reconnection/reload.
Steps to reproduce:
Connect to remote PC via SSH in Cursor
Open files and make edits using AI agent (StrReplace tool)
Run a command that causes SSH connection to drop (e.g., launching a program that disrupts networking)
Cursor attempts to reconnect and triggers “reload”
Result: Files that were being edited disappear from:
The filesystem (confirmed via ls and git status showing “deleted”)
Open editor tabs
Expected behavior:
Files should persist on disk. At worst, unsaved changes might be lost, but files themselves should not be deleted.
Actual behavior:
Entire files are deleted from the remote filesystem after reconnection.
Impact:
Critical - data loss. Users lose source code files.
Workaround:
Use git restore to recover deleted files if they were tracked by git.
User theory:
The issue may be related to how Cursor handles file buffers during SSH reconnection - possibly the reload process incorrectly syncs an empty/null state back to the remote filesystem.

Steps to Reproduce

Steps to reproduce:
Connect to remote PC via SSH in Cursor
Open files and make edits using AI agent (StrReplace tool)
Run a command that causes SSH connection to drop (e.g., launching a program that disrupts networking)
Cursor attempts to reconnect and triggers “reload”
Result: Files that were being edited disappear from:
The filesystem (confirmed via ls and git status showing “deleted”)
Open editor tabs

Operating System

Windows 10/11

Version Information

cursor --version
2.5.20
511523af765daeb1fa69500ab0df5b6524424610
x64

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Heya,

so in my case switching to anysphere remote containers seems to have solved it (at least i havent had a crash since). I still often get ssh connection issues and am prompted to reload the workspace, but not a big deal, I do have a monstrous workspace.

Also a few more details:
-my .envs got wiped, which were in the my gitignore, so don’t think’s directly related to git.
-strangely enough some of the wiped files / changes were recoverable in the chat (but not the transcript). Basically any “changes” codeblocks that was still within the truncated chat history could be opened and i could use CMD+A to select everything. Tried a long time to see exactly where these were but wasn’t able to find them, so just used a small script in my dev tools console to make the process faster. Managed to recover about 1/2 of what i lost which was still quite useful in my case.
-might be worth mentioning i was running a nanoclaw setup with multiple concurrent AppleContainers, these have been a bit buggy so far

For your 4 questions:

1. How are the two repos opened? Multi-root vs separate windows

Multi-root workspace. Using a .code-workspace file at colony-os/db/mmini.code-workspace with these roots:

  • .. (colony-os)

  • ../../molerat-egg

  • ../../colony-dashboard

  • ../../colony-os

All four roots (colony-os, molerat-egg, colony-dashboard) are in a single workspace, not separate Cursor windows.

2. macOS Tahoe (26) — is it beta?

Yes. macOS Tahoe 26 is a beta release. Filesystem-level issues are plausible as a contributing factor.

  1. No tengo

  2. Extensions installed

Remote (SSH host — emiglio):

  • andrepimenta.claude-code-chat

  • saoudrizwan.claude-dev

8

Also last thing i’ll add I forgot to mention, I was using Cline add on (which is kind of broken and glitchy btw) with codex, not sure if that could’ve caused issues

9

Update, bug has happened again, so Anysphere doesn’t seem to have fixed it.

This time it happened as I came back after being away from my setup (that was left on and running, I’m running it as a server).

While I was away, I had autonomous agents of my own work on some parts of the project opened in my cursor workspace (they run 24/7 on the remote machine, whereas my cursor runs works on the client / my laptop). Could be related, I’m not sure.

This time when I opened my laptop it “looked” alright, but then i was told by the agent that I was unable to connect or connection failed i forgot, but there was a “new version available” so i clicked it thinking it was the reason behind the issue. When I reopened it (just now) I got nudged down to composer 1.5 for “credit reasons” (I was erroneously blocked today for about 10 mins today already because I “hadn’t paid my latest invoice” , even though all my invoices were paid).

When I switched back to sonnet 4.6 and “resent” the request, i noticed at that point files were missing. I have a github backup from a few hours ago, but it is starting to get costly.

I’ve saved the “Output” logs, can send them to you if you want but not sure they contain anything useful, from GPT:

What the log shows

The log you pasted does not show a normal SSH failure. The SSH connection itself comes up cleanly, the Cursor remote server installs cleanly, the code server starts, and the multiplex ping stays healthy for over an hour via repeated successful echo 1 checks. In other words: the transport layer is alive; the little goblin is elsewhere.

You can see that from:

  • successful install and startup

  • exitCode==0

  • isFatalError==false

  • regular successful ping cycles every minute

  • no crash, auth failure, or disconnect loop in the excerpt

So from this log alone, the likely conclusion is:

the bug is probably not Tailscale or SSH transport dying
it is more likely a Cursor Remote SSH / reload / workspace-state bug.

-Ran ls -la, did a full scan of my computer, but no success here.
-Nope nothing there.
-No smoking guns here, can send output if you want.

Also I do have a very large project, think it’s 1.4 gb, i have apple containers being mounted and dismounted on the go, and 2 large partially symlinked folders. Also running pm2 to keep my setup running.

Let me know if you need more info, happy to give more details or let you guys snoop around on my mac mini if you want, nothing sensitive on it.

Also:
on my client:
anthropic.claude-code
anysphere.remote-containers
anysphere.remote-ssh
coenraads.bracket-pair-colorizer-2
esbenp.prettier-vscode
formulahendry.code-runner
ms-vscode-remote.remote-wsl
ms-vscode-remote.vscode-remote-extensionpack
ms-vscode.js-debug-nightly
ms-vscode.remote-server
openai.chatgpt
pranaygp.vscode-css-peek
wallabyjs.quokka-vscode
zhuangtongfa.material-theme

On my remote mac mini I don’t think i have any extensions, think i might’ve just installed cursor cli

10

Hey, thanks for the update and for staying in touch.

This is an important detail. It means switching to Anysphere Remote Containers wasn’t the root cause, so the bug is deeper. The team is aware of the issue. Your update helps with prioritization since a few users are seeing the same thing.

A couple things:

  1. Those Output logs Anysphere Remote SSH, yep, please send them over. Even if it looks like nothing interesting at first, it helps engineers see the full picture. You can paste them here as a code block or use pastebin.

  2. When this last incident happened, were you already on version 2.6.11, or did you update during the session? You mentioned new version available.

  3. You’ve got a pretty unusual setup multi-root workspace 1,4 GB, AppleContainers mount and unmount, pm2, autonomous agents. Can you clarify, do those autonomous agents modify files in the same directories that are open in the Cursor workspace?

As a workaround, besides git backups, try splitting the multi-root workspace into separate Cursor windows, one repo per window. That reduces the surface area and helps confirm whether the bug is tied to the multi-root setup.

Let me know once you have the logs.

11

*1)I have the Output logs from Anysphere Remote SSH. They contain system paths and machine identifiers from my Mac mini that I’d rather not post publicly. Can I send them via a private channel (e.g. support email or DM)? If not, I can redact hostnames, usernames, and paths and paste the redacted version here.

  1. I was not on 2.6.11 when the incident started. I saw “new version available,” clicked to update, and then reopened Cursor. So the deletion may have occurred during or right after that update/reconnect

3)Yes. The autonomous agents run on the remote Mac mini and can modify files in the same directories that are open in my Cursor workspace. Cursor connects via SSH from my laptop, so both Cursor and the agents operate on the same remote filesystem (cursor has a wider scope though). The first time it happened, agents weren’t autonomous yet, so i’d rule out them deleting the files directly. Also have fairly large symlinked folders in there.*

12

I’ve sent you a DM.

13

Checked the logs. Here’s what stands out.

The SSH transport is fully stable: connection in 393 ms, exitCode == 0, and a ping every minute works for over an hour with zero failures. This confirms the issue isn’t Tailscale or the SSH tunnel. It’s likely somewhere in Cursor’s reconnect or reload logic.

From git diff, it looks like not only git-tracked files were removed, but also vault/ and .env which are in .gitignore. So this is definitely not a git operation. The pattern matches what we’ve seen from other users.

A few things from the logs I want to clarify:

  1. In the nanoclaw logs, I see an infinite cleanupOrphans loop container-runtime.js:67 about every 10 seconds. This process runs execSync and fails regularly. This might be a contributing factor. Can you check if cleanupOrphans touches files in the working directory, or if it only deals with containers?

  2. You mentioned you saw “new version available” and clicked update. Did the deletion happen after the restart on the new version, or did you notice missing files before updating?

  3. I see that at the time of the incident, the leonardo, travis, and jenny agents were actively running. They have recent sessions and logs. Can you confirm if their CLAUDE.md or rules include any file cleanup steps? Or is it strictly read and write only, with no deletes?

The team is aware of the issue. A few users have hit the same pattern SSH remote plus disconnect or reload leads to files being deleted. Your logs help us prioritize this because we haven’t had data this detailed yet.

To narrow down the cause, I suggest one experiment: open the project in a separate Cursor window not a multi-root workspace, with no autonomous agents running, and work like that for a couple days. If it reproduces in clean conditions, it’s 100% on our side. If it doesn’t, we’ll know multi-root plus concurrent agents plays a role.

Let me know about the questions above.

14

Similarly, I encountered the same problem. My local environment is a MacM1, and the remote environment is a Macmini SSH. It’s an Anysphere plugin.

I had the same problem as the blogger: the cursor froze, then restarted, and I just discovered that it deleted all my files at 19:47, and LocalHistory cannot be recovered.

It’s so frustrating. I wrote for two days, and now everything is gone. I can’t even recover my code from the chat history.

Version: 2.6.21
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
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: Darwin arm64 24.6.0

Here’s my guess:
Because of the potential weak network environment, could it be that:
First time: The network disconnected and reconnected, and during the recovery of the workspace, the network disconnected again when it was 30% complete.

Second time: The network disconnected and reconnected, only recovering the previous 30%

ultimately leading to the deletion of a large amount of file data.

-

I found a post online with the same question; please refer to it here: https://wpzyh.com/73691.html

15

Hey, we know about this issue and we’re tracking it. We’re seeing the same pattern across several users: the remote SSH session freezes, Cursor reloads, and files get physically deleted from disk. Your report really helps. Another data point for the Mac M1 → Mac mini setup confirms this isn’t tied to one specific environment.

A few things that could help us debug:

  1. Next time, if this happens again hopefully it won’t, before you restore anything, please grab the SSH logs: View > Output > then pick Remote SSH in the dropdown. Paste them here, or if there’s sensitive info, feel free to redact it.
  2. Were you using a multi-root workspace a .code-workspace file with multiple folders, or a single project?
  3. Were the deleted files in git tracked, not in git untracked, or both?

In the meantime, here are some practical workarounds to reduce the impact:

  • Commit more often, even WIP commits. git restore . is the fastest way to recover if the files are tracked.
  • If you work with untracked files new files, .env, etc, make manual backups or set up a cron job to copy them.
  • Avoid letting Cursor auto-reload after it freezes. If you see unable to connect, try waiting a bit instead of reloading right away.

The team is aware. Your report helps with prioritization since it confirms the bug is still present in 2.6.21.

Let me know if you manage to grab those logs next time.

16

It’s true that my development habits were poor. I’ve now changed my development environment to local testing + remote deployment. There shouldn’t be a chance to reproduce it again.

However, regarding your question, “Were you using a multi-root workspace a .code-workspace file with multiple folders, or a single project?”, I can clearly tell you it’s only a single project.

17

Useful detail about a single project, it helps narrow down the cause. Before, we suspected a multi-root workspace might be involved, but your case rules that out.

Sorry you lost two days of work. Switching to local development with remote deployment is a reasonable workaround for now.

The team is aware of this issue. Your report helps with prioritization, especially the confirmation that single projects are affected too. If you go back to SSH development and hit this bug again, SSH logs from View > Output > Anysphere Remote SSH would be really helpful.