Cursor 3.6 auto-review and rules

Cursor 3.6 auto-review is a run mode in Cursor, Anysphere's AI code editor, that lets the agent work longer with fewer approval prompts. Auto-review is a way of sorting every action into one of three lanes: allowlisted Shell, MCP, and Fetch calls run right away, calls that can be sandboxed run in the sandbox, and everything else goes to a classifier subagent that decides what to do. Most teams do not get stuck because they are missing a feature. They get stuck when the agent moves faster than the review path, and nobody wants to own the mess in a shared repo. This piece is about closing that gap without handing the agent a blank check.

Sort actions into three lanes

Auto-review Run Mode landed in the May 29 changelog. The idea is simple once you see the three lanes.

The first lane is safe by rule: allowlisted Shell, MCP, and Fetch calls just run. The second is safe by sandbox: anything that can be isolated runs in the sandbox, so a mistake stays contained. The third lane is everything else, which goes to a classifier subagent. That subagent decides whether to allow the call, try another approach, or stop and ask you.

The result is fewer false stops and less clicking through prompts. You still own the boundary. The mode only changes how often a human gets pulled in, not who is responsible for the outcome. Start by asking what should never need a prompt, then let the rest find its lane.

Write rules the agent meets first

Rules are the cheapest place to make agent work safer, because they shape the run before it starts. A rule file is a set of instructions Cursor attaches to a job based on which files are in scope. Treat it as policy, not as sticky notes.

The trap most teams hit is one giant rules file that grows until nobody knows which line still applies. Split it. Move to .cursor/rules/*.mdc files with narrow scope and a one-sentence description each. If you cannot explain a rule in one sentence, it is two rules.

Here is a small starter you can paste and trim to your repo.

---
description: "Team rule for safe Cursor review and scoped edits"
globs:
  - "src/**"
  - "tests/**"
apply: always
---

- Prefer small diffs over broad refactors.
- Use shell only for commands that are safe to repeat.
- Ask before any write outside the current repo.
- If an MCP connector is needed, explain why and name the data scope.
- When delegating to a subagent, return a short receipt: files changed, risk, and open questions.
- Before finishing, run the repo's tests or explain why they were skipped.

Smaller rules are easier to review, easier to attach to the right files, and easier to delete when they drift. That last part matters more than it sounds. A rule you are afraid to delete is a rule you stopped trusting.

Ask subagents for a receipt

Subagents are fast because they work in isolated context. That same isolation hides assumptions, so a subagent can be right about its slice and wrong about the repo. You ask for a review, the summary comes back clean, and the real problem is still sitting there.

Fix it with a receipt. Have the subagent return a short summary of the files it touched, the risk it saw, and the exact reason it asked for approval. The reviewer gets a smaller surface to inspect, and the parent agent gets a stable handoff format. No receipt, no trust.

Keep connectors and policy out of the fast lane

MCP connectors expose tools and data, so scope and consent are the whole game. Cursor's MCP docs and the protocol spec both draw the trust boundary in the same place: a connector can act on your behalf, so it needs a reason to exist and a named owner. Review each server for the minimum data and action scope it needs, then keep that scope visible in your team rule file or AGENTS.md.

Auto-review is for pace, not policy. A classifier subagent can still miss context, and the sandbox does not make a bad task into a good one. Keep the actual policy in rules, AGENTS.md, and a review checklist where a human can read it. In the Review step, the question that earns its keep is not whether the agent finished. It is whether another engineer can trust the path it took.

Common questions

• What is Cursor 3.6 auto-review?

  Cursor 3.6 auto-review is Auto-review Run Mode, the key change in the May 29 changelog. The agent works longer with fewer approval prompts because every action takes one of three lanes: safe by rule, safe by sandbox, or reviewed by a classifier subagent that allows the call, retries, or asks for your approval.

• How do you turn on auto-review safely for a team?

  Set the run mode in Settings, then pair it with a small rule file that names the work that belongs in the fast lane. Do not begin by letting the agent do more. Begin with the opposite question: what should never run without a prompt? Your answer to that becomes the first few lines of the rule file.

• Does auto-review replace human code review?

  No. Auto-review changes the pace of work, not the policy behind it. A classifier subagent can still miss context, and sandboxing does not turn a bad task into a safe one, so the real checks stay in rules, AGENTS.md, and a review checklist. Use it to spend fewer prompts, not fewer judgments.

• How should cursor rules be structured for auto-review?

  Move from one broad file to .cursor/rules/*.mdc files with narrow scope and a clear description each. Smaller rules are easier to review, easier to attach to the right files, and easier to delete once they drift out of date. A good test: if a rule cannot be explained in a single sentence, split it into two.

• What is a delegation receipt for Cursor subagents?

  A delegation receipt is a short summary the subagent returns: the files it touched, the risk it saw, and the exact reason it stopped to ask for approval. It gives reviewers a small surface to check and gives the parent agent a predictable handoff. The rule behind it is blunt: no receipt, no trust.

Where to start this week

If your team is standardizing Cursor work, ship one scoped rule file and one review checklist, then move the rest of the repo toward the same boundary. The subagents and skills topic page has more on building those handoffs.

Further reading

• Cursor: Agent
• Cursor: Rules
• Cursor: Skills
• Cursor: MCP
• Cursor: Enterprise
• Cursor: Changelog
• Model Context Protocol: specification