Where did YOLO mode go?

It was renamed **Auto-Run**, and in Cursor 3.6 the behavior is selected from the **Run Mode** dropdown (Settings → Agents). Choose **Ask** to require a prompt every time.

Why does a fresh install run commands on its own?

Auto-review is the default Run Mode for new users as of Cursor 3.6 (May 29, 2026). Switch to **Ask** if you want approval prompts.

The in-app allowlist won't let me edit it. Why?

A `permissions.json` (`~/.cursor/` or the repo's `.cursor/`) is defining that list, which makes the in-app editor read-only. Edit the JSON instead.

Can I allowlist just safe commands?

Yes. Use exact strings like `npm test` or `pnpm build` in `terminalAllowlist`, never bare prefixes or wildcards (matching is prefix-based).

Does the gate also cover file edits?

No. File edits go through the diff review flow. Run Mode and the allowlist gate shell, MCP, and Fetch tool calls.

Why did Agent push to main without asking?

Either `git` was an allowlist prefix (which also matches `git push`), Run Mode was Auto-review/Run Everything, or you approved a multi-step plan that included the push.

Is there a panic-stop?

Click the stop button on the running task, or Cmd/Ctrl+Shift+P → "Cursor: Stop Agent." For a runaway process, kill the integrated terminal.

Troubleshooting

Cursor Runs Shell Commands Without Asking (YOLO / Auto-Run)

Cursor Agent runs terminal commands with no confirmation even after you turned auto-run off. As of June 2026 it's almost always Run Mode, a wide allowlist, or a workspace permissions.json. Fix it in a minute.

Published: May 24, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You turned off auto-run (or never turned it on), opened Agent, asked Cursor to do something innocent, and the next thing you see is rm -rf node_modules running in the integrated terminal with no confirmation popup. Or a long pip install. Or a git push. You expected a prompt and got none.

Fastest fix: set the Run Mode to Ask so every shell call needs your approval. Go to Settings → Cursor Settings → Agents → Run Mode and choose Ask, then empty your command allowlist. That covers the common case in under a minute. The rest of this page is for when that alone does not stick.

One naming note up front, because it trips people up: the old YOLO mode toggle was renamed to Auto-Run, and as of Cursor 3.6 (released May 29, 2026) the run behavior is selected from a single Run Mode dropdown — Ask, Auto-review, Allowlist, Allowlist (with Sandbox), or Run Everything. Auto-review is the default for new installs. If you never opted in but you are on a fresh 3.6+ install, that is why commands run on their own.

Which bucket are you in?

Symptom	Most likely cause	Jump to
Fresh Cursor 3.6+ install, never touched settings	Auto-review is the new default Run Mode	Step 1
Only `npm`/`git`/`python` commands skip the prompt	Allowlist prefix is too broad	Step 2
Setting is right in the app but ignored	A `.cursor/permissions.json` is overriding it	Step 3
Commands you described as “safe” run, others ask	Auto-review classifier matched them	Step 4
A `.cursorrules` / `.mdc` says “run without asking”	A rule is instructing Agent to skip the gate	Step 5
Only the first step of a plan prompted	Multi-step plan inherited one approval	Step 6

Common causes

Ordered by hit rate, highest first.

1. Run Mode is set to Auto-review or Run Everything

As of Cursor 3.6, Run Mode decides how shell, MCP, and Fetch tool calls are gated:

Ask — every call waits for your approval. This is what you want if you expected a prompt.
Auto-review — allowlisted calls run instantly, sandboxable calls run sandboxed, and everything else goes to an LLM classifier subagent that decides allow / try-differently / ask. This is the default for new users, so a brand-new install will run many commands on its own.
Allowlist / Allowlist (with Sandbox) — only allowlisted commands auto-run; the rest still ask.
Run Everything — no gate at all (the closest thing to old YOLO).

How to judge: Settings → Cursor Settings → Agents → Run Mode. If it is anything other than Ask, that explains silent execution.

2. Command allowlist is too permissive

Cursor matches allowlist entries by prefix: git matches git status, git diff, and git push. People add npm once for npm test and forget it also covers npm uninstall. A bare prefix or a wildcard means matching commands run with no prompt regardless of how innocent they look.

How to judge: Settings → Cursor Settings → Agents → Command allowlist. Any single-word prefix (npm, git, python) or wildcard is the culprit.

3. A permissions.json is overriding your app settings

This is the big change since this article first shipped. The old per-key settings (cursor.agent.yoloMode, cursor.agent.allowedCommands) were replaced by permissions.json. Cursor reads it from two places:

~/.cursor/permissions.json (per-user, applies everywhere)
<workspace>/.cursor/permissions.json (per-repo, applies in that repo)

When permissions.json defines a list, it fully replaces the in-app allowlist for that type and the in-app editor goes read-only. So you can be editing the UI to no effect while a checked-in workspace file grants auto-run. Per-user and per-repo arrays are concatenated, so a repo file can only add permissions, not remove yours.

How to judge: Search the repo and your home dir for permissions.json. If terminalAllowlist contains broad prefixes, or autoRun.allow_instructions is loose, that wins over the UI.

4. The Auto-review classifier let it through

In Auto-review, you can steer the classifier in plain language via autoRun.allow_instructions / block_instructions in permissions.json. If you wrote something like “allow build and test commands,” the classifier may read a wider command as matching your intent and run it. Cursor explicitly calls the classifier non-deterministic and “best-effort convenience, not a security boundary” — it can miss bad calls.

How to judge: Read your autoRun instructions. If they are broad or aspirational (“run whatever is needed”), tighten them or switch the repo to Ask.

5. A rules file grants auto-execution

A .cursorrules or .cursor/rules/*.mdc file with text like “always run shell commands without asking” gets parsed by Agent as an instruction and pushes the classifier toward running things for that session.

How to judge: Grep your repo for “without asking”, “no confirmation”, “auto run” inside rules files. Any match could be the culprit.

6. The command was queued in a multi-step plan

Agent plans several steps and runs them as a batch. The first step may prompt; subsequent steps in the same plan can inherit that consent and not re-prompt.

How to judge: Look at the chat. If the run started with a “Plan: 1, 2, 3” block and you clicked Approve once, every step in that plan can run without further prompts.

Before you start

Decide whether you want zero auto-execution (set Run Mode to Ask) or a small curated allowlist; the fix differs.
Stop any running Agent task before editing settings — Run Mode and permissions.json are read at the start of a turn, not mid-run.
Note your current permissions.json contents before editing, in case you want to restore them.

Information to collect

Cursor version from Cursor → About Cursor (Help → About on Windows/Linux). You should be on 3.6 or later as of June 2026.
The current Run Mode (Settings → Agents → Run Mode).
OS and shell (Cursor uses your default shell for the integrated terminal).
The exact command that ran without confirmation.
Contents of ~/.cursor/permissions.json and any <repo>/.cursor/permissions.json.
Any .cursorrules or .cursor/rules/*.mdc in the project.
Workspace .vscode/settings.json if present (legacy keys may linger).

Step-by-step fix

Step 1: Set Run Mode to Ask

Settings → Cursor Settings → Agents → Run Mode → Ask. This is the single biggest lever: in Ask mode every shell, MCP, and Fetch call waits for your approval. If you were on Auto-review (the new default) or Run Everything, this alone usually fixes it. Reload the window after changing it (Cmd/Ctrl+Shift+P → “Developer: Reload Window”).

Step 2: Empty the command allowlist

Settings → Cursor Settings → Agents → Command allowlist. Remove every entry. If you genuinely need an allowlist later, add exact strings (npm test, pnpm build), never bare prefixes or wildcards — remember matching is by prefix, so git also approves git push.

If the in-app allowlist editor is read-only, a permissions.json is controlling it — go to Step 3.

Step 3: Audit permissions.json (the override layer)

Open both files if they exist:

~/.cursor/permissions.json
<your-repo>/.cursor/permissions.json

A safe, locked-down file looks like this — empty allowlists plus explicit block instructions:

{
  "terminalAllowlist": [],
  "mcpAllowlist": [],
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Never delete files or directories (rm, rmdir, del).",
      "Never run git push, git reset --hard, or force operations.",
      "Never touch shell rc files, SSH config, or run package installs."
    ]
  }
}

Because per-user and per-repo arrays are concatenated, a checked-in repo file can only add allowed commands on top of yours — delete its terminalAllowlist/autoRun.allow_instructions entries or set Run Mode to Ask for that repo. Note that the legacy cursor.agent.yoloMode / cursor.agent.allowedCommands keys in settings.json are obsolete in 3.x; remove any leftovers so they do not confuse you.

Step 4: Tighten the Auto-review classifier (if you keep Auto-review)

If you want Auto-review’s fewer-prompts workflow but stricter behavior, scope allow_instructions to exact, low-risk categories and add block_instructions for anything destructive (see the block list above). Treat the classifier as convenience, not security — Cursor says so itself. For anything you truly cannot afford to run by accident, keep that repo on Ask.

Step 5: Scrub rules files

Grep your repo for any rule that grants auto-execution:

grep -ri "without asking\|no confirmation\|auto.run\|skip prompt" .cursor .cursorrules 2>/dev/null

Delete or rephrase those lines. Rules are interpreted as instructions; an aggressive rule will steer the classifier toward running things.

Step 6: Update Cursor

Cursor → Check for Updates. Earlier 0.x builds had assorted confirm-bypass quirks (e.g. &&-chained or cd ...-prefixed commands slipping the gate); the modern Run Mode model in 3.6+ supersedes all of those. If you are stuck far behind, update before debugging further.

Step 7: Verify with a known-harmless command

In a scratch repo, ask Agent: “Run echo TEST && false.” In Ask mode you must get a confirmation prompt. If it runs silently, jump back to Step 1 (Run Mode) and Step 3 (permissions.json override).

Step 8: Hard backstop — sandbox the shell

If you still cannot trust the gate, point Cursor’s integrated terminal at a sandboxed shell wrapper that requires a stdin yes/no for any command outside a safe list: Settings → Terminal → Integrated → Default Profile. Heavy-handed but bulletproof, and independent of any Cursor setting.

How to confirm it’s fixed

Run a fresh Agent prompt that needs a shell command. In Ask mode the confirmation popup must appear.
Run a multi-step Agent plan. Every shell step should re-prompt, not just the first.
Reload the window and repeat — the Run Mode and permissions.json must survive a reload.
Re-open the in-app allowlist. If you cleared it but it is read-only and still shows entries, a permissions.json is still in control.

Long-term prevention

Default sensitive repos to Ask; reserve Auto-review for low-stakes, green-field work.
Keep terminalAllowlist empty unless you have a strong reason; an empty list is the safe default.
Commit a locked-down .cursor/permissions.json (empty allowlists + block_instructions) to shared repos so teammates inherit safe defaults.
Treat .cursorrules and permissions.json like code — review changes in PRs so nobody slips in an auto-run rule or a broad allowlist.
Audit user vs workspace config during onboarding. People who clone repos inherit the repo’s permissions.json.

Common pitfalls

Assuming the classifier is a safety boundary. Cursor states it is “best-effort convenience, not a security boundary.”
Adding npm to the allowlist for npm test, forgetting prefix matching also covers npm uninstall.
Editing the in-app allowlist while a permissions.json silently overrides it (the editor goes read-only when this happens).
Expecting a repo permissions.json to remove your permissions — arrays concatenate, so it can only add.
Looking for the old cursor.agent.yoloMode key. It is gone in 3.x; Run Mode + permissions.json replaced it.

FAQ

Where did YOLO mode go? It was renamed Auto-Run, and in Cursor 3.6 the behavior is selected from the Run Mode dropdown (Settings → Agents). Choose Ask to require a prompt every time.
Why does a fresh install run commands on its own? Auto-review is the default Run Mode for new users as of Cursor 3.6 (May 29, 2026). Switch to Ask if you want approval prompts.
The in-app allowlist won’t let me edit it. Why? A permissions.json (~/.cursor/ or the repo’s .cursor/) is defining that list, which makes the in-app editor read-only. Edit the JSON instead.
Can I allowlist just safe commands? Yes. Use exact strings like npm test or pnpm build in terminalAllowlist, never bare prefixes or wildcards (matching is prefix-based).
Does the gate also cover file edits? No. File edits go through the diff review flow. Run Mode and the allowlist gate shell, MCP, and Fetch tool calls.
Why did Agent push to main without asking? Either git was an allowlist prefix (which also matches git push), Run Mode was Auto-review/Run Everything, or you approved a multi-step plan that included the push.
Is there a panic-stop? Click the stop button on the running task, or Cmd/Ctrl+Shift+P → “Cursor: Stop Agent.” For a runaway process, kill the integrated terminal.

External references: Cursor Agent Security docs and the permissions.json reference.

Tags: #Cursor #Troubleshooting #agent #Debug