When using parallel agents with a window opened to a git repo's child folder, the apply button doesn't work

Support Bug Reports
, ,
1

Describe the Bug

I have a monorepo with many different projects in child folders. The projects work best in most of cursor tooling when opening the child folders in a cursor window rather than opening the whole monorepo folder. Using multiple agents (or any workflow that uses worktrees) doesn’t work correctly in this scenario. Clicking “Apply” on a parallel agent’s work fails to apply it. The error popup says it’s looking in the wrong place to apply the work though it was created in the correct place. Apply is looking in child_folder/.git/worktrees… rather than monorepo/.git/worktrees.

Steps to Reproduce

  1. Create a git repo with a child folder.
  2. open the child folder in a cursor window
  3. ask parallel agents to do something
  4. attempt to apply an agent’s work
  5. see error

Expected Behavior

The apply button shouldn’t error

Operating System

MacOS

Version Information

Version: 2.4.31
VSCode Version: 1.105.1
Commit: 3578107fdf149b00059ddad37048220e41681000
Date: 2026-02-08T07:42:24.999Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

For AI issues: which model did you use?

Composer 1.5 and Opus 4.6

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the report. When you open a subfolder of a git repo instead of the repo root, Cursor resolves the .git/worktrees path relative to the opened folder, not the actual repo root. The team is aware, and your report helps us prioritize it.

As a temporary workaround, you have two options:

  1. Open the monorepo root folder in Cursor instead of the child folder when you use parallel agents.
  2. Apply changes from the worktree manually using git commands in the terminal. You can get the worktree paths with git worktree list, then do a cherry-pick or merge from there.

Also, can you share the exact error text from the popup? That’ll help with tracking.

Let me know if either workaround helps.

6

Yup, The first workaround works, but the second only partially works:

  1. My monorepo is larger than the context window for most models so 1 works but not well, so I’d rather not do that.
  2. Cursor’s agent worktrees seem not to be interpoerable with the native worktree implementation - they don’t show up in the panel and are quite awkward to apply with git commands from their nonstandard location, which ends up outside the repo in ~/.cursor/worktrees…

An example of the error text I see is:

```
Failed to apply worktree to current branch: Unable to read file ‘/Users/orvisevans/.cursor/worktrees/admin-portal/yij/src/components/OrderableList/OrderableListContext.tsx’ (Error: Unable to resolve nonexistent file ‘/Users/orvisevans/.cursor/worktrees/admin-portal/yij/src/components/OrderableList/OrderableListContext.tsx’)
```