Codex Automations para tareas largas: desencadenantes programados, heartbeats y trabajo de varios días

Si le pasas a Codex comprobaciones repetitivas, seguimiento de PR, revisiones después de deploy y triage de varios días, la primera pregunta no es si se puede automatizar. Es qué tipo de tarea merece automatización y cómo hacerlo. Automations no convierte a Codex en un agente de fondo siempre encendido. Lo trae de vuelta en el momento correcto, dentro del límite correcto, para hacer una sola cosa bien definida.

1. Primero juzga si la tarea debe automatizarse

1.1 standalone/project automation: trabajos de fondo independientes

Standalone automation y project automation son trabajos de fondo independientes. La diferencia está en el alcance. Standalone no está atado a un proyecto concreto; project automation sí está vinculada a una ruta de proyecto, por lo que encaja mejor con trabajo recurrente alrededor de un repositorio fijo.

Cada disparador inicia una ejecución nueva. Al terminar, el resultado va a inbox o triage; si no hay nada nuevo, puede archivarse automáticamente. Los usos típicos son comprobaciones semanales de dependencias, triage diario de issues y revisiones programadas tras un despliegue.

La limitación clave es el entorno local: la máquina que ejecuta Codex debe seguir encendida, la app debe seguir corriendo y la ruta del proyecto debe existir. Si la máquina se suspende, se apaga o la app se cierra, no sigue. No es la capa adecuada para hosting sin supervisión a largo plazo.

1.2 thread automation (heartbeat): wakeups periódicos en el mismo hilo

Thread automation es un wakeup periódico tipo heartbeat unido al hilo de conversación actual. La idea central es conservar el contexto: cada vez que despierta, continúa la misma conversación en vez de crear una ejecución nueva e independiente.

Es una buena opción para checks de logs tras un deploy, seguimiento de varios días y triage continuo. Por ejemplo, puedes pedirle a Codex que revise los logs de despliegue cada 10 minutos, que solo avise cuando vea error o éxito, y que permanezca en silencio en caso contrario. Ese tipo de trabajo necesita continuidad de contexto, así que standalone automation no encaja bien.

El heartbeat no es un daemon permanente ni un forever loop. Es un ritmo de despertar -> revisar -> reportar -> esperar. Si la app se pausa o se cierra, el heartbeat también se detiene.

1.3 Tabla comparativa

Dimensión	standalone/project automation	thread automation (heartbeat)
Ubicación de ejecución	Hilo de fondo independiente	Hilo de conversación actual
Conservación del contexto	Contexto nuevo en cada ejecución	Conserva el contexto de la sesión actual
Casos de uso adecuados	Tareas repetitivas independientes, triage de issues, comprobaciones de dependencias	Seguimiento de tareas largas, triage continuo, logs tras deploy, trabajo de varios días
Dependencias	La app local / la máquina / la ruta del proyecto deben existir	El hilo actual debe seguir vinculado
Superficie de resultados	inbox / triage, archivado automático si no hay hallazgos	Ventana de conversación actual
Mecanismo de parada	Desactivar la automatización	Pausar o cerrar la app

La decisión es sencilla: ¿la tarea necesita conservar contexto? Si sí, usa thread automation. ¿Está atada a un proyecto concreto? Si sí, usa project automation; si no, standalone automation.

2. Qué tareas encajan con Automations

No todas las tareas repetitivas merecen Automations. Primero mira la forma de la tarea.

2.1 Rasgos de las tareas adecuadas

Las tareas adecuadas para Automations suelen compartir tres rasgos: repetición alta, reglas claras y salida verificable.

El trabajo muy repetitivo aparece en un ritmo fijo y busca prácticamente el mismo resultado cada vez. Las comprobaciones semanales de dependencias, el triage diario de issues y las revisiones fijas tras deploy son buenos ejemplos. El alcance de inspección, los criterios de decisión y el formato de salida pueden definirse antes.

Las tareas basadas en reglas se convierten muy bien en prompt. Por ejemplo: “Revisa las versiones en package.json, lista los paquetes que tengan versiones nuevas y recomienda un orden de actualización.” Los criterios de juicio se mantienen estables, así que no hace falta repetirlos manualmente.

La salida verificable también importa. Una buena automatización debe volver a inbox / triage, archivarse sola cuando no haya nada que hacer y mostrar con claridad el siguiente paso cuando encuentre algo. Así sabes que realmente ahorra tiempo en vez de mover ruido a otro sitio.

2.2 Rasgos de las tareas que no encajan

Las tareas que no encajan con Automations suelen tener cuatro rasgos: necesitan juicio humano frecuente, dependen de un estado externo que cambia rápido, el prompt aún no es estable, o requieren hosting sin supervisión a largo plazo.

Las tareas que requieren juicio humano frecuente suelen tener fronteras difusas. Las decisiones de arquitectura, la caza de bugs complejos y los trade-offs situacionales necesitan adaptación al caso, así que encajan mal con una automatización fija.

