Hooks en Cursor para proteger tu código

Los hooks en Cursor son una capa de control que te permite observar, validar y bloquear acciones del agente antes de que toquen tu código. Si estás automatizando flujos con IA y quieres evitar que un subagente borre archivos críticos o rompa tipos, esta pieza es clave para construir software agéntico más seguro.

En el flujo de trabajo se combinan dos ideas: primero configurar hooks automáticos como guardianes, y luego ejecutar el spec del login con usuario y contraseña sabiendo que esos guardianes están vigilando cada turno del agente.

Qué son los hooks y cuándo se ejecutan

Un hook es una herramienta que se engancha al ciclo de vida del agente para observar, controlar y ampliar su comportamiento [00:12].

Piénsalo como un vigilante silencioso que corre en background mientras el agente trabaja. No interrumpe la creatividad del modelo, pero sí levanta la mano cuando algo se sale de los rieles.

¿Qué hace un hook en Cursor? Ejecuta un comando de bash en momentos específicos del ciclo agéntico, como después de una edición o antes de correr un comando en la terminal, para validar o bloquear acciones.

Los casos de uso más comunes son:

• Ejecutar formatters después de las ediciones.
• Agregar analíticas para eventos del agente.
• Escanear el código en busca de información personal o secretos.
• Restringir operaciones riesgosas en la base de datos, como deletes.

En qué puntos del ciclo agéntico corre un hook

Un hook puede dispararse en varios momentos clave: cuando una sesión empieza, cuando se llama una tool, cuando un subagente arranca o antes de la ejecución de una shell [00:38]. En todos esos puntos tienes la oportunidad de meter una validación.

Cómo configurar hooks automáticos en .cursor/hooks

Cursor soporta hooks dentro de la carpeta .cursor, la misma donde ya viven las reglas y el MCP [01:05]. Aquí se definen en un archivo hooks.json que apunta a comandos de bash.

Para este proyecto se configuraron dos guardianes con propósitos muy distintos pero complementarios.

Hook de stop para validar tipos y tests

Este hook se ejecuta al terminar cada turno del agente [01:20]. Corre el check types y los tests del evaluador en el dominio, y si algo falla devuelve un mensaje de error en la salida.

La idea es que el agente no cierre un turno con el proyecto roto. Si los tipos no compilan o los tests fallan, el propio agente lo sabe y puede reintentar. Se configuró un loop limit de 3 reintentos antes de marcar el error en la terminal [02:35].

Hook before shell para bloquear comandos destructivos

El segundo hook corre antes de ejecutar cualquier comando en la shell [01:35]. Su misión es bloquear comandos peligrosos como rm -rf sobre carpetas, incluyendo node_modules y dist.

¿Por qué bloquear rm -rf con un hook? Porque un agente o subagente puede tomar decisiones más allá de lo que le pediste. Un hook before shell intercepta esos comandos antes de que toquen tu sistema de archivos.

Ambos hooks son, en el fondo, scripts de bash corriendo en background. Esa simpleza es su fuerza: puedes auditarlos, versionarlos y adaptarlos a los caminos críticos de tu proyecto.

Cómo implementar el spec del login usando los hooks

Con los guardianes en su lugar, el siguiente paso fue pedirle al agente que implementara el spec del login referenciándolo directamente en el prompt [03:35]. La instrucción incluía usar un usuario demo, construir la pantalla de login, consumir el endpoint, validar por token y trabajar bajo la vigilancia de los hooks.

El agente configuró la autenticación con un middleware, aplicó los tests, construyó el login, el dashboard, los proxies y usó el seed para crear el usuario. Cada vez que terminaba un turno, el hook de stop disparaba el type check automáticamente [04:05].

Cookies firmadas y autenticación stateless

Una nota técnica que dejó el flujo: las cookies firmadas son stateless, por lo que al borrar la cookie se invalida el token de forma inmediata [04:30]. No hay estado guardado en el servidor que mantener sincronizado.

Para probar el resultado, el agente levantó el proyecto con la web en el puerto 3000 y la API en el puerto 3001 [04:50]. Al entrar a localhost:3000/dashboard, el middleware redirige al login, donde funcionan las credenciales de usuario admin y contraseña demo123.

Dónde deberían vivir los hooks en tu proceso

La tarea que queda abierta es leer la documentación oficial de hooks y pensar dónde encajan mejor en tu flujo. ¿Antes de una migración? ¿Después de cada edición en un archivo crítico? ¿Escaneando secrets antes de un commit?

Cuéntame en los comentarios qué hook implementarías primero en tu proyecto y qué acción riesgosa te gustaría bloquear.