What Is Cursor 3.6 Auto-review? (June 2026)

Cursor 3.6 shipped Auto-review on May 29, 2026. Quote from Cursor’s changelog: “Auto-review is a new run mode that allows Cursor to work for longer with fewer approval prompts and safer execution.”

If you’ve ever run Cursor’s agent for more than 20 minutes and clicked “Allow” 80 times, this is the feature for you. Here’s how it actually works.

Last verified: June 1, 2026.

The 30-second version

Cursor 3.6 sorts every Shell, MCP, and Fetch tool call into one of three buckets:

1. Allowlisted — runs immediately (you defined these patterns)
2. Sandboxable — runs inside a sandbox where its blast radius is contained
3. Everything else — sent to a classifier subagent, which decides one of three outcomes:
   • Allow the call
   • Suggest a different approach to the parent agent
   • Escalate to you for manual approval

You configure Auto-review in Settings → Agents → Run Mode, where you can also write custom instructions to steer the classifier.

What problem this solves

Cursor’s agent has been getting better and more autonomous since Cursor 3 (April 2026) and the Agents Window. But long autonomous sessions hit a wall called approval fatigue:

• Every shell call needs a click
• Every MCP tool call needs a click
• Every fetch needs a click

After 50 clicks, you stop reading what you’re approving. That’s worse than no approval — it’s an illusion of oversight.

Auto-review acknowledges this. Instead of asking you to approve 100 obvious shell commands and then bury one dangerous one in the middle, Auto-review:

• Auto-allows the obvious ones (you allowlisted them)
• Sandboxes the riskier-but-still-fine ones
• Funnels the ambiguous ones through a classifier that surfaces just the genuinely surprising calls to you

The three tiers in detail

Tier 1 — Allowlisted

You define these patterns. Typical entries:

• Read-only shell commands: ls, cat, rg, git status, git log, npm test, python -m pytest
• Safe project-internal operations: npm run lint, cargo check, eslint
• Build commands you trust: npm run build (in non-prod environments)

These execute with no prompt, no classifier, no delay.

Tier 2 — Sandboxable

Some calls aren’t on your allowlist but Cursor can run them in a sandbox where they can’t damage your real environment. This is useful for:

• Experimental script execution
• Fetching URLs to inspect responses
• Running ad-hoc analysis tools

The sandbox limits filesystem and network access. The call completes, the agent sees the output, but your local state isn’t affected.

Tier 3 — Classifier-gated

Everything else. Examples:

• A sed -i that rewrites files in-place
• A curl to an unfamiliar URL
• A git push to remote
• An MCP tool the agent hasn’t used before in this session

The classifier subagent sees the call, the surrounding context, your custom instructions, and decides:

• Allow — the call seems consistent with the task and your instructions
• Retry — suggest a safer alternative back to the parent agent
• Escalate — ask you, the human

In practice this means you still see escalations — but only for the genuinely interesting calls, not for the 80% of routine shell.

What Auto-review is NOT

Cursor itself says it loudly in the release notes: “Auto-review is best-effort and not a security guarantee.”

That phrase matters. Here’s what Auto-review does not do:

• It does not validate the code the agent generates. Auto-review gates tool calls. It does not inspect that the file the agent just wrote is safe.
• It does not enforce schema checks. If the agent writes a config file with rm -rf in a postinstall script, Auto-review didn’t see that as a tool call.
• It is not adversarially robust. A sufficiently clever prompt-injection attack can manipulate the classifier subagent itself.
• It is not a container boundary. Unlike OpenAI Codex Cloud’s per-task containers, Auto-review runs on your real machine with your real credentials. A bypassed classifier means a real command on your real filesystem.

For workloads where you cannot tolerate any wrong execution — production deploys, irreversible data operations, anything regulated — keep manual approval on or use container-level isolation.

How to configure it well

The default Auto-review settings are reasonable for most users. To get more out of it:

1. Tighten the allowlist. Add the read-only and lint commands you run constantly. Skip anything destructive. Don’t allowlist rm, git push, npm publish, or anything that touches .env.

2. Write classifier instructions. Examples that work well in practice:

• “Never modify files in node_modules, .git, or dist.”
• “Always escalate before pushing to remote or deploying.”
• “If a shell command writes to /etc, /var, or /home outside the repo, escalate.”
• “Treat any curl to a non-allowlisted domain as escalate.”

3. Combine with Cursor’s existing protections. Auto-review doesn’t replace .cursorignore, project-level git ignore, or your shell’s own safeguards. Layer them.

4. Watch the first 50 sessions. Auto-review is new (released May 29, 2026). Review what the classifier let through versus what it escalated. Adjust instructions accordingly.

How it fits with Cursor’s other recent shipping

May 2026 was a big shipping month for Cursor:

• Cursor 3.5 (May 20, 2026) added Automations and shared canvases plus /loop skill
• Cursor 3.6 (May 29, 2026) added Auto-review
• Bugbot usage-based billing announced for Teams and Individual plans, with the change taking effect at the next renewal after June 8, 2026

Auto-review is best paired with Automations: schedule a Cursor automation overnight, give it Auto-review with a tight allowlist, and let it grind through long-running tasks while you sleep. Without Auto-review, you’d be clicking approvals all night.

When to use Auto-review

Good fit:

• Long refactors across many files
• Test suite generation and execution
• Code review and PR drafting via Bugbot
• Exploration of a new codebase
• Local development where you want fewer interruptions

Bad fit:

• Production database operations
• Code on a shared workstation with elevated credentials
• Anything where a single wrong command costs real money
• Regulated environments that require traceable per-call approvals

Sources

• Cursor changelog: 3.6 Auto-review (May 29, 2026) — official release notes
• Cursor changelog: Auto-review detail — tier definitions
• Releasebot: Cursor release notes May 2026 — full May 2026 changelog summary

Bottom line

Cursor 3.6 Auto-review is the right idea: most approval prompts are boring, automate them; the interesting ones deserve attention, surface them. It’s not a security guarantee, and Cursor is honest about that. Use it on long autonomous sessions where the alternative is approval fatigue. Don’t use it on production-critical work.