Cursor 3.24 pide confirmacion antes de borrados peligrosos, pero Run Everything guarda silencio

El fallo mas desagradable de un agente no es generar codigo defectuoso, sino ejecutar un comando que borra en silencio lo que no debe. Basta un rm -rf desafortunado o un comodin que se expanda mas de lo previsto para que desaparezca la mitad del proyecto. En sus versiones recientes, Cursor ha reducido parte de este riesgo, pero solo si el propio usuario no desactiva la proteccion.

Que cambio en la version 3.24

Segun las notas de lanzamiento de Cursor, desde la version 3.24 el modo Auto-review pide permiso antes de realizar borrados arriesgados. Esto incluye cuatro casos: borrado recursivo, borrado forzado, borrado mediante comodines y situaciones en las que el destino real puede no coincidir con el especificado en el comando.

El ultimo caso es el mas traicionero. Supongamos que el agente va a limpiar la carpeta de compilacion, pero la ruta se construye a partir de una variable que esta vacia o apunta a un nivel superior. El comando parece inofensivo, pero puede borrar algo completamente distinto. Ahora Cursor se detiene en ese momento y espera la confirmacion del usuario.

Donde no hay proteccion

El modo Run Everything funciona de otra manera. Segun la documentacion de Cursor, el agente ejecuta todos los comandos consecutivamente y no existe ni un sandbox ni un clasificador de riesgos. Las restricciones solo aparecen si el propio usuario las define en permissions.json.

En esencia, se trata de un unico interruptor. Mientras este activado, la pregunta «¿esta seguro?» no aparecera en ningun caso, ni siquiera ante un comando que elimina un directorio. Puede resultar practico para experimentos rapidos en un repositorio desechable. En un proyecto de trabajo sin copia de seguridad, equivale a apostar a que el agente no se equivocara.

Si aun asi se necesita velocidad, es mas sensato definir limites en permissions.json—especificando que puede ejecutar el agente y que no—que desactivar por completo la proteccion. De ese modo, el funcionamiento sin preguntas al menos no se extiende a las operaciones peligrosas.

Un habito sencillo: hacer commit antes de modificar

El autor de la publicacion recomienda dos cosas. La primera es mantener Auto-review como modo predeterminado. La segunda es hacer un commit antes de encargar al agente un cambio importante.

La segunda recomendacion es importante por la forma en que funcionan los checkpoints de Cursor. Se almacenan localmente y por separado de git. Su objetivo es revertir los cambios del agente, no mantener el historial del proyecto. El historial permanente solo existe en git. Por eso, un checkpoint no puede considerarse un sustituto de un commit: si el propio directorio o el entorno de trabajo resultan dañados, el unico punto de restauracion fiable estara en el repositorio.

En la practica, el procedimiento es el siguiente:

• antes de asignar una tarea importante al agente, guarde el estado actual mediante un commit;
• mantenga Auto-review activado, especialmente en proyectos con datos importantes;
• si utiliza Run Everything, limite sus permisos en permissions.json;
• considere la restauracion mediante checkpoints una comodidad, no un seguro.

Limitaciones y contexto

Conviene ser claros: esto no es un estudio ni un benchmark, sino una nota breve basada en las notas de lanzamiento y la documentacion. La publicacion no explica como determina exactamente Cursor que un borrado es «arriesgado» ni con que fiabilidad detecta todas sus variantes. Por tanto, tampoco conviene confiar por completo en Auto-review: reduce el riesgo, pero no elimina la necesidad de mantener una disciplina de commits.

La publicacion es parcialmente promocional: da continuidad a la serie animada «Vibe Coder and Bug», cuyo quinto episodio esta dedicado a este tema, e invita a unirse al club NeyroMakers. El autor tambien desglosa el coste del episodio: unos $5 a precios de API, equivalentes al 0,5% del limite semanal de la suscripcion, mas alrededor de 9 centavos por la locucion en ElevenLabs. Claude escribio el guion y la animacion en Claude Code.

Conclusion

Si trabaja con agentes en Cursor, dedique un minuto a comprobar en que modo se ejecutan. Si aparece Run Everything y no hay restricciones en permissions.json, en la practica ha autorizado al agente a hacer cualquier cosa. Vuelva a Auto-review y acostumbrese a hacer un commit antes de las tareas importantes. Cuesta muy poco y protege contra la categoria de fallos mas desagradable.