In that thread I reported that the agent left the open workspace folder. Staff replied that a chat instruction is not enough, that the default Read Access is System, and that the fix is to set Read Access to Workspace and run commands in the sandbox. The thread was then closed.
That fix does not hold. I kept the workspace on a nested project folder. The agent asked to turn the sandbox off and then wrote outside that folder, under my home directory. I am indignant. I do not understand how holes this obvious are still there.
Setting Read Access to Workspace does not cover Run Everything. Allowlisted commands run outside the sandbox. And the agent can request an unsandboxed command itself. If that request is granted, the workspace limit is gone. A boundary the agent can ask to remove is not a boundary.
Steps to Reproduce
Steps to Reproduce
Open Cursor on a nested project folder. In this case the workspace was PANEL-SNIFFER/mechanic, not the home directory.
Apply the settings from the previous thread: Read Access set to Workspace, and a Run Mode that uses the sandbox.
In Agent chat, ask for a task inside that folder. Here it was to update conjunto.html from PANEL-SNIFFER.step.
The agent requests a shell command with the sandbox disabled.
When that request is granted, the command runs as the user and can write anywhere that user can write.
Result: the agent created /home/gschelotto/.cache/ocp-venv and installed packages there, outside the open workspace.
Expected Behavior
With the workspace limited to the open folder, a command must not write or install anything outside that folder. Asking to disable the sandbox is not a way out. The agent should stay inside the folder, or stop and say it cannot leave, instead of creating files in the home directory.
Hi @gschelotto, what let this through is the Run Mode rather than Read Access.
In Auto-Review (with Sandbox), when the agent asks to run a command outside the sandbox you don’t get a prompt: an automatic review decides, and if it approves, the command runs completely outside the sandbox. Read Access = Workspace only applies to commands that stay inside the sandbox, and allowlisted commands always run outside it.
If you want leaving the folder to always need your click:
Open Cursor Settings → Agents → Execution and Approvals.
Set Run Mode to Allowlist (with Sandbox).
Remove every entry from the command allowlist.
Keep Read Access on Workspace.
Commands then run inside the sandbox without asking, and any request to run outside it shows you an approval card you can decline. There’s no setting yet that stops the agent from asking at all, and I’ll pass your point along to the team: a Workspace boundary shouldn’t be something an automatic approval can lift.
The problem is still there. I do not want another explanation of modes and settings.
I set a restriction: the agent stays inside the open workspace. That restriction has already been broken twice, each time by a different path. First by the default Read Access. Then by Auto-review approving a command outside the sandbox, which wrote files under my home directory. The setup you just gave me — Allowlist with Sandbox, an empty command allowlist, Read Access set to Workspace — still has a way out. The agent can ask to leave, and approving that request removes the limit. You already said there is no setting that stops the agent from asking.
I have the right to set a restriction and have it hold. A limit the product can get around is not a limit. If my restrictions are broken again and again, each time by a different mechanism, the system is not secure. I do not trust it, and I cannot keep using Cursor unless you change it so the agent cannot leave the workspace at all.
Hi @gschelotto, understood. There’s no setting today that takes the option away from the agent, but you can make it a hard stop yourself with a hook. Cursor runs it before every agent command, and it can refuse the command outright, with no approval card.
Make sure the agent’s auto-run mode is set to run in the sandbox. The hook allows only sandboxed commands, so with the sandbox off it blocks everything.
Save this as ~/.cursor/hooks/stay-in-sandbox.py:
import json, sys
req = json.load(sys.stdin)
if req.get("sandbox"):
print(json.dumps({"permission": "allow"}))
else:
print(json.dumps({
"permission": "deny",
"user_message": "Blocked: this command would run outside the sandbox.",
"agent_message": "Commands outside the sandbox are not allowed. Work inside the open folder, or stop and say you can't."
}))
Add the hook to ~/.cursor/hooks.json. If you don’t have that file yet, create it with this:
If the file already exists, add the { "command": ... } line to its beforeShellExecution list instead of replacing the file.
Cursor picks up the change as soon as you save, so you don’t need to restart. From then on, any command the agent tries to run outside the sandbox is refused, and that includes requests for wider network access. Because of failClosed, if the script can’t run (for example, python3 isn’t installed), commands are blocked rather than allowed.
Thanks for the suggestion. I appreciate the effort, but this is not a complete solution to the problem I’m reporting.
The proposed hook only controls shell command execution through beforeShellExecution. It does not establish an enforceable workspace boundary for all agent operations, including direct file reads and writes or other tools.
My requirement is simple: the agent must not be able to access or modify anything outside the open workspace, regardless of which tool or execution mechanism it uses.
I don’t want to build and maintain custom hooks to compensate for a missing security feature. I want a native, enforceable restriction that the agent cannot override, bypass, or request permission to disable.
Can Cursor provide that guarantee today? If not, please acknowledge that this capability is currently missing.