To me the sandbox never works properly, it confuses the model with failures, always results to explicit approval request. I have been using the Allowlist (without sandbox) mode for long because I simply don’t understand the value of sandbox.
It’s either completely impractical feature which is only good in theory, or I’m just failing to understand it.
If you belive that sandbox is something that has its purpose, then please make a deep, 1-2 hour long, very technical training session on YouTube on how it works, how it meant to be used properly, how it overlaps with other permission models, how does it superseed them, when it useful it and when not in an engineering workflow, how to confugure and debug it etc.
Thanks for the feedback. The Sandbox should overall not be too complicated (docs) – restrict access to read-only unless working in the workspace, restrict network access, allow writing to /tmp/.
Of course the devil is in the details. If you have some specific failure cases it would be great to learn about them!
FYI we also introduced Auto-review Run Mode last week which should drastically reduce how often users are asked for permissions to run something outside the sandbox. Worth a try!
Sandbox isn’t complicated; it just doesn’t have a clear value proposition to justify its existence.
You don’t need a Terminal environment (isolated or not) to read/write file contents; this is being done by tool calling.
The terminal goes into place when there’s a need to call various tools like AWS CLI etc., invoke integration tests and do other stuff… and sandbox is just a useless obstacle for this.
So, so maybe it has some novel and sophisticated practical usage scenario which isn’t clear at first glance — then please do a deep dive on it, now to use it properly and productively.
I think the one-line value prop of sandbox is: Sandbox limits what the agent’s shell commands can physically do on your machine, even when the model makes a mistake.
You’re right that ideally, the agent uses tool calls for file operations and only drops into the terminal when it needs broader access. But in practice, the model doesn’t always make that distinction cleanly!
The agent regularly uses shell commands to read/write files (cat , sed , echo > file ), install things, run scripts, and chain operations. When it does, those commands can touch anything on your machine. Sandbox ensures that even when the model takes an unexpected path, the blast radius is limited to your workspace unless you explicitly approve!
It also prevents data exfiltration, though you can open up network access for trusted domains if needed (sandbox.json Reference | Cursor Docs). It’s very configurable.