Las tareas que dependen de un estado externo que cambia rápido también requieren cautela. El monitoreo en tiempo real de un servicio de producción, por ejemplo, cambia demasiado deprisa y encaja mejor con herramientas de observabilidad especializadas que con Automations.

No automatices tampoco un prompt que aún no se ha probado. Hazlo correr manualmente unas cuantas veces, estabiliza reglas, alcance y salida, y solo entonces pásalo a automatización.

El hosting sin supervisión a largo plazo no es la capa correcta para project-scoped automation. Depende de la app local, la máquina y la ruta del proyecto. Si la máquina desaparece, la automatización se detiene. No es una solución cloud.

2.3 Tabla de encaje

Tipo de tarea	¿Encaja?	Motivo	Enfoque recomendado
Comprobaciones semanales de dependencias	Sí	Repetitiva, basada en reglas, verificable	standalone automation o project automation
Triage diario de issues	Sí	Puede ir a inbox, puede archivarse automáticamente, el prompt es estable	standalone automation o thread heartbeat
Checks de logs tras deploy	Sí	Mismo hilo, el contexto importa	thread automation
Decisiones de arquitectura	No	Necesita juicio humano frecuente, fronteras difusas	conversación manual
Caza de bugs complejos	No	Necesita adaptación situacional	conversación manual
Monitoreo en tiempo real	No	El estado externo cambia demasiado rápido	herramientas de observabilidad especializadas
Hosting sin supervisión a largo plazo	No	project-scoped automation depende del entorno local	enfoque CI o cloud
Flujos de automatización no probados	No	Prompt inestable, ejecuciones manuales inconsistentes	estabilizar manualmente primero

El flujo de decisión es simple: primero verifica que el prompt sea estable, luego decide si la tarea necesita conservar contexto y, por último, si hace falta hosting cloud duradero.

3. Crear tu primera standalone/project automation

3.1 Flujo de creación

1. Escribe primero la tarea con claridad. Define alcance, entrada, salida, criterios de éxito y condiciones de parada.
2. Elige el tipo de automatización. El trabajo repetitivo independiente va a standalone; el trabajo repetitivo alrededor de un repositorio fijo va a project automation.
3. Elige la ubicación de ejecución. En repos Git, empieza con un worktree para no molestar al workspace actual.
4. Define la frecuencia. Las tareas por minuto necesitan condiciones de parada explícitas para no despertarse sin fin.
5. Haz primero algunos ciclos de prueba. Cuando la salida sea estable, sube a la frecuencia real.

3.2 Cómo elegir entre worktree y local project

Ubicación de ejecución	Aislamiento	Casos adecuados	Riesgo
worktree	Los cambios quedan aislados del directorio actual	Tareas que editan archivos, escriben código o sugieren PR	Los errores suelen quedar dentro del worktree y se descartan fácilmente
local project	Sin aislamiento; ejecuta directamente en el directorio actual	Comprobaciones de solo lectura, generación de informes, triage	Puede afectar archivos que estás editando

En repos Git, las tareas de modificación deben empezar en un worktree. Usa local project solo cuando la tarea sea explícitamente de solo lectura, inspección o confirmación.

4. Crear thread automation (heartbeat)

4.1 Flujo de creación

1. Verifica primero que el hilo actual ya está gestionando una tarea larga.
2. Luego vincula la thread automation a ese hilo.
3. Escribe exactamente qué debe revisar en cada wakeup, cuándo debe reportar y cuándo debe permanecer en silencio.
4. Define condiciones de parada: éxito, fallo, timeout o un máximo de rondas.
5. Empieza con frecuencia baja y comprueba que no haga spam antes de pasar al ritmo final.

4.2 Ejemplo de prompt heartbeat

Revisa los logs de despliegue cada 10 minutos y reporta solo en estos casos:

1. Aparece una señal de error (contiene "error", "failed" o "exception")
2. Aparece una señal de finalización (contiene "deployed", "success" o "completed")
3. Pasan 30 minutos y aún no termina

Formato del reporte:
- Status: [in progress / success / failure]
- Extracto clave del log: [hasta 3 líneas]
- Siguiente paso: [si lo hay]

Permanece en silencio cuando no haya cambios.

Este prompt deja explícitos el alcance de revisión, el límite de salida y las condiciones de parada. No hace falta repetir “revisión completada” en cada wakeup, ni convertir la ausencia de cambios en ruido.

5. Seguridad: sandbox, approval policy y gobernanza de equipo

5.1 Ajustes de sandbox y approval policy

Las Automations ejecutan por defecto dentro de una sandbox. La sandbox decide qué archivos puede tocar, si puede cruzar límites y si hace falta aprobación adicional. Para la automatización de fondo, cuanto más pequeño sea el límite por defecto, mejor.

