SSH Remote deletes ENTIRE home directory when workspace is set to `~` — repeated data loss including conda, SSH keys, PDFs, and project files

Support Bug Reports
, ,
1

# Critical: SSH Remote deletes ENTIRE home directory when workspace is set to `~` — repeated data loss including conda, SSH keys, PDFs, and project files

## Summary

When using Cursor SSH Remote with the workspace set to the user’s **home directory** (`/home/liuzhenyin`), Cursor’s reconnect/session-reset logic **physically deletes nearly all files** from the home directory — including `miniconda3/`, `.ssh/`, `.bashrc`, project directories, and multi-GB research data. This happened **at least 3 times** within a single hour on June 16, 2026, while I was actively working.

This is the most destructive variant of the known SSH file-deletion bug. Because the workspace was `~`, the blast radius was the **entire home directory**, not just a project folder.

## Environment

| Item | Value |

|------|-------|

| Local OS | Windows |

| Remote OS | Ubuntu 20.04.6 LTS, kernel 5.15.0-60-generic |

| Remote filesystem | btrfs 17TB on /dev/sda1, mounted at /home |

| Cursor server commit | `776d1f9d76df50a4e0aeca61819a88e7c1b861e0` |

| Connection | SSH Remote (Anysphere Remote SSH) |

| Workspace path | `/home/liuzhenyin` (the entire home directory) |

| Hostname | SRJ (shared lab server, multi-user) |

## What happened

### Timeline (all times CST, June 16, 2026)

**Occurrence 1 — between Jun 14 and Jun 16 15:49**

- Jun 14: Long working session. Home contained: git repo, miniconda3, SSH keys, ~40 MinerU-parsed PDFs, `.env`, project configs.

- Jun 16 15:48–15:49: First login from a new IP. **Everything gone.** Home contains only `.cursor-server/`, `.cursor/`, `.cache/`, `.local/`.

**Occurrence 2 — 16:25 → 16:31**

- 16:19–16:25: Restored project from GitHub, reinstalled miniconda, re-ran MinerU, regenerated SSH keys.

- 16:31: MinerU hit `FileNotFoundError` mid-run — PDF gone. `ls ~/` empty again. `stat ~` mtime → 16:31:58.

**Occurrence 3 — ~16:35**

- Home cleaned again during the same Cursor session.

### Evidence: not admin, not cron, not user error

| Ruled out | Evidence |

|-----------|----------|

| User deleted files | No `.bash_history` (fresh home); only my account active |

| Admin/cron cleanup | Empty crontab; system cron only logrotate/apt |

| Temporary filesystem | btrfs 17T on `/dev/sda1`, not tmpfs |

| System reboot | Last reboot Jun 12 |

| Other users affected | Other home dirs untouched (mtimes Jun 12–15) |

| Agent commands | Full transcript reviewed — no `rm -rf ~` |

### Evidence: Cursor is the cause

1. **Surviving files = Cursor footprint only**: `.cursor/`, `.cursor-server/`, `.cache/`, `.local/`

2. **Timing matches Cursor activity**, not idle periods

3. **`.cursor-server/data/snapshots/`** has only transcripts/terminals — NOT project files or conda

4. **Terminal log at deletion moment**:

```

16:31:37 unzip completed (16 zips) ← files exist

16:31:47 FileNotFoundError: PDF gone ← deleted mid-process

16:31:58 stat ~ mtime updated

```

5. **Same pattern as known reports** (see related threads below)

### What was lost (each time)

| Item | Recoverable? |

|------|--------------|

| Project code (~100 files) | Yes — GitHub |

| miniconda3 (~2 GB) | No — reinstall |

| ~/.ssh/ | No — regenerate keys |

| .env, .bashrc | No |

| knowledge/parsed/ (~500 MB, 40 docs) | No — re-run MinerU ($) |

