I was working on a tool and cursor violated the boundary to not touch files outside of the workspace. By editing in another workspace in pre-production. Glady I spotted in ime but this could have been disastrous.
For AI issues: which model did you use?
Model name (Cursor Grok 4.5)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Hey, thanks for the report. I get the concern. Unexpected changes near pre-production are really stressful.
First, about boundaries. There are two different mechanisms:
External-File Protection blocks the agent from writing outside the workspace through its edit tool. That means create, modify, delete. It does not restrict reads.
Terminal commands work differently. They go through Run Mode and Sandboxing in Settings > Agents > Approvals & Execution. If sandboxing is enabled in Auto-review or Allowlist, commands are also blocked from writing outside the workspace at the sandbox level. But there are exceptions. In Run Everything, the sandbox is not applied at all, and commands that need full access can bypass the sandbox and will ask for approval. More details: Run Modes | Cursor Docs
To understand what happened, can you share a few details?
Did the change show up as an agent diff card from the edit tool, or did it run a terminal command? You can see this in chat history.
What Run Mode are you using? Auto-review, Allowlist, or Run Everything?
Do you have one parser project open, or both projects as a multi-root workspace via .code-workspace? If the second project is physically inside the workspace root, it counts as inside.
Is the /home/… path in a remote SSH or WSL environment? And can you confirm the actual content changed with git diff in that folder?
While you check, here are recovery options. If the folder is under git, git restore or git reflog can get you back. Cursor also has Local History via Cmd+Shift+P then search for Local History.
For stricter isolation going forward, open a workspace that is not inside the other project’s folder tree, so ../ can’t reach it on disk. Also note that .cursorignore hides files from the edit tool and AI features, but it is not a hard security boundary for the terminal. Physical folder separation and the right Run Mode are more reliable.
Send the details above and we can dig deeper. Also, the agent’s self-report like I went out of bounds is not always accurate. The model often agrees with the framing, so we need to confirm the real mechanism behind the change.
Did the change show up as an agent diff card from the edit tool, or did it run a terminal command? You can see this in chat history.
Yes, it showed as changed diff.
What Run Mode are you using? Auto-review, Allowlist, or Run Everything?
Auto-Review
Do you have one parser project open, or both projects as a multi-root workspace via .code-workspace? If the second project is physically inside the workspace root, it counts as inside.
Both projects were open with different users remote ssh access, in different windows. Same server, different working directories. One in home/usera/projecta another in home/userb/projectb
Is the /home/… path in a remote SSH or WSL environment? And can you confirm the actual content changed with git diff in that folder?
Remote local ssh server..
Content when detected had only changed one file so was easy to revert, I stopped the agent straight away to a avoid further damage.
Thanks for stopping the agent and rolling back. That was the right call, and it’s good it only touched one file.
The details make sense, but I want to lock down the exact mechanism so we don’t mix it up with normal behavior. When External-File Protection is enabled, the edit tool’s diff card shouldn’t apply to files outside the workspace root, so one thing really matters here:
Which window did the diff card show up in, the one opened as usera at /home/usera/projecta, or the userb window? In other words, did the agent you asked to edit the parser in projecta apply a change to a file in /home/userb/projectb?
Can you confirm the workspace root of that window (what you see in the title or in the explorer) and the full path of the changed file from the diff card or from the rollback git history?
This separates two scenarios: the edit tool actually writing outside the workspace boundary vs the agent in the second window making a change inside its own project.
If I get an update, I’ll post it here.
For the future, for stricter isolation: keep your windows set up so one workspace root can’t be reached via ../ from the other on disk, and for unfamiliar tasks you can use Plan mode. More on boundary behavior and Run Modes here: https://cursor.com/docs/agent/security/run-modesThanks for stopping the agent and rolling back. That was the right call, and it’s good it only touched one file.
The details make sense, but I want to lock down the exact mechanism so we don’t mix it up with normal behavior. When External-File Protection is enabled, the edit tool’s diff card shouldn’t apply to files outside the workspace root, so one thing really matters here:
Which window did the diff card show up in, the one opened as usera at /home/usera/projecta, or the userb window? In other words, did the agent you asked to edit the parser in projecta apply a change to a file in /home/userb/projectb?
Can you confirm the workspace root of that window (what you see in the title or in the explorer) and the full path of the changed file from the diff card or from the rollback git history?
This separates two scenarios: the edit tool actually writing outside the workspace boundary vs the agent in the second window making a change inside its own project.
If I get an update, I’ll post it here.
For the future, for stricter isolation: keep your windows set up so one workspace root can’t be reached via ../ from the other on disk, and for unfamiliar tasks you can use Plan mode. More on boundary behavior and Run Modes here: Run Modes | Cursor Docs
I cqn confirm that the diff showed on project A where we were correcting bugs. That the file changed was on project b.
So to be clear: the agent in projecta touched and executed changes on project b because the solution he was implemented required changes in projectb. So he jumped outside the boundary and changed files in project b. A boundary that he should not have jumped.
But this has a more complex underline issue he used knowledge from other projects to create a solution to a bug. There should have been total code isolation and he should not have even had access to the other agent/workspace code in the first place.
Thanks for confirming the details, that’s exactly what we needed to untangle.
Let’s split this into two separate issues, since they’re about different mechanisms.
Editing a file in projectb (writes outside the workspace).
This is the key point. With External-File Protection enabled, the edit tool shouldn’t apply a change to a file outside the current window’s workspace root without explicit approval, and this does not depend on Run Mode. What you’re describing, a diff card shown in the projecta window, but the file changed in projectb, is not the expected behavior, and it’s not caused by your settings. I’ve shared this with the team and we’re tracking it. I can’t promise a timeline yet, but I’ll post here if there’s an update.
To fully confirm what happened, could you share two details:
the exact workspace root of the window where the diff showed up, from the title bar or explorer
the full path of the changed file from the git rollback history
This will let us clearly separate edit tool actually writing across the boundary from a case where the agent made the change in the second window.
The agent knew code from another project.
This is different, and it’s by design. External-File Protection only limits writes (create, modify, delete) outside the workspace, not reads. The model can read files outside the workspace root if it thinks it helps with context, especially if the path is reachable via ../ on the same server. So this setting alone won’t give you full code isolation.
If you need strict isolation between projects:
set your workspace root so the other project can’t be reached via ../ on disk, ideally separate machines or containers, not neighboring folders on the same server
for sensitive paths, use Global ignore files in settings, they apply to all projects: Ignore File | Cursor Docs
for unfamiliar tasks, you can run them in Plan mode
Thanks, that was exactly the missing detail. The workspace roots and the full path of the changed file make it clear.
Summary on the two points:
Edit in projectB writing outside the workspace. The diff card showed up in the projectA window, but the changed file /home/userb/projectb/shared/database/dbapi/ui/markdown.ts is outside that window’s root. With External-File Protection enabled, the edit tool shouldn’t apply changes outside the workspace root without explicit approval, and this doesn’t depend on Run Mode. This shouldn’t happen, and it’s not caused by your settings. I’ve passed this to the team and we’re tracking it. I can’t share a timeline yet. If there’s an update, I’ll reply here.
The agent knew code from projectB. That’s a separate mechanism and it’s by design. External-File Protection only limits writes create, modify, delete outside the workspace, it doesn’t block reads. The model can read files outside the root if it thinks they’re useful for context, especially when the path is reachable via ../ on the same server. So this setting alone doesn’t fully isolate code.
For strict isolation going forward:
Set up workspace roots so a neighboring project can’t be reached via ../ on disk. Ideally use separate machines or containers, not sibling folders on the same server.
