Auto-run: how much the agent runs without asking

The auto-run modes

Auto-run is the setting that decides which of the agent’s proposed commands pause for your approval and which just run. Cursor’s current name for the surface is run modes, and there are three: Auto-review, Allowlist, and Run Everything (as of September 2026 - run modes documentation). In the desktop app you set them under Settings > Agents > Approvals & Execution. From the CLI (agent, Cursor’s terminal entrypoint), /run-everything [on|off|status] toggles Run Everything on or off, or reports its state - /auto-run is an alias for the same command (slash-command reference, as of September 2026) - so it is a toggle, not a selector among the three named modes.

Auto-review

The default since Cursor 3.6 (released May 29, 2026), and the most important mode to understand because it is not a single gate - it is a three-tier router. When the agent proposes a terminal command, an MCP tool call, or a web fetch, Auto-review sorts it through the tiers in order:

1. Allowlisted commands run immediately - trusted calls execute with no model in the loop and no prompt. (The docs do not specify whether allowlisted commands still run inside the sandbox when sandboxing is on; if that containment matters to a trusted command, verify the current behavior.) This is your known-safe set (npx vitest run, git status on budgetcli, the course’s illustrative personal-finance API) going straight through.
2. Sandboxable commands run in the sandbox - anything Cursor can safely isolate executes inside the OS-level sandbox automatically, without asking you. The sandbox does the containing; you don’t get a prompt.
3. Everything else goes to a classifier - a small model that reads the proposed call and decides whether to let it through, take a different approach, or stop and ask for your approval.

The classifier is the piece to be precise about: it is not a security boundary. It is a non-deterministic model making a best-effort convenience call to cut approval prompts, and because it can be wrong, you do not lean on it to keep the agent away from something irreversible. The three tiers are real and useful for staying in motion; the wall is still the sandbox (next section), not the classifier’s judgment.

Allowlist

Commands matching your allowlist run without prompting; anything not on the list stops for approval. This is the classic “let it run npx vitest run and git status freely, but pause on everything else” posture - useful for cutting friction on a known-safe set of commands while keeping a checkpoint in front of the rest.

Sandboxing is not a separate mode - it is a layer inside Allowlist. “Run in Sandbox” was historically its own option; since Cursor 3.5 it has been folded into Allowlist, so you turn sandboxing on or off as a part of this one mode rather than picking a different mode for it. With sandboxing enabled, the agent gets to grind through its loop - run tests, re-run the build, retry after a failure - without stopping at every step, because supported shell commands run inside an OS-level sandbox instead of waiting on the allowlist. A command that tries to write outside the sandboxed area, or reach the network, doesn’t get to. This is the setting the rest of the chapter is really about, because it is where the sandbox is doing the protecting and you need to understand exactly what the sandbox does and doesn’t cover.

One thing to be precise about: with sandboxing on, the allowlist stops being the thing that’s gating reach. The sandbox is meant to replace per-command approval with filesystem and network restrictions for whatever it can isolate. So when a command genuinely needs what the sandbox blocks - outbound network, or filesystem access outside the sandboxed area - it doesn’t silently fail into the void, and it doesn’t fall through to allowlist evaluation. The documented behavior is that some commands need full system access and bypass the sandbox, and “Cursor will indicate when a command runs outside the sandbox and ask for your approval” (run modes documentation). The fall-through is to a prompt, not to a list - and under Auto-review it is the classifier of tier three that fields the non-sandboxable call first.

Run Everything

No gating. Every command runs, no sandbox, no prompt - the posture the community calls YOLO mode, after the CLI’s --force flag whose alias is --yolo. There are legitimate places for it: a throwaway container, a CI runner that’s already isolated, a VM you’ve deliberately made disposable. On your actual development machine, with your real repos and credentials in reach, it’s almost always the wrong answer. The reason you’d reach for an AI agent on serious work is that the stakes are real, and this is precisely the setting that throws away every protection those stakes call for. When you feel the pull toward it, the right move is usually to switch to Allowlist with sandboxing on instead - you get the unattended loop without removing the wall.

Try it

Open Settings > Agents > Approvals & Execution and add one command to the allowlist (e.g. npx vitest). Run a task that triggers it and watch it execute without a prompt. Then remove it and notice the prompt return.

Every one of those three modes decides only which commands pause for you. None of them decides what a command can reach once it’s running - and on this chapter’s central point, that second question is the one that actually protects you.

The sandbox

Cursor’s Agent Sandbox is the control that actually holds. Sandboxed terminals launched in beta in Cursor 1.7 and went GA in 2.0 - for macOS; the changelog is explicit that “sandboxed terminals are now GA for macOS” (2.0 changelog). It is enforced by the operating system, not by the model’s judgment or by a pattern match against a command string - so a write outside the sandboxed area, or an outbound network call, fails, regardless of how the command was spelled or whether the agent “meant” to escape. Inside the fence, in Cursor’s own phrasing, agents “run freely inside a controlled environment and only request approval when they need to step outside it” - most often to reach the internet (sandboxing blog).

You enable it where you set the run modes: Settings > Agents > Approvals & Execution, with sandboxing enabled on the mode. Once it’s on, commands the agent runs are isolated by default - you don’t configure per-command sandbox rules, you flip it on and the OS enforces the boundary.

Which platforms the sandbox actually covers is worth stating exactly, because tutorials repeat an optimistic version (as of September 2026 - run modes documentation):

• macOS - supported directly. Cursor uses Seatbelt, accessed via sandbox-exec.
• Linux - supported with prerequisites. Cursor uses Landlock for filesystem restrictions and seccomp to block unsafe syscalls, and it requires kernel 6.2 or later with Landlock v3 support and unprivileged user namespaces enabled. Where those prerequisites aren’t met, the sandbox can’t enforce its restrictions, and Cursor falls back to asking for approval before running commands - you get prompted rather than silently unprotected.
• Windows - not documented. The current run-modes page says nothing about Windows support either way; a February 2026 blog post described running the Linux sandbox inside WSL2 while a native Windows sandbox was still under development (sandboxing blog). Until the docs list Windows, treat the sandbox as unavailable there and put your wall somewhere else - a container, a VM, or a Cloud Agent (a Cursor agent on managed cloud infrastructure).

What the wall buys, in Cursor’s own measurement: “Sandboxed agents stop 40% less often than unsandboxed ones,” saving the manual approvals that sandboxing replaces (sandboxing blog, February 2026). Enforcing a boundary and staying in motion are not in tension here - used where it applies, the sandbox reduces interruptions rather than adding them.

Hold the distinction - the course’s control principle, what enforces a boundary versus what merely guides execution - the same way you would a wall versus a checkpoint. The sandbox is a property of the environment: set it and a forbidden write is impossible, not disallowed-but-overridable. The auto-run mode is a property of the workflow: it decides which possible actions pause for you. You combine them - the sandbox says where a command can reach at all, the mode says which commands you watch run.

With the wall established, the two features that look like walls are worth putting in their place - because the allowlist and the denylist are the ones people reach for first, and they carry far less weight than their names suggest. Next: why the lists are friction controls, not the boundary.