Parallel agents writes to the root repository instead of the worktree

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I just had a worktree agent write directly to the root repository instead of the worktree. When asked why, it said

> why did you modify a file in the root repository and not the worktree?

You're right, I made a mistake. The system instructions say to only edit files within the worktree at /Users/josteingogstad/.cursor/worktrees/the_repo/bqe, but I edited the file in the main repository.
Let me fix this by reverting the change in the main repo and making it in the worktree instead.

it looks like this feature works at the mercy of the model always honoring instructions in the system prompt. That evidently is not enough, the model makes mistakes. The IDE needs to have more guardrails, e.g. let the tools it uses to write files refuse to write to the wrong location

Steps to Reproduce

  • open a parallel agent, ask it to write something to .cursor/new_rule.mdc

in my case it wrote to the wrong worktree

Operating System

MacOS

Version Information

Version: 2.4.22
VSCode Version: 1.105.1
Commit: 618c607a249dd7fd2ffc662c6531143833bebd40
Date: 2026-01-26T22:51:47.692Z (1 day ago)
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 24.6.0

For AI issues: which model did you use?

Opus 4.5

For AI issues: add Request ID with privacy disabled

request id: 36f6f603-3fa6-4f36-a8f8-c580bc485dab
worktree id: prod-fix-bqe

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

3

Hey, thanks for the report. This is a known issue. Worktree isolation currently relies on instructions in the system prompt, not on tool-level restrictions. Your idea to have file-writing tools reject invalid paths is spot on.

The team is aware of this limitation. Your report with the request ID helps us prioritize it.

For now, the safest workaround is to double-check the agent’s target path before accepting changes. Let us know if you run into any other issues.

4

thank you for the quick reply!

The suggested workaround doesn’t work. The parallel agent writes to the root workspace immediately. When the “Apply” button is presented to the user, the changes to the root workspace has already been written—it’s not possible to review or prevent it

5

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