Cursor removes active worktree directories and then closes/crashes unexpectedly

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor appears to be incorrectly cleaning up active git worktrees: directories that are still in use become missing, which causes repeated ENOENT / not a git repository errors in open workspaces, followed by intermittent Cursor self-closing/crash behavior.

Steps to Reproduce

Open Cursor on macOS and open a repo that uses git worktrees (keep only 1-2 worktrees open).
Work normally in those worktrees for a while (edit files, switch branches, run git actions in Cursor).
Continue using Cursor until one open worktree path becomes invalid/missing.
Observe errors in Cursor such as ENOENT for worktree paths and repeated fatal: not a git repository …/.git/worktrees/…
Keep working after those errors appear; Cursor eventually closes/crashes on its own.

Expected Behavior

Cursor should never delete or invalidate a git worktree that is currently open or actively in use.
Open workspaces should continue to resolve to valid paths, with no ENOENT or not a git repository errors caused by internal cleanup.
Background cleanup should only target truly stale, unused worktrees and should verify they are not active first.
Cursor should remain stable and not close/crash as a side effect of worktree management.

Operating System

MacOS

Version Information

Version: 3.4.20 (Universal)
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Date: 2026-05-15T02:26:10.351Z
Layout: glass
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 25.4.0

Additional Information

Cursor logs show active worktree paths later failing validation with ENOENT (directory no longer exists).
The same session shows WorktreeCleanupCron registered and running on a 6-hour interval.
Git extension logs repeatedly report fatal: not a git repository for paths under .git/worktrees/…, consistent with worktrees being removed/invalidated while still referenced.
Main process logs show repeated MCP process crash/restart failures and eventual fallback after exceeding restart budget, indicating broader instability around the same timeframe.
macOS DiagnosticReports (.diag) from affected periods include file-removal call stacks (removeItem, removefile, unlink) inside Cursor-related processes, supporting the unexpected deletion symptom.

Does this stop you from using Cursor

Yes - Cursor is unusable

9

Hi @Nate_Perry-Thistle Thanks very much for reporting, and I apologize for the inconvenience. we’ve replicated this internal and we have a bug report open to fix. I’ll let you know when it’s sorted out! Thanks for letting us know.

10

Hi @Nate_Perry-Thistle

In the meantime, here are some settings you can tweak that might help. You can also drop this into cursor and ask the agent to make these changes for you:

Add this to your Cursor Settings → Open Settings (JSON):

{

"cursor.worktreesGlobalMaxSizeGb": 0,

"cursor.worktreeMaxCount": 100,

"cursor.worktreeCleanupIntervalHours": 168

}

Not 100% this will solve it but I think this will help.

  • worktreesGlobalMaxSizeGb: 0 disables size-based cleanup entirely.

  • A higher worktreeMaxCount reduces count-based eviction pressure.