Windows: Request to disable automatic worktree creation - critical disk space issue

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

Hey, thanks for the report. I see the issue with worktrees piling up. Important note: worktrees aren’t for Sandbox (macOS-only). They’re used by Parallel Agents/Best-of-N, which works on all OSes.

Cursor should auto-clean old worktrees. By default it keeps up to 20 worktrees per workspace and cleans every 6 hours. From your note (22 worktrees over a week), cleanup might be failing or running too infrequently.

For diagnostics, please check:

  1. Current settings in settings.json:
{
  "cursor.worktreeMaxCount": 20,
  "cursor.worktreeCleanupIntervalHours": 6
}
  1. Are you using Best-of-N (multiple models at once) or a single agent?

  2. Open logs: Help > Output > select “Worktrees Setup” in the dropdown. Any errors there?

  3. Try more aggressive cleanup settings:

{
  "cursor.worktreeMaxCount": 5,
  "cursor.worktreeCleanupIntervalHours": 1
}

Temporary workaround (your approach is correct):

git worktree prune
Remove-Item -Path "C:\Users\<user>\.cursor\worktrees" -Recurse -Force

You can also show worktrees in the SCM panel:

{
  "git.showCursorWorktrees": true
}

Docs: Parallel Agents | Cursor Docs

The settings git.useWorktrees and cursor.git.useWorktrees don’t exist. Worktrees are created automatically for Parallel Agents.

Please share the results of the settings and logs checks.

1 Like

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.