Cursor Auto-review Run Mode Guide

Cursor's Auto-review Run Mode lets agents work longer with fewer prompts by allowing safe shell, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. and fetch calls, sandboxing calls when possible and sending other actions to a classifier subagent.

Knowing what shipped is the easy part. Turning Cursor Auto-review Run Mode into something a team relies on takes a few deliberate steps, mapped below.

1. 1Start with the task risk, not with the desire to reduce 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. 4Review whether auto-review changed the agent's actual behavior before scaling it.

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

A useful default from one security engineer: let reads run free, gate anything that mutates state or touches the network. Reading files is fine almost full-stop. Anything that changes state or needs network access should ask for approval every single time - because his own user has more permissions to the systems behind it than he's comfortable handing the agent.

Writing outside the workspace barely registers as a worry when you run agents inside git workspaces - if the agent changes something, you reset it. The same engineer is candid that this is personal: "I honestly don't care if it runs rm -rf on my hard drive," because it isn't on his top-50 list of concerns. A local crypto developer with keys on disk would draw the line somewhere completely different.

Auto-review is the default in Cursor 3Cursor's agent-forward interface (also called the agent window or Glass), built to run and supervise many agents at once rather than edit one file. Press Enter for the full definition..6 and later, and for most local work it is also the right answer. The other two sit either side of it.

Allowlist keeps automatic execution to the calls you have listed. Run Everything drops the review step. Auto-review takes the middle ground, running allowlisted calls, sandboxing shell commands where Cursor can sandbox them and sending the remainder to an LLM classifier that returns allow or block.

The reason to think about Run Everything in terms of the environment rather than the task is that nothing else is holding the line. Cursor agents run locally with your user account's permissions, so they can read, write, execute and reach the network exactly as you can. Take away the review step and a destructive command runs before you see it, whether it came from the model's own reasoning or from an instruction that arrived inside a file it read.

So Run Everything belongs where something else contains the damage. Sandbox ModeAn isolated agent execution mode that contains the blast radius: file access scoped to the workspace, network off by default and git restricted to read-only, enforceable org-wide. Press Enter for the full definition. scopes file access to the workspace, keeps network access off unless you allow it and holds git read-only, which blocks a force-push that would rewrite shared history. A cloud agent in its own VM gets you the same thing by different means. And Sandbox Mode is not something a developer opts out of when it slows them down, since it is set as an org-level policy an individual cannot switch off.

Allowlist mode is the one I would expect teams to under-use. It suits a repo where the useful commands are few and dull, and unlike Auto-review it is legible. You can read it, and so can an auditor.

No, and the docs are direct about it. The run-mode allowlist is best-effort, a determined agent or a prompt injection may get past it, and Cursor's guidance is to pair it with hooks. The classifier is a model making a judgment call, so the instructions you give it change the odds rather than the outcome. That is what the guardrail about natural-language instructions is pointing at.

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 first, synchronously, and returns allow or deny. Same input, same answer, every time. It is code you write, own and check into the repo, which is what separates a boundary from a strong suggestion.

The division of labour is worth stating plainly, because the release note does not. Run mode exists to cut the number of times the agent stops and asks you something. Hooks exist to make certain things impossible. Turning run mode up is not a substitute for having written the hook, and the second one is the piece that survives a developer being in a hurry.

On a team there is a further wrinkle in your favour. A hook deployed through MDM at enterprise level takes precedence over whatever hook an individual has configured locally, so the policy cannot be quietly weakened by editing a file on one laptop. Run mode is governable as well, through Run Mode policies in the team dashboard on Enterprise, though in 3.6 and later the mode itself is still an end-user choice. Put the rule you cannot afford to lose in the hook.

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

Which is an argument against writing the allowlist first, from imagination. A list built that way tends to permit things nobody ever runs while missing the test command the repo runs forty times a day, and then people conclude the feature does not help. A week of real approvals is a better source document than an afternoon of guessing at one.

Solo, you are the log, and the whole exercise is a couple of settings and some attention. Nothing here needs a document.

On a platform team the same list becomes a policy artifact, so it needs an owner, a review date and a home in the repo rather than in each person's settings. The high-risk half of it should not live in run mode at all. Destructive and production-touching actions belong behind a hook, with the terminal sandbox and VM isolation underneath, each layer written on the assumption that the one above it failed.