YOLO mode de Cursor en 2026: qué dejan hacer Auto-review, Allowlist y Run Everything

¿Ha eliminado Cursor el YOLO mode?

No. El YOLO mode de Cursor, que llegó con la versión 0.44 en diciembre de 2024, pasó a llamarse Auto-run en marzo de 2025 y sobrevive como el modo Run Everything, en Settings > Agents > Approvals & Execution. Desde Cursor 3.6 (mayo de 2026) el modo por defecto es Auto-review, y por eso ha desaparecido la antigua casilla de YOLO. El recorrido completo, según el changelog de Cursor:

Fuentes: el changelog de Cursor y la documentación de los modos de ejecución, consultados el 18 de octubre de 2026.

Si seguiste un tutorial de 2025 y no encuentras el interruptor de "YOLO" o de "Auto-run", esa es la razón. Los modos están ahora en Settings > Agents > Approvals & Execution.

¿Qué permiten los modos de auto-run de Cursor?

Cursor tiene ahora tres modos de ejecución, herederos del antiguo ajuste Auto-run. Auto-review ejecuta las llamadas de la allowlist y los comandos de shell que admiten sandbox, y un modelo clasificador juzga el resto. Allowlist ejecuta solo lo que está en tu lista y pregunta por todo lo demás. Run Everything ejecuta todas las llamadas a herramientas sin sandbox, sin clasificador y sin aprobación. Los tres modos se aplican a los comandos de shell, a las llamadas a herramientas MCP y a las peticiones web.

La tabla esconde tres detalles que determinan hasta qué punto es seguro cada modo en la práctica.

Primero, las llamadas de la allowlist se saltan el sandbox. La documentación de los modos de ejecución de Cursor lo dice sin rodeos: las llamadas de shell, Fetch y MCP que están en la allowlist se ejecutan fuera de él. Una entrada amplia como npx, zsh o incluso find le da al agente permisos completos para todo lo que empiece por ella. El propio equipo de Cursor puso esos tres ejemplos al explicar por qué construyó el sandbox en lugar de una allowlist más granular.

Segundo, el clasificador es un modelo que juzga a otro modelo. En Auto-review, Cursor envía a un clasificador todo lo que no está en la allowlist ni admite sandbox (Cursor cita Gemini 3.5 Flash Lite, con Haiku como respaldo). Según Cursor, bloquea alrededor del 4 % de las acciones. Su documentación añade dos frases que conviene tener presentes: "Auto-review no es una frontera de seguridad" y "El clasificador puede equivocarse".

Tercero, Ask Every Time sigue existiendo para algunos usuarios. Desde la 3.5 los usuarios nuevos no pueden elegirlo; el equivalente es Allowlist con la lista vacía. Quien ya lo tenía lo conserva, y el equipo de Cursor todavía lo recomendaba en octubre de 2026, después del borrado de un disco.

¿Cómo se activa ahora el YOLO mode en Cursor?

Para activar el YOLO mode en Cursor, abre Settings > Agents > Approvals & Execution y elige Run Everything. Ese es el comportamiento YOLO: sin confirmaciones, sin sandbox y sin clasificador. Si la opción no aparece, lo más probable es que un administrador del equipo la haya desactivado (los administradores Enterprise pueden ocultar Run Everything e imponer un modo), o que tu versión de Cursor sea anterior a los modos actuales.

En la CLI de Cursor, --yolo (alias --force) y el comando /auto-run activan Run Everything; desde febrero de 2026, --yolo lo aprueba todo automáticamente "por igual en las aprobaciones de confianza, de MCP y de comandos". --auto-review y /auto-review, en cambio, seleccionan Auto-review.

Lee las dos secciones siguientes antes de activarlo: las protecciones que parecen aplicarse a Run Everything cubren menos de lo que sugieren sus nombres.

¿Qué bloquea de verdad el sandbox de Cursor?

