Permissions, auto-run & the sandbox

The work so far has been supervised by default: you read the agent’s proposed edits, you clicked through its terminal commands one at a time, and nothing ran that you didn’t watch run. That’s fine while you’re feeling a project out. It stops being fine the moment the work gets repetitive - a budgetcli migration that runs the same npx vitest run thirty times, a refactor that touches forty files and wants to re-run the build after each batch. Clicking Run on every command is friction you’ll start routing around, and the way people route around it is by flipping the agent to run everything unattended. Do that without understanding what’s actually containing the agent and you’ve quietly handed a model write access to your whole machine.

This chapter is about setting the blast radius on purpose instead of by accident. There are two things to get straight, and they’re easy to conflate:

• How much the agent runs without asking you - the auto-run mode. Does the agent route each command through review tiers, run them unattended inside a sandbox, or just run everything?
• What a running command can actually reach - the sandbox and environment, with allow/deny rules as policy controls around execution. When a command does run, is it boxed into your project, or is your filesystem and network in scope?

The single most important idea in the chapter is which of these is real. In Cursor, the sandbox or isolated runner is the load-bearing control; allow/deny rules are policy and convenience controls, not a complete boundary. Get that ordering backwards - trust a deny rule to keep the agent away from something dangerous - and the protection you think you have isn’t there.

Before Cursor’s names for any of this, the judgment itself: how much leash a task earns comes down to two properties of the task, not its difficulty. Set them for the budgetcli migration grind, then for anything that touches a deploy, and watch the recommended rung move - the rest of this chapter is Cursor’s hardware for each rung, with the sandbox as the fence that makes the loose end safe:

Two questions decide how much leash a task earns - neither of them is “how hard is it.” Set both for the work in front of you and read the rung it lands on.

If the agent’s worst single action went wrong, undoing it would take…

a git checkoutthe change lives in tracked files; the floor holdsreal worka migrated database, regenerated files, a rebased brancha miraclea send, a deploy, a delete with no backup

…and its consequences would reach

your working copyone repo, one machine, nobody downstreamwhat the team sharesa library others consume, common infra, shared databeyond the machineproduction, customers, money, the public

1. Run free, no fencedisposable environments onlyNothing pauses it and nothing contains it. No combination on this dial lands here - it belongs only where the whole environment is disposable: a throwaway container, an already-isolated CI runner.
2. Run free inside a fencethis taskNo prompts; the boundary does the protecting. The agent grinds end to end inside a sandbox, container, or scratch worktree, and you review the whole batch once at the end.
3. Auto-apply edits, gate the rest
4. Ask before acting
5. Read & propose only

A mechanical rename across your own repo is the canonical case: the worst outcome is a git diff you throw away. Prompting on every one of twenty-four identical edits doesn’t add safety - it teaches you to stop reading prompts, which is where real risk starts. Let it run inside the fence and review the batch once.

The rung names are generic on purpose - every tool spells its own versions of them, and most let you set different rungs for different categories of action. The judgment underneath is the same two questions, asked per task, never answered once for all time.

The four moves

The rest of the chapter is Cursor’s hardware for each rung of that dial, in the order you’d actually set it up:

• Pick how much runs unattended, and find the wall - the auto-run modes, plus the OS-enforced Agent Sandbox that actually holds - Auto-run and the sandbox
• Use the lists in their proper place - allow/deny rules as policy controls, with the sandbox as containment - Allowlist and denylist
• Escalate when the sandbox isn’t enough - Cloud Agents for real isolation, and setting the whole thing by reflex - When you need real isolation

Work through them in order and the payoff is a posture you can hold without thinking: the grind runs unattended because it’s fenced, and the one command that could actually hurt you still stops and asks. Start with the auto-run modes.