Modo sandbox	Alcance de permisos	Adecuado para	Nivel de riesgo
read-only	Solo lectura, sin escritura	Inspección y análisis puros	Bajo
workspace-write	Lectura/escritura en el workspace; las acciones externas siguen requiriendo aprobación	Automatizaciones diarias, cambios de archivos, sugerencias de PR	Medio
danger-full-access	Acceso al sistema sin restricciones	Entornos aislados o tareas muy fiables	Alto

La approval policy controla si el agente debe pedir permiso cuando encuentra una acción más arriesgada.

approval policy	Comportamiento	Caso de uso
on-request	Pide permisos superiores cuando hace falta	Un poco de autonomía, pero con revisión humana
never	Ejecuta automáticamente sin preguntar	Scripts de automatización o entornos no interactivos

La recomendación por defecto debería ser workspace-write + rules/allowlist, no full access + unattended. Lo segundo es demasiado amplio cuando algo sale mal.

5.2 Consejo de gobernanza

Los equipos pueden fijar sandbox y approval en requirements.toml para que nadie conceda demasiados permisos por accidente.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

El objetivo no es bloquearlo todo. El objetivo es mantener el límite por defecto estrecho y ampliarlo solo cuando la tarea lo necesite de verdad.

6. Tres plantillas de automatización listas para usar

6.1 Revisión semanal de dependencias

• Frecuencia de disparo: una vez por semana
• Ubicación de ejecución: prioriza worktree en repos Git
• Salida exitosa: lista de dependencias actualizables y prioridades sugeridas
• Condición de parada: si no hay nada que actualizar, limita el resultado a una respuesta breve
• Límite de permisos: solo lectura o reporte ligero

6.2 Seguimiento heartbeat tras deploy

• Frecuencia de disparo: cada 10 minutos, hasta 30 minutos
• Ubicación de ejecución: thread automation
• Salida exitosa: resumen breve de éxito, fallo o timeout
• Condición de parada: señal de éxito, señal de fallo o timeout
• Límite de permisos: solo leer logs, no tocar producción

6.3 Triage diario de issues / PR

• Frecuencia de disparo: una vez al día
• Ubicación de ejecución: standalone automation o thread heartbeat
• Salida exitosa: mover a inbox lo que requiera atención humana
• Condición de parada: permanecer en silencio cuando no haya nada nuevo
• Límite de permisos: por defecto workspace-write; evitar full access

7. Si la automatización falla, revisa primero estas 6 cosas

1. ¿La app de Codex sigue corriendo y la máquina está despierta?
2. ¿La ruta del proyecto sigue existiendo o se movió/eliminó el worktree?
3. ¿La sandbox está bloqueando escritura o red?
4. ¿La thread automation realmente necesita conservar contexto?
5. ¿El worktree se ha acumulado demasiado y necesita limpieza?
6. ¿El prompt dice claramente cuándo parar y cuándo reportar?

8. Checklist de FAQ

8.1 ¿Automations es una tarea programada o un agente que corre siempre?

Se parece más a un trabajo en segundo plano programado o despertado periódicamente. En cada wakeup comprueba, trabaja, informa y vuelve a esperar. No es un forever loop.

8.2 ¿Cuál es la diferencia entre standalone/project y thread automation?

Standalone/project automation es una ejecución de fondo independiente que empieza de nuevo cada vez y cuyo resultado va a inbox / triage. Thread automation es un heartbeat sobre el mismo hilo y conserva el contexto de la conversación actual.

8.3 ¿Qué tareas encajan con Automations y cuáles no?

Las adecuadas son repetitivas, basadas en reglas y verificables. Las inadecuadas son las que requieren juicio humano frecuente, dependen de un estado externo que cambia rápido o tienen prompts inestables.

8.4 ¿Cómo elijo entre worktree y local project?

Para todo lo que pueda modificar archivos, prioriza worktree. Usa local project solo para comprobaciones de lectura y tareas tipo informe.

8.5 ¿Seguirá funcionando si cierro la app o el ordenador duerme?

No. La automatización ligada al proyecto depende de la app local, la máquina y la ruta del proyecto. Si la app se cierra o la máquina duerme, se detiene.

8.6 ¿Cuándo debo usar Computer Use?

Solo cuando sea necesario manejar directamente una GUI y no exista API ni interfaz web. Si el código normal basta, normalmente no merece la pena.

8.7 ¿Cómo controlo el coste y la frecuencia?

Mantén la frecuencia solo tan alta como necesites, revisa el estado con /status, define condiciones de parada para cada automatización y evita el polling excesivo.

9. Resumen

Computer Use, el navegador integrado y Automations resuelven capas distintas del mismo problema. Automations sirve para dar a Codex trabajo estable, verificable y repetitivo en segundo plano; thread automation sirve para seguimiento de tareas largas de varios días; worktree y sandbox sirven para mantener el riesgo bajo control.

El orden más seguro es siempre el mismo: primero juzgar si la tarea debe automatizarse, luego elegir ubicación de ejecución y permisos, y solo después ajustar la frecuencia. Primero estabiliza el proceso humano, y después deja que Codex lo mantenga un poco más tiempo.