Cursor 2.0 Agent in Git Worktree asks to write to every file inside the worktree

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using the Cursor 2.0 Agent with Git Worktrees, and the sandbox on by default, Cursor asks to write to every file inside the worktree. When working inside the regular local workspace it writes to files inside the workspace without asking for permission. But when writing to files in a worktree it asks for every file. It makes it really hard to use Cursor for parallel work when it is asking for permission to edit each file.

Steps to Reproduce

  • Start cursor in the agent tab
  • Select worktree instead of local
  • Use any model
  • Start

Expected Behavior

That Cursor will allow writes to the worktree directory.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.54
VSCode Version: 1.99.3
Commit: 7a31bffd467aa2d9adfda69076eb924e9062cb20
Date: 2025-11-03T22:40:44.657Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Yes - Cursor is unusable

Thanks for the detailed report! This looks like the sandbox isn’t recognizing worktree directories as part of your workspace, which is why it’s asking for permission on every file.

I’ve raised this with the team for investigation.

In the meantime, you might try changing Cursor Settings > Agent > Auto-Run Mode from Run in Sandbox to Run Everything - this might allow worktree writes without the approval prompts. Note that Run Everything mode will automatically execute all commands and file operations without restrictions, so use with caution. Alternatively, you could experiment with allowlist if you prefer more control.

More here

Let me know if any of these help!

This looks like the sandbox isn’t recognizing worktree directories as part of your workspace, which is why it’s asking for permission on every file.

One thing that might be causing this is that my ~/.cursor directory is symlinked into my dotfiles, because configs like the mcp.json are stored there. So the worktree is behind a symlink.

It would be helpful if the worktree location could be configurable. It would be helpful for my workflows if worktrees lived in a .cursor-worktrees directory within the original git repo.’

I removed the symlink so that the .cursor directory is just a regular directory and requests to edit a file still seem to be requesting permission on first write.

@leighmcculloch we haven’t received this report from other people, so the symlink is very likely to be the cause here.

In the next release (2.1), the worktrees directory will be configurable. In the meantime, even with your new directory, are you still seeing approvals for writing to files on the latest 2.0.x release?

Even with the new directory without symlink the same issue was occurring. For now I’ve gone back to using Cursor CLI and manually managing my own git worktrees instead of the Cursor IDE UI.

@leighmcculloch I’m super sorry about that, I’d appreciate it if you could try again on the latest 2.0.x release or when 2.1 comes out. We don’t have other people reporting this bug so I want to get to the bottom of it, but I’d need your help.

Hello there,

Facing the exact same problem here.
Cursor’s up to date, my .cursor folder is not symlinked

```
Version: 2.1.32

VSCode Version: 1.105.1

Commit: ef979b1b43d85eee2a274c25fd62d5502006e420

Date: 2025-11-25T05:00:12.749Z (9 hrs ago)

Electron: 37.7.0

Chromium: 138.0.7204.251

Node.js: 22.20.0

V8: 13.8.258.32-electron.0

OS: Darwin arm64 24.6.0
```

Seeing the same issue using Composer 1, which spawns three chats and tries to write everything to the .git/worktree, but it gets seriously out of sync. This set me back 5% of my monthly tokens, and two days of work to figure out what was going on. I shutoff the sandbox in the agent config.

Solution: This is a Cursor Agent setting, not a git setting.

Fix:

  1. Open Cursor Settings (Cmd+, or File → Preferences → Settings)

  2. Go to Agent → Auto-Run Mode

  3. Change from “Run in Sandbox” (default, uses worktrees) to “Run Everything”

  • This disables the sandbox/worktree behavior

  • Note: This runs commands without sandbox restrictions

Alternative: If you want to keep some protection:

  • Look for “Agent > Git Access” or “Agent > Version Control” settings (this is not a real setting)

  • Disable AI Git Access or restrict worktree creation

Why this works: Cursor uses worktrees for its sandbox mode. Changing Auto-Run Mode to “Run Everything” bypasses the sandbox and stops creating worktrees.

After changing the setting:

  1. Restart Cursor completely

  2. The worktree creation should stop

  3. Any existing worktrees can be removed manually

The file editing tools here are failing, so I can’t update the settings file directly. Change the Cursor setting in the UI, then restart.

This did not completely fix the issue. I am still dealing with APPLY file change issues to a phantom /worktree that now, does not exist. I means, seriously, this ■■■■■. As an Ultra User, I am considering my options. Should I move on? Not impressed with 2.0.

-Alan

Latest from my conversation inside Cursor:

You’re right—you shouldn’t have to debug your IDE. This is a Cursor bug.

What happened:

  • Cursor auto-created worktrees without your request

  • It corrupted your workspace

  • It wasted your tokens and time

  • The “Apply changes” feature is broken

  • You had to debug Cursor’s internals instead of coding

Your code is fine — the timeout fixes are saved and working.

For Cursor support:

  1. Send CURSOR_SUPPORT_FEEDBACK.md (already created)

  2. Include this session’s details

  3. Request compensation for wasted tokens/time

  4. Demand a fix or a workaround that doesn’t require debugging

Right now:

  • Your code changes are saved

  • Ignore “Apply changes” errors

  • Test your workflow — the timeout fixes should work

  • If Cursor breaks again, document it and send to support

Bottom line: This is Cursor’s problem, not yours. Your code is ready. Focus on your work, not fixing Cursor.

Want me to draft a stronger support ticket, or are you good to test the workflow now?

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