Cursor YOLO mode nel 2026: Auto-review, Allowlist e Run Everything

Lo YOLO mode di Cursor è stato rimosso?

No. Lo YOLO mode di Cursor, introdotto con la versione 0.44 a dicembre 2024, è stato rinominato Auto-run a marzo 2025 e sopravvive come modalità Run Everything, in Settings > Agents > Approvals & Execution. Da Cursor 3.6 (maggio 2026) la modalità predefinita è Auto-review, ed è per questo che la vecchia casella YOLO non c'è più. La storia completa, dal changelog di Cursor:

Fonti: il changelog di Cursor e la sua documentazione sulle modalità di esecuzione, consultati il 18 ottobre 2026.

Se hai seguito un tutorial del 2025 e non trovi l'interruttore "YOLO" o "Auto-run", ecco perché. Oggi le modalità stanno in Settings > Agents > Approvals & Execution.

Cosa permettono le modalità auto-run di Cursor?

Cursor ha oggi tre modalità di esecuzione, eredi dell'impostazione Auto-run. Auto-review esegue le chiamate in allowlist e i comandi di shell compatibili con la sandbox, e lascia il resto al giudizio di un modello classificatore. Allowlist esegue solo ciò che è nella tua lista e chiede conferma per tutto il resto. Run Everything esegue ogni chiamata a uno strumento senza sandbox, senza classificatore e senza approvazione. Tutte e tre valgono per i comandi di shell, per le chiamate agli strumenti MCP e per le richieste web.

La tabella non mostra tre dettagli che, nella pratica, decidono quanto è sicura ogni modalità.

Primo, le chiamate in allowlist saltano la sandbox. La documentazione di Cursor sulle modalità di esecuzione è esplicita: le chiamate shell, Fetch e MCP in allowlist girano fuori dalla sandbox. Una voce ampia come npx, zsh o perfino find concede all'agente permessi completi su qualsiasi comando che inizi con quella voce. Lo staff stesso di Cursor ha usato proprio questi tre esempi per spiegare perché ha costruito la sandbox invece di un'allowlist più granulare.

Secondo, il classificatore è un modello che giudica un altro modello. In Auto-review, Cursor manda a un classificatore tutto ciò che non è in allowlist e non può girare nella sandbox (Cursor indica Gemini 3.5 Flash Lite, con Haiku come riserva). Cursor dichiara che il classificatore blocca circa il 4% delle azioni. La sua documentazione aggiunge due frasi da tenere a mente: "Auto-review non è un confine di sicurezza" e "il classificatore può sbagliare".

Terzo, Ask Every Time esiste ancora per alcuni utenti. Dalla 3.5 i nuovi utenti non possono sceglierla; l'equivalente è Allowlist con una lista vuota. Chi l'aveva la conserva, e a ottobre 2026, dopo la cancellazione di un intero disco, lo staff di Cursor la consigliava ancora.

Come si attiva lo YOLO mode in Cursor oggi?

Per attivare lo YOLO mode in Cursor, apri Settings > Agents > Approvals & Execution e scegli Run Everything. Il comportamento YOLO è questo: nessuna richiesta di conferma, nessuna sandbox, nessun classificatore. Se l'opzione non c'è, probabilmente un amministratore del team l'ha disattivata (gli amministratori Enterprise possono nascondere Run Everything e bloccare la modalità), oppure la tua versione di Cursor è precedente alle modalità attuali.

Nella Cursor CLI, --yolo (alias --force) e il comando /auto-run attivano Run Everything; da febbraio 2026 --yolo approva tutto in automatico, secondo Cursor, "in modo coerente tra fiducia, MCP e approvazioni dei comandi". --auto-review e /auto-review selezionano invece Auto-review.

Leggi le due sezioni successive prima di attivarlo: le protezioni che sembrano fare al caso di Run Everything coprono meno di quanto suggeriscano i loro nomi.

Cosa blocca davvero la sandbox di Cursor?

Su macOS e Linux, la sandbox di Cursor limita le scritture dei comandi di shell al workspace e blocca l'accesso alla rete, tranne verso i domini consentiti dalle tue impostazioni. Impedisce di scrivere su file come .git/hooks e .cursor/*.json. Per impostazione predefinita non limita le letture, e i comandi in allowlist la saltano del tutto. A ottobre 2026 le shell di Windows nativo non hanno sandbox.

