Cursor Auto-review Run Mode Guide

The table follows one call through run mode. A known-safe call runs at once, a call that can be sandboxed runs in the sandbox, and only the rest reach the classifier subagent.

Cursor's release notes and announcements say what changed. They don't say how a team should act on it. The steps below are our suggested order, and the next section lists what to watch out for along the way.

1. 1Start from the task's risk, not from the wish for fewer prompts.
2. 2Allowlist read-only or low-risk commands that are easy to audit.
3. 3Keep destructive, external or production-impacting actions behind approval.
4. 4Check whether auto-review changed the agent's behavior before you scale it.

Each item below is either a fact about the release, such as its beta status or plan access, or our advice for using it safely. Plan around each one, and recheck the facts when Cursor ships an update.

• Don't treat natural-language instructions as a hard security boundary. They steer the classifier, but they don't block a call on their own.
• Pair run mode with hooks, sandboxing and repo policy for high-risk actions.
• Log allowed and blocked cases, and use the log to improve the policy over time.

One security engineer uses a simple default: reads run freely, and anything that changes state or touches the network asks first. Reading files is fine in almost every case. Anything that changes state or needs network access asks for approval every time, because his own user account has more access to the systems behind it than he is comfortable handing to the agent.

Writes outside the workspace barely worry him, because he runs agents inside git workspaces: if the agent changes something, he resets it. He is open that this is personal. "I honestly don't care if it runs rm -rf on my hard drive," he says, because it isn't on his list of top 50 concerns. A crypto developer with keys on local disk would draw the line somewhere else entirely.

Auto-review is the default in Cursor 3An older release label for Cursor's multi-agent interface; current product guidance calls the active surface the Agents Window. Press Enter for the full definition..6 and later, and for most local work it is the right choice. The other two modes sit on either side of it.

Allowlist runs only the calls you have listed without asking. Run Everything runs every call automatically, with no sandbox and no classifier. Auto-review takes the middle ground: it runs allowlisted calls, sandboxes shell commands where Cursor can, and sends the rest to an LLM classifier that returns allow or block.

Judge Run Everything by the environment, because nothing else holds the line. Cursor agents run locally with your user account's permissions, so they can read, write, execute and reach the network just as you can. Without a review step, a destructive command runs before you see it. That is true whether it came from the model's own reasoning or from an instruction hidden in a file it read.

So Run Everything belongs only where something outside the agent contains the damage. A cloud agent is the clearest case: Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. run in their own dedicated machine and don't use run modes at all.

On a laptop, containment comes from the sandbox, which only Auto-review and Allowlist with sandboxing on use. A sandboxed command can work in your project, but it can't write outside approved paths or reach the network unless you allow it. Cursor also write-protects paths such as .git/config and .git/hooks. Team settings take precedence over individual and project configuration, so a developer can't switch a team's sandbox policy off to move faster.

Allowlist is the mode we expect teams to underuse. It suits a repo where the useful commands are few and dull, and unlike Auto-review it is legible: you can read the list, and so can an auditor.

No, and Cursor's docs say so directly: Auto-review is not a security boundary, and the allowlist is best-effort, since a determined agent or a prompt injection might get past it. The classifier can make mistakes: it can allow a call you would have blocked, or block one you would have allowed. It is a model making a judgment call, so the instructions you give it change the odds rather than the outcome. That is the point of the guardrail about natural-language instructions.

A hook is the part that holds. It fires at a fixed point in the agent loop, and beforeShellExecution is the one that matters here: your script runs before the command and returns a permission decision. Given the same input, it returns the same answer every time, and it is code you write, own and check into the repo. Set failClosed: true on the hooks that guard risky commands, because by default a hook that crashes or times out lets the action through.

Run mode and hooks do different jobs, and the release note doesn't separate them. Run mode exists to cut how often the agent stops to ask you something. Hooks exist to make certain actions impossible. Raising the run mode doesn't replace writing the hook, and the hook is the piece that still holds when a developer is in a hurry.

Teams get one more advantage. Cursor runs every matching hook and lets a deny from any source win, so a hook deployed through MDM at the enterprise level can't be weakened by editing a file on one laptop. On Enterprise, admins can also set run-mode policies in the team dashboard, but each member still chooses among the modes left open. Put the rule you can't afford to lose in a hook.

Mine it in two directions. The commands you approved twenty times this week are allowlist candidates, and promoting them is where most of this feature's value is. The approvals that surprised you are hook candidates, because a surprise means your model of what the agent needs was wrong.

So don't write the allowlist first, from imagination. A list built that way tends to permit commands nobody runs and miss the test command the repo runs forty times a day. Then people decide the feature doesn't help. A week of real approvals is a better starting point than an afternoon of guessing.

Working solo, you are the log, and the whole exercise takes a couple of settings and some attention.

On a platform team, the same list becomes a policy artifact. It needs an owner, a review date and a home in the repo instead of in each person's settings. The high-risk part shouldn't live in run mode at all. Put destructive and production-touching actions behind a hook, with the terminal sandbox and VM isolation underneath, and write each layer on the assumption that the one above it failed.