En macOS y Linux, el sandbox de Cursor limita la escritura de los comandos de shell al workspace y bloquea el acceso a la red salvo a los dominios que permitan tus ajustes. Protege contra escritura archivos como .git/hooks y .cursor/*.json. Por defecto no limita las lecturas, y los comandos de la allowlist se lo saltan por completo. A fecha de octubre de 2026, los shells de Windows nativo no tienen sandbox.

El sandbox lo aplica el sistema operativo, no el modelo, y por eso resiste aunque el agente esté siendo manipulado. En macOS, Cursor usa Seatbelt mediante sandbox-exec. En Linux usa Landlock y seccomp, y necesita un kernel 6.2 o posterior con user namespaces sin privilegios; con un kernel más antiguo, Cursor pasa a preguntar antes de cada comando. En Windows nativo, el equipo de Cursor afirmó en julio y de nuevo en octubre de 2026 que los comandos de terminal no se ejecutan en un sandbox; la vía documentada es WSL2 o un dev container.

Lo que un comando dentro del sandbox puede y no puede hacer, con los valores por defecto de Cursor:

• Escrituras: solo dentro del workspace. Algunas rutas siguen protegidas contra escritura incluso ahí: .cursor/*.json, .git/hooks/, .git/config, .vscode/ y .cursorignore.
• Red: bloqueada, y después abierta según tu ajuste de red. El ajuste por defecto añade la lista de dominios para desarrolladores de Cursor, que incluye github.com, *.googleapis.com y registry.npmjs.org. Las direcciones privadas y el endpoint de metadatos de la nube siguen bloqueados.
• Lecturas: la frontera de lectura por defecto es todo el sistema, y la referencia de Cursor indica que, con ella, ~/.ssh es "siempre legible". Solo desde la 3.23 puedes limitar esa frontera al workspace.
• Archivos temporales: /tmp y los directorios temporales de la plataforma admiten escritura salvo que lo desactives.

Y tres formas de salir de él, todas documentadas:

1. La allowlist, como ya hemos visto: las llamadas de la allowlist nunca entran en el sandbox.
2. El reintento. Cuando un comando falla por una restricción del sandbox, el agente puede volver a ejecutarlo fuera. En Auto-review, el clasificador revisa ese reintento; en los demás modos, se te pregunta a ti.
3. La configuración del propio repositorio. El .cursor/sandbox.json de un proyecto tiene prioridad sobre el tuyo, y "type": "insecure_none" desactiva el sandbox por completo. Los archivos locales no pueden debilitar las políticas de administración de un equipo, pero un desarrollador que trabaja solo no tiene administrador.

El sandbox también ha tenido escapes reales, todos corregidos: escribir git hooks para ejecutar código fuera de él (CVE-2026-26268, corregida en la 2.5), un directorio de trabajo y unos enlaces simbólicos que apuntaban fuera del workspace (CVE-2026-50548 y CVE-2026-50549, corregidas en la 3.0) y un wrapper de virtualenv de Python ejecutado por una extensión del editor (CVE-2026-73217, corregida en la 3.1.2). Mantén Cursor actualizado. Nuestra guía sobre los escapes de sandbox en agentes de código recorre el patrón en distintas herramientas.

¿Es seguro el modo Run Everything (YOLO) de Cursor?

No en una máquina que te importe. Run Everything no tiene sandbox ni clasificador, así que el agente actúa con tu identidad, tus tokens y tus archivos, y lo único que se interpone entre un comando dañino y su efecto es que el modelo decida no ejecutarlo. En el foro de Cursor hay casos de discos enteros borrados en este modo en octubre de 2026. Es razonable en una máquina desechable y arriesgado en cualquier otra.

El propio foro de Cursor muestra lo que eso supone en la práctica. Entre marzo y octubre de 2026, al menos seis usuarios de Windows contaron que habían perdido un disco o la mayoría de sus archivos por un comando del agente, varios de ellos por el mismo patrón: un cmd /c "rmdir /s /q ..." cuyas comillas se rompieron, de modo que la ruta quedó reducida a la raíz de la unidad. El equipo de Cursor dijo que coincidía con "un problema del que ya hacemos seguimiento". Dos de esos casos llegaron la misma semana de octubre de 2026: el 13 de octubre un usuario perdió un disco en Auto-review, y el equipo respondió que Auto-review "debería haber detenido un comando recursivo así y haber preguntado antes"; el 17 de octubre otro usuario perdió un disco de 1 TB en Run Everything, donde, en palabras del equipo, "todas las llamadas a herramientas se ejecutan automáticamente, sin aprobación, sin sandbox y sin clasificador". En abril de 2026, The Register contó que un agente de Cursor borró la base de datos de producción de una startup y sus copias de seguridad llamando a la API de un proveedor de hosting con un token que encontró en un archivo que no tenía nada que ver. El artículo no dice qué modo de ejecución estaba activo.

Dos protecciones que parecían capaces de evitarlo, y no lo evitaron:

• File-Deletion Protection cubre la herramienta de borrado de archivos del propio agente. En octubre de 2026 el equipo confirmó que no se aplica "a comandos de terminal como rd o rmdir". Los borrados hechos desde el terminal "NO están cubiertos por los checkpoints de Cursor ni por el historial local", así que no hay forma de deshacerlos.
• External-File Protection impide que el agente cree o modifique archivos fuera del workspace a través de sus herramientas de archivos. "No bloquea la lectura de archivos fuera del workspace", y no controla lo que hace un comando de terminal.

Cursor ha ido endureciendo estas protecciones: desde agosto de 2026 Auto-review bloquea los borrados recursivos y forzados en lugar de ejecutarlos automáticamente, y la CLI del 8 de octubre de 2026 pregunta antes de los borrados "cuyo destino podría resolverse de forma distinta a como está escrito". El caso del 13 de octubre muestra por qué la documentación lo califica de best-effort.

Nuestros propios datos sobre agentes sin guardián apuntan en la misma dirección. En nuestro estudio anterior, en el que los agentes construían una plataforma sobre una base de datos de aplicación en funcionamiento, dos configuraciones sin guardián ejecutaron DROP SCHEMA sobre esa base dieciocho veces en total.

6+

discos o carpetas de Windows borrados por un agente de Cursor, según su foro, de marzo a octubre de 2026

4 %

porcentaje de acciones que, según Cursor, bloquea el clasificador de Auto-review

18

ejecuciones de DROP SCHEMA contra una base de datos en funcionamiento por agentes sin guardián, en nuestro estudio anterior

¿Por qué la allowlist no es una frontera de seguridad?

La allowlist compara el texto de un comando, y el mismo comando se puede escribir de muchas maneras. La documentación de Cursor lo dice claramente: "La allowlist es un mecanismo best-effort, no una frontera de seguridad. Un agente decidido o una prompt injection podrían saltársela." Así funciona hoy la comparación:

• Las entradas son prefijos y distinguen mayúsculas de minúsculas: git coincide con git status pero no con gitk. npm:install* separa el comando de un patrón de argumentos. No hay expresiones regulares.
• Una cadena se comprueba comando a comando: cd api && npm test | tail -20 solo se ejecuta automáticamente si cd, npm y tail están, cada uno, en la lista.
• Los comandos de la allowlist se ejecutan fuera del sandbox, así que una sola entrada amplia anula el sandbox para todo lo que empiece por ella.

El historial de bypasses es largo y público. En la época del YOLO mode, los comandos encadenados se colaban por las dos listas, y por eso Cursor eliminó la denylist en la 1.3. Desde entonces, Cursor ha publicado avisos de seguridad por un bypass de la allowlist mediante comillas invertidas y $(...) (CVE-2025-54131), por comandos internos del shell que se ejecutaban sin figurar en la lista (CVE-2026-22708) y por la ejecución de comandos con "Use AllowList" a través de una prompt injection desde un sitio web (CVE-2026-31854). En agosto de 2026, un usuario mostró dos formas de PowerShell que ejecutaban automáticamente comandos arbitrarios detrás de una entrada de la allowlist; el equipo de Cursor las trasladó internamente y, a finales de septiembre, dijo que los bloques de script ya piden siempre aprobación.

¿Por qué no me funciona el auto-run o la allowlist de Cursor?

Si Cursor te sigue pidiendo aprobación o parece ignorar tu allowlist, la causa suele ser una de estas:

• Un terminalAllowlist no vacío en ~/.cursor/permissions.json fija el modo en Allowlist y hace que Auto-review deje de estar disponible (según el equipo de Cursor, agosto de 2026).
• Un comando encadenado solo se ejecuta sin preguntar si todos sus comandos están en la lista.
• En Linux, el sandbox necesita un kernel 6.2 o posterior con user namespaces sin privilegios. Sin ellos, Cursor pregunta antes de cada comando.
• Un administrador del equipo ha impuesto el modo de ejecución o ha ocultado Run Everything.
• En el antiguo modo Run in Sandbox, la allowlist no se aplicaba en absoluto, porque "el sandbox está pensado para sustituir a la allowlist".

¿Protege .cursorignore tu .env en Cursor?

Solo en parte: un comando de terminal ejecutado fuera del sandbox puede seguir haciendo cat .env. .cursorignore oculta archivos a las herramientas de archivos del agente, a Tab y a las menciones con @, y la lista de ignorados por defecto de Cursor ya incluye .env*. Pero sobre lo demás la documentación es clara: "Las herramientas de terminal y de servidor MCP que usa Agent no pueden bloquear el acceso al código cubierto por .cursorignore." Dentro del sandbox, los archivos que figuran en .cursorignore no se pueden leer, así que añade tú mismo .env* a ese archivo en lugar de fiarte de la lista por defecto. Fuera del sandbox, es decir, en Run Everything, con comandos de la allowlist, con salidas del sandbox aprobadas y en Windows nativo, cat .env funciona.

Si un archivo no debe llegar nunca al modelo, sácalo del workspace o bloquea la propia lectura, que es lo que hacen las dos secciones siguientes. Si te haces la misma pregunta con Claude Code, consulta qué envía Claude Code a Anthropic.

¿Qué modo de ejecución de Cursor deberías usar?

En una máquina de desarrollo, hoy, esta es la configuración que usaríamos:

1. macOS o Linux: Auto-review con el sandbox activado. Limita la allowlist a comandos de solo lectura (git status, git diff, ls) y defínela en la interfaz de ajustes en lugar de en permissions.json si quieres que Auto-review siga disponible.
2. Cierra las lecturas y la red en ~/.cursor/sandbox.json (la frontera de lectura necesita Cursor 3.23 o posterior), y elige el ajuste de red que usa solo sandbox.json si no quieres los dominios por defecto de Cursor:

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

Si una toolchain necesita un archivo fuera del proyecto, añádelo a additionalReadPaths en lugar de volver a abrir todo el sistema. 3. Windows nativo: Allowlist con la lista vacía, o lleva el proyecto a WSL2 o a un dev container, donde sí existe el sandbox. 4. Equipos: impónlo de forma centralizada. La propia guía de hardening de Cursor recomienda configurar el modo de ejecución de la organización "en Auto-review (no en Run Everything)" con el sandbox activado, y distribuir los hooks desde el dashboard. Ten en cuenta que, en los grupos de una organización, gana el ajuste de sandbox más permisivo. 5. Run Everything solo donde la máquina sea desechable:

Contenedor o VM nuevos, clon desechableDentro, ningún token de larga duración ni credenciales cloudSalida de red limitada a los registros de paquetes que necesitasEntonces, y solo entonces, Run Everything

Los Cloud Agents de Cursor ya siguen este modelo: cada uno se ejecuta en su propia microVM y nunca pide aprobación, con el acceso a internet activado por defecto salvo que lo restrinjas.

¿Siguen funcionando los hooks de Cursor en Run Everything?

Sí, y eso los convierte en el único control que sobrevive a todos los modos de ejecución. Un hook es un script al que Cursor llama antes de una acción; puede responder deny, y la acción no se ejecuta. Cuando el 17 de octubre de 2026 alguien preguntó cómo proteger de los borrados recursivos una configuración en Run Everything, el equipo de Cursor respondió: "La principal salvaguarda en ese caso es el hook."

Un hook mínimo a nivel de usuario que rechaza los borrados recursivos en todos los shells que usa Cursor. En ~/.cursor/hooks.json:

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

Y ~/.cursor/hooks/block-recursive-delete.mjs (las rutas de los hooks de usuario se resuelven desde ~/.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" }));
}

Tres límites que conviene conocer antes de confiar en él, todos según el equipo de Cursor:

• Solo se aplica deny. En marzo de 2026 el equipo escribió que "los hooks solo aplican el permiso deny. Tanto allow como ask se ignoran, básicamente". Por eso el script responde allow para todo lo demás: deja la decisión a tu modo de ejecución. No cuentes con ask para que Cursor vuelva a pedirte confirmación.
• Una condición de carrera conocida puede hacer que se pierda un deny. En julio de 2026 el equipo confirmó que una condición de carrera puede anular el deny de un hook preToolUse, con lo que el comando se ejecuta, y añadió: "por favor, no confíes solo en un hook deny como bloqueo definitivo". Seguía abierto en septiembre.
• Los hooks no ven el modo de ejecución. El script no puede endurecerse solo cuando estás en Run Everything.

Y un límite del propio método: un patrón es un cable trampa, no una frontera. Detecta las formas que dejaste escritas, se le escapa un borrado escondido en un archivo de script o escrito de otra manera, y también salta con comandos inofensivos: lo probamos con un conjunto de comandos de ejemplo y rechazó rm -rf node_modules y git rm -r --cached junto con los borrados masivos de verdad. Mantén el sandbox debajo.

La brecha que ningún modo de ejecución cierra

Todos los ajustes de esta guía controlan lo que Cursor puede ejecutar. Ninguno controla lo que Cursor escribe, y la mayor parte del riesgo del código escrito por IA está en el diff, no en el terminal. Auto-review dejará sin pestañear que el agente guarde un endpoint sin comprobación de autorización, un gestor de reembolsos sin tope o una consulta construida concatenando cadenas, porque nada de eso es un comando. Son fallos de lógica de negocio, y un ajuste del terminal no puede verlos. Además, los agentes empiezan cada sesión sin las reglas de tu equipo, salvo que algo se las ponga delante en el momento en que escriben.

Esa es la capa que VibeDefend añade dentro de Cursor. Se instala en la máquina con un solo comando: sirve al agente tus reglas de negocio y de seguridad mientras escribe, revisa el diff antes del commit y ejecuta sus guardianes como hook de Cursor antes de cada llamada a herramienta, sea cual sea el modo de ejecución. Por defecto rechazan las lecturas de archivos .env, claves SSH y credenciales cloud, rm -rf sobre un directorio raíz o personal, los force-push, las sentencias DROP y las descargas redirigidas a un shell. El guardián es el mismo tipo de cable trampa que el hook de arriba, mantenido por nosotros y con los mismos límites: en nuestro estudio controlado del 24 de agosto de 2026 comprobó 1.769 comandos de shell y rechazó diecisiete, con una captura real, tres aplicaciones correctas de la política y trece falsos positivos. En el propio código, la configuración con la capa implementó al pie de la letra 57 de 64 detalles de regla evaluados (89 %), frente a 7 de 55 (13 %) con un archivo de reglas mantenido a mano y 8 de 65 (12 %) sin nada.

Si usas Cursor en Run Everything a propósito, en un contenedor y con un guardián en el hook, tienes una configuración defendible. Si lo usas así en tu portátil porque te molestaban las confirmaciones, lee nuestra guía de seguridad de Cursor, compara con lo que quita el --yolo de Codex y con el --dangerously-skip-permissions de Claude Code, y luego hablamos.

Preguntas frecuentes

¿Cursor ha quitado el YOLO mode?

No. El YOLO mode pasó a llamarse Auto-run en marzo de 2025. Su comportamiento de "ejecutarlo todo sin preguntar" es ahora el modo Run Everything, en Settings > Agents > Approvals & Execution. Desde Cursor 3.6, el modo por defecto es Auto-review.

¿Cómo activo el YOLO mode en Cursor?

Abre Settings > Agents > Approvals & Execution y elige Run Everything. En la CLI de Cursor, usa --yolo (alias --force) o /auto-run. Si la opción no aparece, lo más probable es que un administrador del equipo la haya desactivado, o que tu versión de Cursor sea anterior a los modos actuales.

¿Qué es Auto-review en Cursor?

Auto-review es el modo de ejecución por defecto de Cursor desde la versión 3.6 (29 de mayo de 2026). Las llamadas de la allowlist se ejecutan de inmediato, los comandos de shell que admiten sandbox se ejecutan dentro de él, y un modelo clasificador decide sobre el resto: lo permite, lo redirige o te pregunta. Cubre las llamadas de shell, MCP y Fetch. La documentación de Cursor dice que no es una frontera de seguridad.

¿En qué se diferencian Auto-review y Run Everything?

Auto-review ejecuta las llamadas de la allowlist, ejecuta los comandos de shell en el sandbox cuando puede y envía todo lo demás a un modelo clasificador que puede permitirlo, sugerir otro enfoque o preguntarte. Run Everything ejecuta todas las llamadas a herramientas sin sandbox y sin clasificador.

¿Es seguro usar Run Everything?

Solo en una máquina desechable: un contenedor o una VM nuevos, sin credenciales de larga duración y con la red limitada. En un puesto de trabajo deja que el agente actúe con tu identidad, y en el foro de Cursor hay casos de discos enteros borrados en este modo en octubre de 2026.

¿Qué bloquea el sandbox de Cursor?

En macOS y Linux limita la escritura de los comandos de shell al workspace, bloquea la red salvo los dominios que permitan tus ajustes y protege archivos como .cursor/*.json y .git/hooks. Por defecto no restringe las lecturas fuera del workspace; Cursor 3.23 añadió una frontera de lectura Workspace. A fecha de octubre de 2026, los shells de Windows nativo no tienen sandbox.

¿Por qué Cursor ignora mi allowlist o no me funciona el auto-run?

Las causas habituales: un terminalAllowlist no vacío en ~/.cursor/permissions.json fija el modo en Allowlist y desactiva Auto-review; un comando encadenado solo se ejecuta automáticamente si todos sus comandos están en la allowlist; en Linux, un kernel anterior a la 6.2, o que no permite user namespaces sin privilegios, hace que Cursor pregunte antes de cada comando; y en el antiguo modo Run in Sandbox la allowlist no se aplicaba en absoluto.

¿El auto-run funciona también con las herramientas MCP?

Sí. Las llamadas a herramientas MCP siguen los mismos modos de ejecución que los comandos de terminal. En Auto-review, las herramientas MCP de la allowlist (entradas server:tool, se admiten comodines) se ejecutan de inmediato y el resto pasa al clasificador. En Run Everything se ejecutan todas.

¿Sirve .cursorignore para que Cursor no lea mi .env?

Desde el terminal, no. .cursorignore oculta archivos a las herramientas de archivos del agente y a las menciones, y .env* está en la lista de ignorados por defecto de Cursor, pero la documentación de Cursor indica que las herramientas de terminal y MCP no pueden bloquear el acceso a los archivos ignorados. Un comando dentro del sandbox no puede leer los archivos que figuran en .cursorignore; un comando de la allowlist, Run Everything o un shell de Windows nativo sí pueden.