# Critical Data Loss Incident: repository appears deleted or renamed during/after indexing on Windows 11 **URL:** \ **Category:** Bug Reports\ **Tags:** indexing, windows, worktrees\ **Created:** [April 13, 2026, 12:47pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534 "2026-04-13T12:47:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Igor\_P](https://avatars.discourse-cdn.com/v4/letter/i/a587f6/32.png) [@Igor\_P](https://forum.cursor.com/u/Igor_P)\ **Post date:** [April 13, 2026, 12:47pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/1 "2026-04-13T12:47:02Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug Cursor on Windows 11 appears to have deleted or renamed my repository path during or after codebase indexing. The logs show Cursor opening the repo normally, indexing real source files successfully, and later logging Watcher shutdown because watched path got deleted at 2026-04-13 11:52:37. The original working tree was left hollowed out, while surviving copies were later found under Cursor-managed worktrees. This is a critical data-loss incident involving over a year of work and needs immediate engineering investigation and recovery guidance. **Cursor’s worktree cleanup mistakenly operated on the main working tree rather than just the worktree directories** , or its file operations confused the main repo path with a worktree path. ### Steps to Reproduce On Windows 11, open a large existing Git repository in Cursor 2.6.20. Allow Cursor to treat it as a normal repository and begin initial scan/indexing. Leave Cursor open while indexing/retrieval processes run over the workspace. During the same session, Cursor successfully scans and indexes large portions of the repository, including backend, frontend, docs, and tests. At some later point in the same session, Cursor logs Watcher shutdown because watched path got deleted. After that event, inspect the original workspace directory on disk. ### Operating System Windows 10/11 ### Version Information Cursor version: 2.6.20 ### Additional Information FINAL MESSAGE TO YOU: YOU DELETED 1 YEAR OF MY WORK AND I WANT IT BACK!!! ### Does this stop you from using Cursor No - Cursor works, but with this issue ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [April 13, 2026, 2:20pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/5 "2026-04-13T14:20:14Z")
Hey, this is a serious report, let’s figure it out. First, about recovery. If the files were tracked by git, try: 1. `git status` to see which files are marked as deleted 2. `git restore .` to restore all deleted files that exist in the latest commit 3. Check `%USERPROFILE%\.cursor\worktrees\` You mentioned copies were saved there, so you might be able to recover part of your work from that folder Now about the cause. The message “Watcher shutdown because watched path got deleted” is an observation, not the cause. The file watcher only notices the path is gone, it doesn’t delete anything. The indexing pipeline is also read-only, it only reads files to build embeddings. The team knows about this class of issues, and your report helps with prioritization. To narrow down the cause, I need a couple details: 1. Were you using Agent or Composer during this session? If yes, did you undo or revert any checkpoints? 2. What does `git status` show right now in the repo? Are files marked as deleted, or is the whole folder empty? 3. What’s inside `%USERPROFILE%\.cursor\worktrees\` right now? Are there full copies of the files? 4. Did Cursor update or did you reload the window right before the files disappeared? Let me know if you were able to restore the files with `git restore .`. ---
**Author:** ![Igor\_P](https://avatars.discourse-cdn.com/v4/letter/i/a587f6/32.png) [@Igor\_P](https://forum.cursor.com/u/Igor_P)\ **Post date:** [April 13, 2026, 2:36pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/7 "2026-04-13T14:36:05Z")
> [@Igor\_P](#): > > **Cursor’s worktree cleanup mistakenly operated on the main working tree rather than just the worktree directories** , or its file operations confused the main repo path with a worktree path. Thanks for the response. I understand that `Watcher shutdown because watched path got deleted` is an observation, not the cause. My concern is identifying what local process actually removed, renamed, moved, or replaced the workspace path during that session. On recovery: - `git restore .` is not a complete solution in this case. - The affected workspace was left as a partial shell, and the original Git working-tree state was no longer intact afterward. - I did find surviving copies under `%USERPROFILE%\.cursor\worktrees\…`, but the copy I recovered appears to be an older snapshot, not the current state of the repository immediately before the incident. - So at this point I have only partial recovery, not full restoration of the lost state. To answer your questions: 1. Agent / Composer usage I was using Cursor normally during the session. I need engineering to check the session logs for any Agent, Composer, checkpoint, revert, restore, or worktree-related operations near the incident timestamp. If you need exact correlation, please trace all internal events around `2026-04-13 11:52:37`. 2. Current repo state / `git status` The original workspace was hollowed out. This is not just a normal “files deleted in working tree” situation. The original `.git` metadata / repo linkage was no longer intact enough for the damaged workspace to be treated as a normal repo. 3. `%USERPROFILE%\.cursor\worktrees\` Yes, there are surviving copies there. However, what I found is not a current replacement for the lost working tree. It appears to be an older Cursor-managed snapshot. 4. Cursor update / reload There was no window reloading or performing an update immediately before the disappearance. Please check whether there was any internal reload, update, worktree transition, checkpoint/revert flow, or cleanup event near the incident timestamp. At this point, one plausible failure mode I want engineering to investigate is this: Cursor’s worktree or snapshot cleanup may have mistakenly targeted the main working tree path, or confused the main repository path with a Cursor-managed worktree path. I am not claiming this is proven, but it is consistent with the observed pattern: the main workspace was hollowed out while older Cursor-managed copies survived under `.cursor\worktrees`. What I need from engineering is: - Determine whether any Cursor-managed process touched, renamed, moved, replaced, restored, reverted, or deleted the workspace path during that session. - Correlate file watcher, indexing, worktree, agent/composer, checkpoint, revert/restore, and window reload/update events around the incident timestamp. - Confirm whether Cursor keeps any additional recoverable local artifacts beyond the visible worktrees. - Treat this as a critical data-loss investigation, not only as a generic watcher/indexing question. ---
**Author:** ![Igor\_P](https://avatars.discourse-cdn.com/v4/letter/i/a587f6/32.png) [@Igor\_P](https://forum.cursor.com/u/Igor_P)\ **Post date:** [April 13, 2026, 2:42pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/8 "2026-04-13T14:42:50Z")
> [@Igor\_P](#): > > **Cursor’s worktree cleanup mistakenly operated on the main working tree rather than just the worktree directories** , or its file operations confused the main repo path with a worktree path. Thanks for the response. I understand that `Watcher shutdown because watched path got deleted` is an observation, not the cause. My concern is identifying what local process actually removed, renamed, moved, or replaced the workspace path during that session. On recovery: - `git restore .` is not a complete solution in this case. - The affected workspace was left as a partial shell, and the original Git working-tree state was no longer intact afterward. - I did find surviving copies under `%USERPROFILE%\.cursor\worktrees\…`, but the copy I recovered appears to be an older snapshot, not the current state of the repository immediately before the incident. - So at this point I have only partial recovery, not full restoration of the lost state. To answer your questions: 1. Agent / Composer usage I was using Cursor normally during the session. I need engineering to check the session logs for any Agent, Composer, checkpoint, revert, restore, or worktree-related operations near the incident timestamp. If you need exact correlation, please trace all internal events around `2026-04-13 11:52:37`. 2. Current repo state / `git status` The original workspace was hollowed out. This is not just a normal “files deleted in working tree” situation. The original `.git` metadata / repo linkage was no longer intact enough for the damaged workspace to be treated as a normal repo. 3. `%USERPROFILE%\.cursor\worktrees\` Yes, there are surviving copies there. However, what I found is not a current replacement for the lost working tree. It appears to be an older Cursor-managed snapshot. 4. Cursor update / reload There was no window reloading or performing an update immediately before the disappearance. Please check whether there was any internal reload, update, worktree transition, checkpoint/revert flow, or cleanup event near the incident timestamp. At this point, one plausible failure mode I want engineering to investigate is this: Cursor’s worktree or snapshot cleanup may have mistakenly targeted the main working tree path, or confused the main repository path with a Cursor-managed worktree path. I am not claiming this is proven, but it is consistent with the observed pattern: the main workspace was hollowed out while older Cursor-managed copies survived under `.cursor\worktrees`. What I need from engineering is: - Determine whether any Cursor-managed process touched, renamed, moved, replaced, restored, reverted, or deleted the workspace path during that session. - Correlate file watcher, indexing, worktree, agent/composer, checkpoint, revert/restore, and window reload/update events around the incident timestamp. - Confirm whether Cursor keeps any additional recoverable local artifacts beyond the visible worktrees. - Treat this as a critical data-loss investigation, not only as a generic watcher/indexing question. > [@deanrie](#): > > Hey, this is a serious report, let’s figure it out. > > First, about recovery. If the files were tracked by git, try: > > 1. `git status` to see which files are marked as deleted > 2. `git restore .` to restore all deleted files that exist in the latest commit > 3. Check `%USERPROFILE%\.cursor\worktrees\` You mentioned copies were saved there, so you might be able to recover part of your work from that folder > > Now about the cause. The message “Watcher shutdown because watched path got deleted” is an observation, not the cause. The file watcher only notices the path is gone, it doesn’t delete anything. The indexing pipeline is also read-only, it only reads files to build embeddings. > > The team knows about this class of issues, and your report helps with prioritization. To narrow down the cause, I need a couple details: > > 1. Were you using Agent or Composer during this session? If yes, did you undo or revert any checkpoints? > 2. What does `git status` show right now in the repo? Are files marked as deleted, or is the whole folder empty? > 3. What’s inside `%USERPROFILE%\.cursor\worktrees\` right now? Are there full copies of the files? > 4. Did Cursor update or did you reload the window right before the files disappeared? > > Let me know if you were able to restore the files with `git restore .`. Or I can give you even more insights just as a finished a deeper investigation on the incident. Your suggestions don’t apply here. Let me explain why. **`git restore .` is not possible.** The original `.git` directory was destroyed during the incident. I had to re-clone from GitHub at 13:00:22 to get a working git repo back. The reflog proves this: ```auto cc179cc HEAD@{2026-04-13 13:00:22 +0200}: clone: from https://github.com/paveigor/SyntegraOS ``` There was nothing to restore FROM — the git object database was gone. **This was not a simple deletion.** Files were not deleted — they were **zeroed out**. 2,397 out of 4,537 source files still exist on disk with their correct file sizes, but their content is entirely null bytes (`\x00`). For example: - `backend/world_graph/agentic/agent_core.py` — 25,929 bytes, all zeros - `backend/requirements.txt` — 1,887 bytes, all zeros - `frontend/src/tests/components/Documents/DocumentsTab.test.tsx` — all zeros This is not what happens when a user deletes a file. This is not what happens when a path is removed. This is what happens when something **overwrites file content with null bytes while preserving file metadata**. **The Cursor worktrees are also corrupted.** The copies in `%USERPROFILE%\.cursor\worktrees\world-graph\` have their `.git` files pointing to: ```auto gitdir: C:/Users/Entraf Ryzen/Documents/Python/world-graph/.git/worktrees/jom ``` That `.git/worktrees/` directory no longer exists (destroyed with the original `.git`). The worktree file copies from `.cursor\worktrees\` also contain zero-filled files. ### Timeline from YOUR logs | Time | Event | Log file | | --- | --- | --- | | 10:38:26 | `[WorktreeManager] Loaded 9 worktree metadata entries` | renderer.log | | 10:38:28 | **`[WorktreeCleanupCron] Registering cleanup task with interval of 6 hours`** | renderer.log | | 10:38:30 | Git extension opens repo normally | Git.log | | 11:10:58 | Indexing starts: uploading 17,754 files, 64,354 to embed | Indexing.log | | 11:12:44 | Indexing successfully processes source files | Indexing.log | | 11:52:37 | **`Watcher shutdown because watched path got deleted`** | fileWatcher.log | | 11:52:39 | Second watcher shutdown | fileWatcher.log | ### Answering your questions 1. **Agent/Composer usage:** I was using Claude Code (Anthropic CLI), not Cursor Agent or Composer. Claude Code creates its own git worktrees under `.claude/worktrees/`. Cursor’s Git extension detected these at 11:12:01 (see `worktree-agent-a4be8c82`, `worktree-agent-a658ba12`, `worktree-agent-a79de31c` in Git.log). 2. **git status:** Not applicable — the `.git` was destroyed. I had to re-clone. The current state after recovery: 2,397 source files are zero-filled. 3. **Cursor worktrees:** 9 directories exist (`fle`, `gyj`, `jom`, `peu`, `qkd`, `sxn`, `tye`, `wmd`, `wuk`). All have broken `.git` references. File contents are partially corrupted (zero-filled) just like the main working tree. 4. **Update/reload:** I did not update Cursor or reload the window before the incident. ### What I need from engineering The `WorktreeCleanupCron` registered at 10:38:28 is the only active automated file-management process Cursor logged in this session. You say the file watcher is read-only and the indexer is read-only. **What does `WorktreeCleanupCron` do?** Does it delete or modify files? Does it interact with git worktrees? My path contains a space (`Entraf Ryzen`) — was this tested? The zeroed-out files suggest a process that opened files for writing and truncated/overwrote them rather than deleting them. This is not consistent with a user action or a filesystem error. Something actively wrote null bytes to 2,397 files. ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [April 13, 2026, 3:03pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/9 "2026-04-13T15:03:20Z")
Thanks for such a detailed analysis. The null bytes pattern and the log timeline are exactly what engineers need. A few important notes: Null bytes pattern: the fact that 2 397 files were filled with `\x00` when saving metadata like size and name is not a delete or move. It’s an overwrite of the contents. We’ve seen a similar pattern in another report [My huge python file is corrupted by Cursor](https://forum.cursor.com/t/my-huge-python-file-is-corrupted-by-cursor/156616) but that one was over SSH. A local Windows case at this scale is new. Claude Code plus Cursor worktrees are two possible vectors: 1. `WorktreeCleanupCron` was registered at 10:38:28. Cursor detected Claude Code worktrees like `worktree-agent-a4be8c82` via the Git extension. There’s a confirmed bug [Cursor's WorktreeManager force-deleted my git branch when cleaning up agent worktrees](https://forum.cursor.com/t/cursors-worktreemanager-force-deleted-my-git-branch-when-cleaning-up-agent-worktrees/146865) where the cleanup logic uses `git branch --contains` and deletes all branches that contain a commit, not only branches created by Cursor. If cleanup tried to remove Claude Code worktrees, that could have triggered cascading damage. 2. Another known vector is Cursor overwriting `.git/worktrees/*/gitdir` [Agent modifies git internal files outside workspace, corrupting worktree references](https://forum.cursor.com/t/agent-modifies-git-internal-files-outside-workspace-corrupting-worktree-references/155163) redirecting git internal references to Cursor-managed paths. If Claude Code worktrees were active and Cursor was modifying gitdir references in parallel, that could break the `.git` structure. A path with a space like `Entraf Ryzen` is also worth checking as an extra factor in path parsing. Questions: 1. Was Claude Code active and doing operations at the time of the incident around 11:52:37? If you have Claude Code logs from that session, that would really help confirm which tool executed the file operations. 2. Does the `.claude/worktrees/` directory still exist in the project? What’s inside it? Keep in mind those are also git worktrees. Without `.git` they won’t work either, so they probably won’t help much for file recovery. 3. When you ran Claude Code, how many worktrees did it create? Cursor loaded 9 worktree metadata entries at 10:38:26. Were all 9 from Claude Code, or were some created by Cursor? Recovery: since `.git` is gone and you already re-cloned, try Volume Shadow Copy or File History on Windows. If it was enabled, you might be able to restore earlier versions of the files from before the incident. This looks like a new variant of the worktree cleanup issue. It’s likely the interaction between Cursor worktree management and external worktrees like Claude Code plus null bytes corruption plus a Windows path with a space. Let me know if you can share Claude Code logs. ---
**Author:** ![Igor\_P](https://avatars.discourse-cdn.com/v4/letter/i/a587f6/32.png) [@Igor\_P](https://forum.cursor.com/u/Igor_P)\ **Post date:** [April 13, 2026, 3:43pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/10 "2026-04-13T15:43:24Z")
Thanks for the detailed investigation. Here are the answers to your questions with exact evidence. ### Q1: Was Claude Code active at 11:52:37? **No. Claude Code was not running any operations at the time of the incident.** Claude Code session logs are stored in `%USERPROFILE%\.claude\projects\`. The sessions modified on April 13 are: | Session | Last modified | Status at 11:52 | | --- | --- | --- | | `b495ebe7` | 00:16:33 | Idle (finished overnight) | | `193869e6` | 00:40:54 | Idle (finished overnight) | | `b62dbf73` | 16:51:49 | Started AFTER incident (post-recovery) | | `48aa4be2` | 17:35:27 | Current recovery session | No Claude Code session was active between 00:41 and 16:51. The incident at 11:52 happened during a **5+ hour window where Claude Code was completely idle**. Claude Code did not execute any file operations at the time. I can share these session log files (`.jsonl` format) if engineering needs them. ### Q2: What’s in `.claude/worktrees/`? Yes, the directory still exists with 9 worktrees. Here’s the full state: ```auto agent-a4be8c82 | last modified: 2026-04-04 | .git → .git/worktrees/agent-a4be8c82 (BROKEN) agent-a553906b | last modified: 2026-04-09 | NO .git file (created after re-clone) agent-a658ba12 | last modified: 2026-04-04 | .git → .git/worktrees/agent-a658ba12 (BROKEN) agent-a79de31c | last modified: 2026-04-04 | .git → .git/worktrees/agent-a79de31c (BROKEN) agent-a9a2a94e | last modified: 2026-04-04 | .git → .git/worktrees/agent-a9a2a94e (BROKEN) agent-a9dc7979 | last modified: 2026-04-04 | .git → .git/worktrees/agent-a9dc7979 (BROKEN) agent-a9e21ec2 | last modified: 2026-04-04 | .git → .git/worktrees/agent-a9e21ec2 (BROKEN) agent-ab59cbd8 | last modified: 2026-04-04 | .git → .git/worktrees/agent-ab59cbd8 (BROKEN) agent-ac79dacd | last modified: 2026-04-04 | .git → .git/worktrees/agent-ac79dacd (BROKEN) ``` All 8 pre-incident worktrees have `.git` files pointing to `C:/Users/Entraf Ryzen/Documents/Python/world-graph/.git/worktrees/agent-*` — which no longer exists because the original `.git` was destroyed. The file content in these worktrees is also partially zero-filled, same corruption pattern as the main tree. ### Q3: How many worktrees from each tool? **9 from Cursor + 9 from Claude Code = 18 total git worktrees.** Cursor’s `WorktreeManager` log says `Loaded 9 worktree metadata entries` at 10:38:26. These are the 9 Cursor worktrees (`fle`, `gyj`, `jom`, `peu`, `qkd`, `sxn`, `tye`, `wmd`, `wuk`) stored in `%USERPROFILE%\.cursor\worktrees\world-graph\`. The 9 Claude Code worktrees were NOT in Cursor’s WorktreeManager metadata. However, **Cursor’s Git extension DID discover them** — the Git.log shows at 10:38:34-10:38:38: ```auto [Model][openRepository] Opened repository: ..\.claude\worktrees\agent-a4be8c82 (kind: worktree) [Model][openRepository] Opened repository: ..\.claude\worktrees\agent-a658ba12 (kind: worktree) [Model][openRepository] Opened repository: ..\.claude\worktrees\agent-a79de31c (kind: worktree) [Model][openRepository] Opened repository: ..\.claude\worktrees\agent-a9a2a94e (kind: worktree) [Model][openRepository] Opened repository: ..\.claude\worktrees\agent-a9dc7979 (kind: worktree) ``` So Cursor knew about Claude Code’s worktrees via the Git extension, but they were NOT in the WorktreeManager’s metadata. **This is a critical detail** : if `WorktreeCleanupCron` used the Git extension’s repository list instead of (or in addition to) WorktreeManager’s metadata, it would have seen Claude Code worktrees as “unmanaged” worktrees and potentially tried to clean them up. ### Q4: Volume Shadow Copy We used Volume Shadow Copy to recover a filesystem snapshot from `2026-04-12 23:00`. What we did: - mounted the shadow copy via a temporary directory link - copied the whole `world-graph` tree out of that snapshot - saved it as: `C:\Users\Entraf Ryzen\Documents\Python\world-graph_shadow_recovery_20260412` What it gave us: - a much newer project snapshot than the old Cursor worktree recovery - lots of recovered source files - the `.git` directory from that point in time What turned out wrong in it: - some files were zero-filled / null-corrupted - `.git/config` was corrupted and had to be rebuilt - Git index/pack state was unhealthy, so we could not trust that repo as a working Git checkout - `backend/world_graph.db` from that shadow copy was unusable: ### Additional finding: the `WorktreeCleanupCron` DID fire Your renderer log shows: ```auto 2026-04-13 10:38:28.660 [info] [WorktreeCleanupCron] Cleanup task registered (interval: 6h) 2026-04-13 16:38:28.662 [info] [WorktreeCleanupCron] Running scheduled worktree cleanup 2026-04-13 16:38:28.675 [info] [WorktreeManager] Using worktrees root: .cursor\worktrees ``` The cleanup ran at 16:38 (6 hours after registration), which is AFTER my re-clone at 13:00. But the question is: **could the initial registration at 10:38 have triggered an immediate cleanup** before the cron interval? Or could there be a cleanup that ran between 10:38 and 11:52 that isn’t logged because it was part of the registration process? ### Summary of the interaction model 1. Cursor’s Git extension opened all 18 worktrees (9 Cursor + 9 Claude Code) as repositories 2. Claude Code was **not active** — no session running between 00:41 and 16:51 3. Cursor’s `WorktreeCleanupCron` was the only automated process managing worktrees 4. The 9 Claude Code worktrees were “foreign” to Cursor’s WorktreeManager 5. Files were zero-filled, not deleted — consistent with a process opening files for write and truncating This points to Cursor as the sole active agent at the time of the incident. I’m happy to share any log files engineering needs. ---
**Author:** ![Anurag\_Kumar](https://avatars.discourse-cdn.com/v4/letter/a/e495f1/32.png) [@Anurag\_Kumar](https://forum.cursor.com/u/Anurag_Kumar)\ **Post date:** [April 14, 2026, 1:19pm UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/11 "2026-04-14T13:19:30Z")
I’ve experienced this issue as well, and it was quite concerning. In my case, some of the uncommitted files suddenly became blank (0-byte files), which suggests the content was wiped out rather than the files being fully deleted. I wasn’t performing any explicit destructive action at the time, so it’s unclear what exactly triggered it—possibly indexing or some background operation. This makes it particularly risky because uncommitted changes are the most vulnerable and can be lost silently without any easy recovery. Would appreciate if the team could help investigate what specific activity (indexing, agent actions, or worktree handling) might be causing this. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [May 28, 2026, 5:30am UTC](https://forum.cursor.com/t/critical-data-loss-incident-repository-appears-deleted-or-renamed-during-after-indexing-on-windows-11/157534/13 "2026-05-28T05:30:45Z")
This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.