Cursor Project local agent initially accessed a different local repository than the Project repository

[chiko]

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

This occurred in the new Cursor Projects feature in the Agent Window, involving a Project Coordinator dispatching work to a local/self-hosted agent. “Projects” is not currently available in the product selector above, so I selected “Somewhere else.”

I created a Project for a disposable repository named cursor-project-boundary-test and explicitly instructed the Coordinator not to access anything outside that repository.

However, the first local subagent operated on a different local repository, /Users/mizutanichie/AI-Workspace, listed its repository root, and reported performing a recursive search of that working tree. The Coordinator then recognized this as the “Wrong checkout,” dispatched another local execution, and found the correct Project repository.

The unexpected access to AI-Workspace was visible only after I opened the detailed subagent execution trace; the normal Project-level view showed the task as completed.

Steps to Reproduce

1. Create a disposable private GitHub repository and a corresponding local working copy. In my test, the repository was cursor-project-boundary-test, located at /Users/mizutanichie/cursor-project-boundary-test.
2. Create a Cursor Project in the Agent Window and explicitly select cursor-project-boundary-test as the Project repository.
3. In the local working copy, create an untracked file named local_only.txt containing local-only observation. Do not commit or push the file.
4. Ask the Project Coordinator:

“In the local working copy of this repository on my Mac, there is an untracked file named local_only.txt that has not been committed or pushed. Read that file and tell me its exact contents. Do not create, modify, delete, commit, or push any files. Do not access anything outside this repository.”

5. In my execution, the Coordinator chose local execution, identified a self-hosted worker, and dispatched a local subagent to read the file.
6. In my execution, the first local subagent operated on a different repository, /Users/mizutanichie/AI-Workspace, instead of the selected Project repository. The detailed trace showed that it checked /Users/mizutanichie/AI-Workspace/local_only.txt, listed the AI-Workspace repository root, and reported that a recursive search confirmed the file was absent from the working tree.
7. The Coordinator then recognized the mismatch as “Wrong checkout,” dispatched another local execution, located /Users/mizutanichie/cursor-project-boundary-test, and successfully read local_only.txt.

I have not attempted to reproduce this a second time because the first execution accessed a repository that I had intentionally placed outside the experiment boundary. I stopped further execution and preserved the Project, detailed execution trace, and screenshots instead.

Expected Behavior

I expected the local execution to operate on the Project repository I had explicitly selected, cursor-project-boundary-test, particularly because my instruction also said, “Do not access anything outside this repository.”

I did not expect the first local subagent to operate on or search a separate repository, AI-Workspace.

However, I do not know whether selecting a Project repository is technically intended to enforce a filesystem boundary for Project-dispatched local agents. Part of this report is therefore to clarify the intended behavior: what filesystem scope a local agent is expected to have, how the Project repository is mapped to the local checkout, and what controls are available to the user before local execution begins.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Cursor:

Version: 3.21.13
Build Type: Stable
Release Track: Default
Layout: Agent Window
Commit: e44a49c17e334d442e58bbde931d791200f014a0

For AI issues: which model did you use?

Auto (Project Coordinator; underlying model used by the Coordinator/local subagent was not visible to me.)

For AI issues: add Request ID with privacy disabled

Normal Chat Request ID unavailable — this occurred through a Cursor Project Coordinator / local subagent execution, and I do not see a “Copy Request ID” option in the Project UI.
Agent run ID visible in the Project trace: bc-beff07cb-d349-5f74-8f99-b944fce17028

Additional Information

Additional observations and questions

During the transition to local execution, macOS displayed a system permission dialog stating that Cursor.app wanted access to data from other applications. I selected “Don’t Allow.” I did not grant any additional permission, but the local execution subsequently continued and eventually read the requested file from the correct repository. I do not know what specific macOS permission this dialog governed, so I am not assuming that the permission was bypassed or ignored.

I would appreciate clarification on the following:

Why did the first Project-dispatched local subagent use /Users/mizutanichie/AI-Workspace rather than the local checkout of the Project repository?
How does the Project Coordinator determine or map a Project repository to a local checkout when dispatching a local/self-hosted agent?
What filesystem boundary is intended to apply to a Project-dispatched local agent?
Can the user inspect or constrain that filesystem scope before local execution begins?
What did the macOS “access data from other apps” permission dialog govern in this execution, given that I selected “Don’t Allow” and the local-file operation later succeeded?
Is it expected that the initial wrong checkout, repository-root listing, and reported recursive search were visible only in the detailed subagent trace rather than the normal Project-level execution summary?

Agent run ID visible in the Project trace:
bc-beff07cb-d349-5f74-8f99-b944fce17028

Request ID:
A normal Chat Request ID is not available because this occurred through a Cursor Project Coordinator / local subagent execution, and I do not see a “Copy Request ID” option in the Project UI.

I have preserved the Project without further execution, along with the detailed execution trace and screenshots. I can provide additional screenshots or the complete experiment record if useful.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

Hey @chiko! Thanks for the careful report. When a Project runs something on your machine, it uses a machine you already have connected and runs in the folder that Cursor window has open, not a clone of the Project repo. Your window was open on /Users/.../AI-Workspace and the Project repo wasn’t open anywhere, so the first local run landed there. For a Project that names a specific repo, that isn’t intended, and we’ve let the team know.

To keep it scoped today: open the Project repository in a Cursor window (and close windows on unrelated repos) so the only connected machine points at the right checkout. There’s a documented repo-match guard for chat-based worker= runs (My Machines); the Project coordinator’s local dispatch just didn’t apply it here.

On the macOS “access data from other apps” prompt: that only covers other apps’ ~/Library folders, and your “Don’t Allow” blocked exactly those. Your repo is an ordinary folder, so reading it was never gated by that permission. Nothing was bypassed.

If you can grab the exact command from the “Ran 1 command” step in that first trace, that would help us confirm the search scope.

[chiko]

Hi Mohit, thanks — yes, I still have the first trace.

The exact command shown under “Ran 1 command” was:

ls -la /Users/mizutanichie/AI-Workspace/ | head -50; ls -la /Users/mizutanichie/AI-Workspace/local_only.txt 2>&1; find /Users/mizutanichie/AI-Workspace -maxdepth 2 -name 'local_only.txt' 2>/dev/null

The trace then reported:

Checked path: /Users/mizutanichie/AI-Workspace/local_only.txt

So the search root used by that first local run was /Users/mizutanichie/AI-Workspace, with the find search limited to -maxdepth 2.

I’ve also kept the screenshot of this trace if that would be useful.

[mohitjain (Mohit)]

Thanks @chiko, that confirms it. The first run stayed inside the folder that window had open, AI-Workspace, and the find was capped at maxdepth 2, so it didn’t range beyond that checkout. The only thing that went wrong is that the folder connected to the Project was the wrong one, which is the mapping gap we’ve passed to the team. No screenshot needed, this is enough.

Nothing more for you to do here. Keeping the Project repo open in a Cursor window, with unrelated repos closed, keeps local runs pointed at the right checkout for now, and I’ll post here if there’s an update on the scoping side.