Permissions, auto-run & the sandbox

Left at its defaults, Cursor works semi-supervised: known-safe commands run right away, sandboxable commands run contained, anything else goes to a quick review that can still stop and ask, and you review the agent’s edits as batches rather than one at a time. That is the right shape while you are feeling a task out. It stops being the right shape when the work turns repetitive - a migration on budgetcli (the course’s illustrative personal-finance API) that re-runs npx vitest run thirty times, a refactor across forty files that wants the build re-checked after every batch. The approvals that do still fire become friction people route around, and the way they route around it is by flipping the agent to run everything unattended. Do that without understanding what is actually containing the agent, and you have quietly handed a model write access to your whole machine.

This chapter is about deciding the agent’s reach on purpose instead of by accident. It separates two decisions that are easy to conflate:

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

One distinction does the most work here, and it is the same line the rules chapter draws from its side (where rules stop being enough): instructions are guidance, permissions and sandboxes are enforcement. A rule tells the model what you want, and it is followed when it is read and remembered - nothing fails when it is missed. A sandbox restriction is imposed by the operating system at execution time; the forbidden action cannot happen however the model was prompted. Within Cursor’s enforcement stack, the ordering matters just as much: the OS-enforced Agent Sandbox - and, beyond it, an isolated remote environment - is the wall, while allow/deny lists are policy and convenience. Get that ordering backwards, trust a deny rule to keep the agent away from something dangerous, and the protection you think you have is not there. Both decisions are control decisions in this course’s sense - control being what guides execution and enforces boundaries - and this chapter is where the enforcement half lives.

Before Cursor’s names for any of this, the judgment itself: how much leash a task earns follows from two properties of the task, not its difficulty. Set them for the migration grind, then for anything that touches a deploy, and watch the recommended rung move:

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 dial’s rung names are generic on purpose; Cursor spells them with its run modes plus one mode from the modes chapter (as of September 2026 - run modes documentation). Read-and-propose is Ask, the read-only mode. Ask-before-acting is a short Allowlist: only listed commands run without approval. The auto-apply-and-gate middle is Auto-review, the default - allowlisted calls run immediately, sandboxable commands run inside the sandbox, and the rest go to a classifier that can still stop and ask. The fence is Allowlist with sandboxing on, where the loop runs unattended and the sandbox does the containing. And run-free-no-fence is Run Everything - the dial is right to confine it to disposable environments.

The chapter, in setup order

• Pick how much runs unattended, and find the wall - the three 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 (agent sessions on a dedicated remote machine) for real isolation, and setting the whole posture by reflex - When you need real isolation

Work through them in order and the payoff is a posture you can hold without thinking about it: the grind runs unattended because it is fenced, and commands that cannot run sandboxed still stop and ask. Start with the auto-run modes.