| knowledge/raw/*.pdf (33 files) | No — re-upload |

**~3 GB lost per occurrence. 3 times in 1 hour.**

## Why this is worse than previous reports

Previous reports: deletion within a **project folder**.

My case:

1. **Workspace = `~`** → entire home is in scope

2. **Non-project files destroyed**: conda, SSH keys, shell config

3. **No git protection** for miniconda, PDFs, `.ssh`

4. **Active long-running process** interrupted when files deleted under it

5. **Repeated 3x/hour** — each recovery destroyed by next reset

## Root cause hypothesis

Same as forum topic **#163075** (Remote-SSH deletes files on reconnect/checkpoint):

> Reconnect reconciles recently-touched files against a **stale or empty snapshot**, and **pushes deletes to disk** for files not in that snapshot.

When workspace = `~`, snapshot only has Cursor metadata → everything else gets deleted.

## Requested fixes

1. **Never delete on empty/stale snapshot** (also requested in #163075)

2. **Warn or block workspace = home directory**

3. **Never delete outside project/git tree** (conda, `.ssh`, dotfiles)

4. **Confirm before bulk delete**

5. **Trash instead of permanent delete**

## Steps to reproduce (WARNING: destructive)

1. SSH Remote, open `~` as workspace

2. Add conda, SSH keys, git project, large data files

3. Work 1+ hours with AI agent edits

4. Trigger reconnect/reload (network blip or session reset)

5. Observe: home cleaned, only `.cursor*` remains

## Related threads (topic IDs — add links in a follow-up comment if needed)

- **#154049** — Critical bug, SSH Remote deletes workspace files on disconnect/reconnect (3rd occurrence)

- **#163075** — Remote-SSH deletes files on reconnect / Restore Checkpoint (server-side logs)

- **#152075** — Undo deletes files on SSH Remote workspace

- **#154532** — Files deleted after SSH reconnection during remote editing

- **#154495** — Cursor IDE rogue file deletion

*(New forum accounts are limited to 2 links per post. Search these topic IDs on forum.cursor.com.)*

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Hey, thanks for the detailed report. The logs, timeline, and evidence really help.

This is a known bug on our side. When you disconnect and reconnect an SSH Remote session, Cursor can physically delete files from the working directory while not touching git. The index and HEAD stay intact, so it’s not a reset, checkout, or stash. The exact mechanism isn’t publicly confirmed yet. Most likely the cleanup or reconnect routine removes files that aren’t in the current snapshot, and if your workspace is set to ~, that can end up affecting basically your whole home folder. We’re tracking the issue, but I can’t share an ETA for a fix yet.

What to try for recovery in this order:

  • Trash: check ~/.local/share/Trash. Some files may have been moved there instead of being deleted forever.
  • Git tracked files: if the index is intact, deleted files will show as D. Running git restore . will bring them back to the last commit.
  • Unsaved or untracked changes: use Local History in the IDE. Explorer → Timeline, or right click a file → Open Timeline. The cache is stored in ~/.cursor-server/data/User/History/.
  • btrfs: since your FS is btrfs, check snapshots. Try sudo btrfs subvolume list /, and look for a .snapshots/ folder if you use snapper or timeshift. This may restore things like conda, .ssh, or PDFs that are not in git.

If anything else disappears, please collect diagnostics for us. It really helps the investigation:

  • output of ls -la ~ right after the incident
  • logs from Output → Anysphere Remote SSH
  • ~/.cursor-server/data/logs/ from the remote host

How to reduce risk until this is fixed:

  • Don’t open ~ as your workspace root. Open a specific project folder instead. This limits the blast radius.
  • Keep each repo in its own window and avoid opening a very broad root folder.
  • Commit more often, even WIP. Back up untracked data like conda, .ssh, .env, and large datasets separately using rsync or cron.
  • Just in case, don’t connect a second client to the same session during reconnect. We haven’t confirmed a direct link to the trigger, but it’s a reasonable precaution.

Let me know if any of the recovery options worked, or if you’ve got questions.