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!!!
Hey, this is a serious report, let’s figure it out.
First, about recovery. If the files were tracked by git, try:
git status to see which files are marked as deleted
git restore . to restore all deleted files that exist in the latest commit
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:
Were you using Agent or Composer during this session? If yes, did you undo or revert any checkpoints?
What does git status show right now in the repo? Are files marked as deleted, or is the whole folder empty?
What’s inside %USERPROFILE%\.cursor\worktrees\ right now? Are there full copies of the files?
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 ..
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.
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.
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:
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:
That .git/worktrees/ directory no longer exists (destroyed with the original .git). The worktree file copies from .cursor\worktrees\ also contain zero-filled files.
[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
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).
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.
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.
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.
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 but that one was over SSH. A local Windows case at this scale is new.
Claude Code plus Cursor worktrees are two possible vectors:
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 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.
Another known vector is Cursor overwriting .git/worktrees/*/gitdirAgent modifies git internal files outside workspace, corrupting worktree references 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:
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.
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.
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.
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:
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:
[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
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
Cursor’s Git extension opened all 18 worktrees (9 Cursor + 9 Claude Code) as repositories
Claude Code was not active — no session running between 00:41 and 16:51
Cursor’s WorktreeCleanupCron was the only automated process managing worktrees
The 9 Claude Code worktrees were “foreign” to Cursor’s WorktreeManager
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.
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.