La sandbox è applicata dal sistema operativo, non dal modello, ed è per questo che regge anche quando l'agente viene manipolato. Su macOS, Cursor usa Seatbelt tramite sandbox-exec. Su Linux usa Landlock e seccomp, e richiede il kernel 6.2 o successivo con gli user namespace non privilegiati; su un kernel più vecchio Cursor torna a chiedere conferma prima di ogni comando. Su Windows nativo, lo staff di Cursor ha dichiarato a luglio e di nuovo a ottobre 2026 che i comandi del terminale non girano in una sandbox; la strada documentata è WSL2 o un dev container.

Cosa può e non può fare un comando nella sandbox, con le impostazioni predefinite di Cursor:

• Scritture: solo dentro il workspace. Alcuni percorsi restano protetti da scrittura anche lì: .cursor/*.json, .git/hooks/, .git/config, .vscode/ e .cursorignore.
• Rete: bloccata, poi aperta secondo la tua impostazione di rete. L'impostazione predefinita aggiunge l'elenco di domini per sviluppatori di Cursor, che comprende github.com, *.googleapis.com e registry.npmjs.org. Gli indirizzi privati e l'endpoint dei metadati cloud restano bloccati.
• Letture: il confine di lettura predefinito è l'intero sistema, e la documentazione di riferimento di Cursor precisa che con questo confine ~/.ssh è "sempre leggibile". Solo dalla 3.23 puoi impostare il confine sul workspace.
• File temporanei: /tmp e le directory temporanee della piattaforma sono scrivibili, a meno che tu non disattivi l'opzione.

E tre vie d'uscita, tutte documentate:

1. L'allowlist, come sopra: le chiamate in allowlist non entrano mai nella sandbox.
2. Il nuovo tentativo. Quando un comando fallisce per una restrizione della sandbox, l'agente può rieseguirlo fuori. In Auto-review il classificatore esamina quella riesecuzione; nelle altre modalità ti viene chiesta conferma.
3. La configurazione del repository stesso. Il .cursor/sandbox.json di un progetto ha la precedenza sul tuo, e "type": "insecure_none" disattiva la sandbox del tutto. Le policy degli amministratori del team non possono essere indebolite da file locali, ma uno sviluppatore che lavora da solo non ha nessun amministratore.

La sandbox ha avuto anche evasioni reali, tutte corrette: scrivere git hook per eseguire codice fuori dalla sandbox (CVE-2026-26268, corretta nella 2.5), una directory di lavoro e dei symlink che puntavano fuori dal workspace (CVE-2026-50548 e CVE-2026-50549, corrette nella 3.0), e un wrapper di virtualenv Python eseguito da un'estensione dell'editor (CVE-2026-73217, corretta nella 3.1.2). Tieni Cursor aggiornato. La nostra guida alle evasioni dalla sandbox degli agenti di coding analizza lo stesso schema nei vari strumenti.

La modalità Run Everything (YOLO) di Cursor è sicura?

Non su una macchina a cui tieni. Run Everything non ha né sandbox né classificatore, quindi l'agente agisce con la tua identità, i tuoi token e i tuoi file, e tra un comando sbagliato e il suo effetto c'è solo la scelta del modello di non eseguirlo. Nel forum di Cursor ci sono segnalazioni di interi dischi cancellati in questa modalità a ottobre 2026. Va bene su una macchina che puoi buttare via; altrove è un rischio.

Il forum di Cursor mostra cosa significa in concreto. Tra marzo e ottobre 2026, almeno sei utenti Windows hanno segnalato di aver perso un disco o la maggior parte dei propri file per colpa di un comando dell'agente, e diversi di loro per lo stesso schema: un cmd /c "rmdir /s /q ..." in cui le virgolette saltavano, così il percorso si riduceva alla radice del disco. Lo staff ha risposto che corrispondeva a "un problema che stiamo già seguendo". Due di quelle segnalazioni sono arrivate nella stessa settimana di ottobre 2026: il 13 ottobre un utente ha perso un disco in Auto-review, e lo staff ha risposto che Auto-review "avrebbe dovuto fermare un comando ricorsivo del genere e chiedere conferma prima"; il 17 ottobre un utente ha perso un disco da 1 TB in Run Everything, dove, nelle parole dello staff, "tutte le chiamate agli strumenti vengono eseguite automaticamente, senza approvazione, sandbox o classificatore". Ad aprile 2026 The Register ha raccontato che un agente di Cursor ha cancellato il database di produzione di una startup e i suoi backup chiamando l'API di un servizio di hosting con un token trovato in un file che non c'entrava nulla. L'articolo non dice quale modalità di esecuzione fosse attiva.

Due protezioni che sembrerebbero servire, e invece non sono servite:

• File-Deletion Protection riguarda lo strumento con cui l'agente cancella i file. Lo staff ha confermato a ottobre 2026 che non si applica "ai comandi del terminale come rd o rmdir". Le cancellazioni fatte dal terminale, inoltre, "NON sono coperte dai checkpoint di Cursor né dalla cronologia locale", quindi non c'è modo di annullarle.
• External-File Protection impedisce all'agente di creare o modificare file fuori dal workspace tramite i suoi strumenti per i file. Secondo Cursor "non blocca la lettura di file fuori dal workspace", e non ha alcun effetto su ciò che fa un comando del terminale.

Cursor sta stringendo le maglie: da agosto 2026 Auto-review blocca le cancellazioni ricorsive e forzate invece di eseguirle in automatico, e la CLI dell'8 ottobre 2026 chiede conferma prima delle cancellazioni "il cui bersaglio potrebbe risolversi in modo diverso da come è scritto". La segnalazione del 13 ottobre mostra perché la documentazione parla di una protezione best-effort.

I nostri dati sugli agenti senza guardia vanno nella stessa direzione. Nel nostro studio precedente, in cui gli agenti costruivano una piattaforma su un database applicativo attivo, due configurazioni senza guardia hanno eseguito DROP SCHEMA su quel database diciotto volte in tutto.

Perché l'allowlist non è un confine di sicurezza?

L'allowlist confronta il testo di un comando, e lo stesso comando si può scrivere in molti modi. La documentazione di Cursor lo dice senza giri di parole: "L'allowlist è best-effort, non un confine di sicurezza. Agenti determinati o una prompt injection potrebbero aggirarla." Ecco come funziona oggi il confronto:

• Le voci sono prefissi e distinguono maiuscole e minuscole: git corrisponde a git status ma non a gitk. npm:install* separa il comando da un pattern di argomenti. Non ci sono espressioni regolari.
• Una catena viene verificata comando per comando: cd api && npm test | tail -20 viene eseguita in automatico solo se cd, npm e tail sono ciascuno nella lista.
• I comandi in allowlist girano fuori dalla sandbox, quindi una sola voce ampia annulla la sandbox per tutto ciò che inizia con quella voce.

La storia degli aggiramenti è lunga e pubblica. All'epoca dello YOLO mode i comandi concatenati riuscivano a superare entrambe le liste, ed è per questo che Cursor ha eliminato la denylist nella 1.3. Da allora Cursor ha pubblicato avvisi di sicurezza per un aggiramento dell'allowlist tramite backtick e $(...) (CVE-2025-54131), per built-in della shell che venivano eseguiti senza comparire nella lista (CVE-2026-22708), e per l'esecuzione di comandi sotto "Use AllowList" tramite prompt injection da un sito web (CVE-2026-31854). Ad agosto 2026 un utente ha mostrato due forme PowerShell che eseguivano in automatico comandi arbitrari dietro una voce in allowlist; lo staff le ha girate al team, e a fine settembre ha detto che ora i blocchi di script chiedono sempre l'approvazione.

Perché l'auto-run di Cursor o la mia allowlist non funzionano?

Se Cursor continua a chiedere l'approvazione o sembra ignorare la tua allowlist, di solito la causa è una di queste:

• Un terminalAllowlist non vuoto in ~/.cursor/permissions.json blocca la modalità su Allowlist e rende indisponibile Auto-review (staff di Cursor, agosto 2026).
• Un comando concatenato parte senza richiesta di conferma solo se tutti i comandi che contiene sono nella lista.
• Su Linux la sandbox richiede il kernel 6.2 o successivo con gli user namespace non privilegiati. In mancanza di questi, Cursor chiede conferma prima di ogni comando.
• Un amministratore del team ha bloccato la modalità di esecuzione o nascosto Run Everything.
• Nella vecchia modalità Run in Sandbox l'allowlist non veniva applicata affatto perché, nelle parole di Cursor, "la sandbox è pensata per sostituire l'allowlist".

Il .cursorignore protegge il file .env in Cursor?

Solo in parte: un comando del terminale eseguito fuori dalla sandbox può ancora fare cat .env. .cursorignore nasconde i file agli strumenti per i file dell'agente, a Tab e alle menzioni @, e l'elenco di esclusioni predefinito di Cursor include già .env*. Ma sul resto la documentazione è chiara: "Gli strumenti del terminale e dei server MCP usati da Agent non possono bloccare l'accesso al codice soggetto a .cursorignore." Dentro la sandbox, i file elencati in .cursorignore non sono leggibili, quindi aggiungi tu .env* a quel file invece di affidarti all'elenco predefinito. Fuori dalla sandbox, cioè in Run Everything, con i comandi in allowlist, con le uscite approvate e su Windows nativo, cat .env funziona.

Se un file non deve mai arrivare al modello, tienilo fuori dal workspace oppure blocca la lettura stessa, ed è ciò che fanno le due sezioni successive. Per la stessa domanda su Claude Code, vedi cosa invia Claude Code ad Anthropic.

Quale modalità di esecuzione di Cursor conviene usare?

Su una macchina di sviluppo, oggi, questa è la configurazione che useremmo:

1. macOS o Linux: Auto-review con la sandbox attiva. Limita l'allowlist ai comandi di sola lettura (git status, git diff, ls) e inseriscila dall'interfaccia delle impostazioni invece che in permissions.json se vuoi che Auto-review resti disponibile.
2. Chiudi letture e rete in ~/.cursor/sandbox.json (il confine di lettura richiede Cursor 3.23 o successivo), e scegli l'impostazione di rete che usa solo sandbox.json se non vuoi i domini predefiniti di Cursor:

{
  "readBoundary": "workspace",
  "networkPolicy": {
    "default": "deny",
    "allow": ["registry.npmjs.org", "pypi.org", "files.pythonhosted.org"]
  }
}

Se una toolchain ha bisogno di un file fuori dal progetto, aggiungilo a additionalReadPaths invece di riaprire l'intero sistema. 3. Windows nativo: Allowlist con una lista vuota, oppure sposta il progetto in WSL2 o in un dev container, dove la sandbox c'è. 4. Team: imponilo a livello centrale. La guida di hardening di Cursor raccomanda di impostare la modalità di esecuzione dell'organizzazione "su Auto-review (non Run Everything)" con la sandbox attiva, e di distribuire gli hook dalla dashboard. Tieni presente che nei gruppi dell'organizzazione vince l'impostazione di sandbox più permissiva. 5. Run Everything solo dove la macchina è usa e getta:

I Cloud Agents di Cursor seguono già questo modello: ognuno gira nella propria microVM e non chiede mai approvazione, con l'accesso a internet attivo per impostazione predefinita a meno che tu non lo limiti.

Gli hook di Cursor funzionano anche in Run Everything?

Sì, ed è proprio questo a renderli l'unico controllo che resta attivo in tutte le modalità di esecuzione. Un hook è uno script che Cursor chiama prima di un'azione; può rispondere deny, e l'azione non viene eseguita. Il 17 ottobre 2026, a chi chiedeva come proteggere una configurazione Run Everything dalle cancellazioni ricorsive, lo staff di Cursor ha risposto: "La protezione principale, lì, è l'hook."

Ecco un hook minimale a livello utente che rifiuta le cancellazioni ricorsive in ogni shell usata da Cursor. In ~/.cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      { "command": "node ./hooks/block-recursive-delete.mjs", "timeout": 5, "failClosed": true }
    ]
  }
}

E ~/.cursor/hooks/block-recursive-delete.mjs (i percorsi degli hook utente si risolvono a partire da ~/.cursor/):

let raw = "";
for await (const chunk of process.stdin) raw += chunk;
const { command = "" } = JSON.parse(raw || "{}");

const RECURSIVE_DELETE = [
  /\brm\s+(-[a-zA-Z]*[rR][a-zA-Z]*|--recursive)\b/, // rm -rf, rm -r, rm --recursive
  /\b(rmdir|rd)\s+\/s\b/i,                         // cmd: rmdir /s, rd /s
  /\bdel\s+(\/\w\s+)*\/s\b/i,                      // cmd: del /s
  /\bRemove-Item\b[^|;&]*-Recurse\b/i,             // PowerShell
];

if (RECURSIVE_DELETE.some((re) => re.test(command))) {
  console.log(JSON.stringify({
    permission: "deny",
    user_message: `Blocked a recursive delete: ${command}`,
    agent_message: "Recursive deletes are blocked on this machine. Delete files by explicit path, or ask the user to run the command.",
  }));
} else {
  console.log(JSON.stringify({ permission: "allow" }));
}

Tre limiti da conoscere prima di farci affidamento, tutti indicati dallo staff di Cursor:

• Viene applicato solo deny. A marzo 2026 lo staff ha scritto che "gli hook applicano solo il permesso deny. Sia allow sia ask vengono di fatto ignorati." Ecco perché lo script risponde allow per tutto il resto: lascia la decisione alla tua modalità di esecuzione. Non contare su ask per far tornare una richiesta di conferma.
• Una race condition nota può far saltare un deny. A luglio 2026 lo staff ha confermato che un hook preToolUse che restituisce deny può perdere una race e il comando viene eseguito, aggiungendo: "per favore non affidatevi solo a un hook di deny come blocco definitivo." A settembre il problema era ancora aperto.
• Gli hook non vedono la modalità di esecuzione. Lo script non può diventare più severo solo in Run Everything.

E un limite del metodo: un pattern è un filtro, non un confine. Intercetta le forme che hai previsto, non vede una cancellazione nascosta in un file di script o scritta in un altro modo, e scatta anche su comandi innocui: l'abbiamo provato su un insieme di comandi di esempio e ha rifiutato rm -rf node_modules e git rm -r --cached insieme alle vere cancellazioni di massa. Sotto, tieni comunque la sandbox.

La lacuna che nessuna modalità colma

Ogni impostazione di questa guida decide ciò che Cursor può eseguire. Nessuna decide ciò che Cursor scrive, e la maggior parte del rischio del codice scritto dall'AI sta nel diff, non nel terminale. Auto-review lascerà tranquillamente che l'agente salvi un endpoint senza controllo di autorizzazione, un gestore dei rimborsi senza limite di importo o una query costruita concatenando stringhe, perché niente di tutto questo è un comando. Sono falle di logica di business, e un'impostazione del terminale non può vederle. Gli agenti, poi, iniziano ogni sessione senza le regole del tuo team, a meno che qualcosa non gliele metta davanti nel momento in cui scrivono.

È questo il livello che VibeDefend aggiunge dentro Cursor. Si installa sulla macchina con un solo comando: serve all'agente le tue regole di business e di sicurezza mentre scrive, controlla il diff prima del commit, e fa girare le sue guardie come hook di Cursor prima di ogni chiamata a uno strumento, qualunque sia la modalità di esecuzione. Per impostazione predefinita rifiutano le letture di file .env, chiavi SSH e credenziali cloud, rm -rf su una directory radice o home, i force-push, le istruzioni DROP e i download passati in pipe a una shell. La guardia è lo stesso tipo di filtro dell'hook qui sopra, che manteniamo noi per te, con gli stessi limiti: nel nostro studio controllato del 24 agosto 2026 ha verificato 1.769 comandi di shell e ne ha rifiutati diciassette, cioè un problema reale intercettato, tre decisioni corrette secondo la policy e tredici falsi positivi. Sul codice vero e proprio, la configurazione con il livello ha implementato alla lettera 57 dettagli di regola valutati su 64 (89%), contro 7 su 55 (13%) con un file di regole mantenuto a mano e 8 su 65 (12%) senza nulla.

Se usi Cursor in Run Everything di proposito, in un container, con una guardia nell'hook, hai una configurazione difendibile. Se lo usi così sul tuo portatile perché le richieste di conferma ti infastidivano, leggi la nostra guida alla sicurezza di Cursor, poi confronta con ciò che toglie il --yolo di Codex e con il --dangerously-skip-permissions di Claude Code, e infine parliamone.

Domande frequenti

Lo YOLO mode di Cursor esiste ancora?

Sì, con un altro nome. Lo YOLO mode è stato rinominato Auto-run a marzo 2025. Il suo comportamento "esegui tutto senza chiedere" oggi è la modalità Run Everything, in Settings > Agents > Approvals & Execution. Da Cursor 3.6 la modalità predefinita è Auto-review.

Come si attiva lo YOLO mode su Cursor?

Apri Settings > Agents > Approvals & Execution e scegli Run Everything. Nella Cursor CLI usa --yolo (alias --force) oppure /auto-run. Se l'opzione non c'è, probabilmente un amministratore del team l'ha disattivata, oppure la tua versione di Cursor è precedente alle modalità attuali.

Cosa fa Auto-review in Cursor?

Auto-review è la modalità di esecuzione predefinita di Cursor dalla versione 3.6 (29 maggio 2026). Le chiamate in allowlist partono subito, i comandi di shell compatibili con la sandbox girano al suo interno, e sul resto un modello classificatore decide se consentire, reindirizzare o chiedere a te. Copre le chiamate shell, MCP e Fetch. La documentazione di Cursor dice che non è un confine di sicurezza.

Che differenza c'è tra Auto-review e Run Everything?

Auto-review esegue le chiamate in allowlist, fa girare i comandi di shell nella sandbox quando può, e manda tutto il resto a un modello classificatore che può consentirlo, suggerire un altro approccio o chiedere a te. Run Everything esegue ogni chiamata a uno strumento senza sandbox e senza classificatore.

È sicuro usare Run Everything?

Solo su una macchina usa e getta: un container o una VM nuovi, senza credenziali di lunga durata e con la rete limitata. Su una postazione di lavoro lascia che l'agente agisca con la tua identità, e nel forum di Cursor ci sono segnalazioni di interi dischi cancellati in questa modalità a ottobre 2026.

Cosa blocca esattamente la sandbox di Cursor?

Su macOS e Linux limita le scritture dei comandi di shell al workspace, blocca la rete tranne i domini consentiti dalle tue impostazioni, e protegge file come .cursor/*.json e .git/hooks. Per impostazione predefinita non limita le letture fuori dal workspace; Cursor 3.23 ha aggiunto un confine di lettura Workspace. A ottobre 2026 le shell di Windows nativo non hanno sandbox.

Perché Cursor ignora la mia allowlist o l'auto-run non parte?

Le cause più comuni: un terminalAllowlist non vuoto in ~/.cursor/permissions.json blocca la modalità su Allowlist e disattiva Auto-review; un comando concatenato viene eseguito in automatico solo se tutti i comandi che contiene sono in allowlist; su Linux, con un kernel precedente al 6.2 o senza user namespace non privilegiati, Cursor chiede conferma prima di ogni comando; e nella vecchia modalità Run in Sandbox l'allowlist non veniva applicata affatto.

L'auto-run vale anche per gli strumenti MCP?

Sì. Le chiamate agli strumenti MCP seguono le stesse modalità dei comandi del terminale. In Auto-review, gli strumenti MCP in allowlist (voci server:tool, wildcard ammesse) partono subito e il resto va al classificatore. In Run Everything partono tutti.

Il .cursorignore impedisce a Cursor di leggere il mio file .env?

Non dal terminale. .cursorignore nasconde i file agli strumenti per i file dell'agente e alle menzioni, e .env* è nell'elenco di esclusioni predefinito di Cursor, ma la documentazione di Cursor afferma che gli strumenti del terminale e MCP non possono bloccare l'accesso ai file esclusi. Un comando nella sandbox non può leggere i file elencati in .cursorignore; un comando in allowlist, Run Everything o una shell di Windows nativo invece sì.