Cursor YOLO Mode

Quick answer

YOLO mode is a toggle in Cursor Composer that auto-accepts every shell command the agent wants to run. No approve/reject click, no review step. It saves time on scaffolding, installs, and test runs. It also creates real risk when the agent decides to drop a table or rm a directory. Turn it on for throwaway work in a clean git tree. Turn it off for anything touching production or unreviewed infrastructure. Add a Cursor rule that forbids destructive shell commands as a belt-and-braces guard.

What YOLO mode actually changes

Composer's default behaviour is to pause before every terminal command. You see the command, a short explanation, and two buttons: accept or reject. That loop is safe but slow. On a project scaffolding run you might click accept 40 times in 20 minutes.

YOLO mode removes that pause. When it is on, Composer still shows the command in the chat log, but it runs immediately. You can still cancel mid-run with the stop button, but by the time you notice a bad command it may already be done.

One nuance that catches new users: YOLO mode only auto-accepts shell commands. File edits still produce a diff view that you review before applying. The agent can still write to disk without asking if you have also enabled auto-accept for edits, but those are two separate toggles.

How to enable it

Open Settings with Cmd+, on macOS or Ctrl+, on Windows. Go to Features, scroll to the Composer section, and flip Enable YOLO mode. The change applies to new Composer sessions.

You can also toggle YOLO per-session from the Composer panel. Click the gear icon at the top of the chat, then check Auto-run commands. This is the safer default: opt in only when you know this session is doing low-risk work.

Why the feature exists

Agents work best in tight feedback loops. When you interrupt every shell call for a human to click approve, the agent slows down to human speed even for trivial work. On a two-minute npm install the approval tax is tolerable. On a 30-step scaffolding run it breaks the flow.

The thinking behind YOLO mode: the agent was going to run that command anyway, and 90% of the time the command is fine. Removing the click lets the agent finish the task at machine speed. The 10% of times the command is not fine is why the feature is off by default.

The real risks

A Composer session with YOLO mode on and a bad prompt can cause genuine damage. The five categories worth calling out:

1. File deletion: rm -rf node_modules/../.. by way of a broken path variable.
2. Git history rewrites: git reset --hard HEAD~10 because the agent decided to "clean up".
3. Package mayhem: npm install into the wrong workspace, polluting lockfiles.
4. Database writes: psql -c "DROP TABLE users" if the agent has a shell with DB credentials.
5. Network calls: running a deploy script that pushes half-finished code to production.

None of these are hypothetical. They have all happened to someone on a public issue tracker in the last year.

Safety guards to put in place first

Before flipping the toggle, set up the room. Four guards that cost nothing and prevent the worst outcomes:

• Clean git tree: commit or stash everything before the session. If YOLO mode does damage, git reset --hard and git clean -fd get you back.
• Scoped credentials: do not keep production DB passwords in the shell environment of the IDE. Use a separate terminal for anything privileged.
• Working test suite: a fast test command that runs in under a minute. If the agent breaks the build, you find out inside the session instead of the next day.
• Cursor rule against rm: add a project rule that says never run rm, rmdir, or git push --force. The rule will not always be respected, but it cuts the probability.

A sample rule you can drop into .cursor/rules/safety.mdc:

---
description: Hard limits on destructive shell commands
alwaysApply: true
---

Never run these commands:
- rm -rf with any path variable
- git push --force or git push -f
- git reset --hard without an explicit ref
- DROP TABLE, DROP DATABASE, or TRUNCATE
- any command that touches /etc or system files

If a task seems to require one of these, stop and ask the user first.

Where YOLO mode saves real time

The use cases where the speedup is worth the risk:

• Project scaffolding: npx create-next-app, package installs, running the dev server, setting up a Tailwind config. Ten small commands that would each get the approve-reject pause.
• Dependency updates: bumping a major version of a library and letting the agent run npm install, run tests, fix breakage, run tests again.
• Test loops: generate code, run tests, read failures, regenerate. Each iteration takes three commands; the approval tax triples the run time.
• Data exploration: the agent running wc -l, head, grep, and other read-only shell commands against local files.

All four share a pattern: the commands are cheap, reversible, and low-blast-radius.

Where YOLO mode is genuinely dangerous

The opposite cases, where you should keep the approval pause:

• Production database access: even a read query can lock a hot table. Write queries can corrupt data.
• Infrastructure scripts: Terraform apply, Pulumi up, Helm upgrade. A wrong plan destroys cloud resources.
• Deploy commands: any deploy or release target in your Makefile or package.json.
• Remote git operations: push, force push, rebase. Especially against shared branches.
• Anything that calls a paid API: the agent spinning up a Fargate task for an experiment that then runs for three days.

Rule of thumb: if the worst case is "restore from a backup" or "apologize to the team", keep the pause on.

Recovering from YOLO mode mistakes

When things go wrong the recovery depends on what was touched.

For file damage in the workspace: git status to see the blast radius, then git reset --hard HEAD and git clean -fd to restore. If the agent also modified untracked files you wanted to keep, git stash them before the reset.

For git history rewrites: use git reflog to find the commit hash before the rewrite. Then git reset --hard to roll back. Reflog entries persist for 30 days by default.

For node_modules mayhem: delete the folder and the lockfile, then reinstall from scratch. Slower but clean.

For database writes: depends on your backups. Point-in-time recovery on Postgres, Supabase, or Planetscale can rewind to a specific moment. Set this up before you need it, not after.

For deploys: roll back through whatever your deploy tool supports. Vercel keeps every deploy and offers a one-click rollback. Railway and Fly are similar.

Comparing to Claude Code auto-accept

Claude Code has a similar feature, often called auto-edit mode or bypass permissions. Same idea, different surface. Claude Code's auto-accept covers both file edits and bash tool calls, configurable via a CLI flag or the settings file.

The main practical difference: Claude Code's permission model is more granular by default. You can allow npm test globally while still requiring confirmation for npm install. Cursor's YOLO mode is a single toggle; no allow-list for specific commands.

If granular control matters, Claude Code wins. If you want one switch you can flip and forget, Cursor is simpler. Teams often use both: Cursor for in-editor work, Claude Code for longer agent runs where they want tighter command filtering.

Team policy recommendations

For a team rolling out Cursor, three policies keep YOLO mode from becoming an incident driver:

• Default off in Business plan settings: admins can lock the setting to require per-session opt-in.
• Commit a safety rule to .cursor/rules/: every engineer gets the same destructive-command guard on their next pull.
• Require YOLO off for any session that touches a production-scoped token: enforced socially, not technically, but a clear rule helps.

The goal is not to ban the feature. It is a real productivity win on the right tasks. The goal is to match the toggle to the blast radius of the work.

A short pre-flight checklist

Before you flip YOLO mode on for a session, run through this list:

1. Is the git tree clean or committed? If no, stop.
2. Does this session touch production? If yes, leave YOLO off.
3. Is there a safety rule loaded in the project? If no, add one.
4. Is the task reversible with a git reset? If yes, proceed.
5. Do I have a terminal open to roll back if needed? If no, open one.

30 seconds of checklist prevents most recoverable mistakes.