Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor on Windows automatically creates Git worktrees in C:\Users<user>.cursor\worktrees<project>\ during Agent sessions. Each worktree duplicates the entire repository, consuming significant disk space. In my case, working with a ~2GB codebase (IsaacLab), two worktrees were created in a 20-minute session totaling 9.82 GB. Over a week of use, 20+ worktrees accumulated consuming ~140 GB before I noticed.
This is unexpected because the Terminal documentation states “Sandbox is currently available on macOS only”—yet worktrees (typically associated with sandbox isolation) are being created on Windows. There is no documented setting to disable this behavior. Attempting git.useWorktrees: false and cursor.git.useWorktrees: false in settings.json has no effect.
Steps to Reproduce
Open Cursor on Windows 10/11
Open a Git repository (larger repos make the issue more apparent)
Start an Agent session and interact with the agent (file edits, terminal commands, etc.)
Check C:\Users<user>.cursor\worktrees\ after the session
Observe new worktree folders (random 3-letter names like xwf, cyg, hof) containing full copies of the repository
Expected Behavior
One of the following:
Worktrees should not be created on Windows since Sandbox is documented as macOS-only
If worktrees serve a purpose on Windows, there should be a user-facing setting to disable automatic creation
Stale worktrees should be automatically cleaned up after Agent sessions end
Screenshots / Screen Recordings
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Version: 2.2.20 (system setup)
VSCode Version: 1.105.1
Commit: b3573281c4775bfc6bba466bf6563d3d498d1070
Date: 2025-12-12T06:29:26.017Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200
Additional Information
Observed worktree creation rate:
Worktree Size Created
xwf 8.5 GB 5:39 PM
cyg 1.32 GB 5:44 PM
Total 9.82 GB ~5 minutes apart
Previously accumulated (before manual cleanup):
22 worktrees with names: adv, auz, bbb, eae, ehc, hof, hqf, kjk, lue, mel, nfm, njb, oqz, org, pth, qvd, reu, rmr, ubg, ubi, vme, wrh
Estimated total: ~140 GB
Current workaround:
From main repositorygit worktree pruneRemove-Item -Path “C:\Users<user>.cursor\worktrees” -Recurse -Force
Notes:
This appears to be a recent change; I did not notice this behavior during a sprint a few weeks ago
The issue is most severe with large repositories (ML, robotics, monorepos)
Pro tier user with heavy Agent usage
Does this stop you from using Cursor
Yes - Cursor is unusable
