Automatización y CI/CD: cómo hacer que Codex trabaje de forma autónoma en su ausencia

📚 Navegación de la serie: El artículo anterior 〔26 Integración con Git y GitHub〕 le enseñó cómo hacer que Codex le ayude localmente a gestionar ramas, escribir confirmaciones y abrir PR, todo mientras usted está en la computadora y el sistema le acompaña. Este artículo se enfoca en el funcionamiento "sin supervisión": una vez configurado, Codex revisará automáticamente cada PR cuando se abra, enviará parches de corrección si la CI falla y le proporcionará un resumen diario de las confirmaciones del día anterior, todo sin requerir su atención constante. El siguiente artículo 〔28 Modo no interactivo codex exec〕 detallará el comando principal que hace posible todo esto.

Suele decirse que "el mayor valor de una herramienta de programación con IA es acompañarle en la programación en pareja, conversando mientras escribe". Pero, para ser honestos, eso es solo la mitad de la verdad.

Tras usar Codex durante más de medio año, he comprobado que el escenario donde realmente libera productividad es cuando usted no está presente. En la programación en pareja, usted debe estar frente a la pantalla, supervisar y revisar cada paso; básicamente es un esquema de "usted dirige y el sistema asiste", y en cuanto se retira, el trabajo se detiene. Sin embargo, en el desarrollo de software abundan las tareas rutinarias y repetitivas: revisar rápidamente cada PR, analizar fallos en la CI a medianoche o estructurar un resumen de cambios semanal para la dirección. Estas tareas tienen algo en común: son repetitivas y siguen un patrón, pero nadie quiere realizarlas constantemente.

Estas tareas representan el escenario ideal para la automatización. Al integrar Codex en sus flujos de CI o programarlo como tareas periódicas, pasa de ser "el asistente que debe supervisar" a "el centinela que patrulla su repositorio mientras duerme". Este artículo se enfoca en este proceso mediante dos flujos: integrar Codex en GitHub Actions (en la infraestructura de CI/CD) y configurar tareas periódicas en segundo plano usando Automations de la App de escritorio (en su máquina local). Al configurar ambos, su repositorio contará con una capa de automatización activa las 24 horas del día.

Al terminar de leer este artículo, obtendrás:

• Identificación clara de ambos flujos de automatización: openai/codex-action en la CI/CD y Automations en segundo plano desde la App de escritorio.
• Un archivo YAML mínimo y funcional de GitHub Actions para configurar la revisión automática de sus PR.
• Explicación de los parámetros de entrada clave de codex-action (prompt-file, sandbox, safety-strategy, final-message...) contrastados con la documentación oficial.
• Cómo configurar de forma segura la OpenAI key en GitHub y la línea de seguridad específica sobre variables de entorno.
• Cómo configurar Automations en la App de escritorio, dónde revisar los resultados de las tareas programadas y si se ejecutan de forma local o en un worktree.
• Una guía práctica para automatizar un "resumen periódico de actividades" con resultados validados.

⚠️ Cualquier comando, entrada de action, configuración o valor predeterminado mencionado en este documento se basa en la documentación oficial de Codex (GitHub Action / Automations). Los números de versión o nombres de modelos pueden cambiar con el tiempo; consulte los detalles en su entorno local al momento de la implementación.

---

01 Distinguir dos flujos de automatización

Como mapa inicial para este artículo, la automatización con Codex se divide en dos flujos que se ejecutan en entornos diferentes y atienden distintos propósitos:

• Flujo 1: GitHub Actions (openai/codex-action). Se ejecuta en los runners administrados por GitHub (máquinas en la nube) y se activa mediante eventos del repositorio (apertura de PR, envío de código, fallos de CI). Corresponde al flujo de CI/CD (Integración y Entrega Continuas) y gestiona tareas vinculadas al trabajo colaborativo del equipo: revisión de PR, control de calidad y corrección de fallos de CI.
• Flujo 2: Automations (Tareas automatizadas). Se ejecuta localmente en su máquina con la App de escritorio de Codex activa y se desencadena por tiempo (programación periódica o cron). Gestiona tareas asociadas a su flujo de trabajo personal: estructuración de resúmenes diarios, revisiones periódicas de proyectos o supervisión de tareas de larga duración.

Diferenciar estos flujos evita el error de aplicar una solución al entorno equivocado, como configurar un flujo Automation en la App de escritorio para revisar automáticamente los PR del equipo (el cual dejaría de funcionar si apaga su computadora) o escribir flujos en GitHub Actions para recibir recordatorios locales de cambios en su máquina.

Analogía: El guardia de seguridad y el mayordomo. GitHub Actions funciona como el guardia de seguridad del edificio de la empresa (su repositorio remoto). Él no vive en su casa, sino en la caseta de vigilancia (el runner de GitHub); cuando hay actividad en el edificio (un nuevo PR o una alerta de CI), realiza su ronda y aplica las reglas para todo el equipo. Automations actúa como el mayordomo de su hogar (su máquina local). Ejecuta sus tareas en la residencia bajo una programación personalizada (por ejemplo, organizar la correspondencia recibida a las 9:00 AM) y no operará si la casa está cerrada (computadora apagada). El guardia gestiona los flujos del edificio común; el mayordomo atiende sus asuntos personales de forma programada.

Los casos de uso recomendados para cada flujo son:

Característica	GitHub Actions (codex-action)	Automations (App de escritorio)
Entorno de ejecución	Runners en la nube de GitHub	Su máquina con la App de escritorio activa
Activador	Eventos del repositorio (PR, push, CI completada)	Tiempo (cron o intervalos programados)
Intervención humana	No requiere, se ejecuta en la nube	Requiere que la computadora y la App estén activas
Casos de uso comunes	Revisión de PR, control de calidad, corrección de CI	Resúmenes diarios, auditorías de código, supervisión
Ámbito	CI/CD (flujos de trabajo colaborativos)	Administración de tareas personales

Este artículo analizará primero GitHub Actions (secciones 02-05), luego Automations (sección 06) y concluirá con un ejercicio práctico de implementación (sección 07).

💡 Resumen en una frase: La automatización se divide en dos flujos: GitHub Actions se ejecuta en la nube, responde a eventos del repositorio y gestiona tareas colaborativas (guardia); Automations se ejecuta localmente, se programa por tiempo y atiende tareas personales (mayordomo).

En el siguiente esquema se representa el flujo de GitHub Actions:

Este diagrama ilustra la arquitectura del flujo: un evento en el repositorio (push, PR o cron) activa el workflow de GitHub Actions, el cual ejecuta el comando codex exec en modo no interactivo sobre el runner para realizar revisiones, aplicar cambios o generar reportes automáticos.

---

02 Qué es GitHub Action: el empaquetado integrado para usar codex exec en la CI

Analicemos detalladamente el primer flujo. openai/codex-action es una GitHub Action oficial provista por OpenAI que instala el Codex CLI en el runner de la CI, configura los agentes proxy para la comunicación con Responses API y ejecuta el comando codex exec bajo los permisos que usted asigne. Esto evita tener que gestionar manualmente la instalación y autenticación del CLI en la máquina virtual.

El comando subyacente es codex exec, el cual representa el modo no interactivo (non-interactive mode) de Codex. Este modo no despliega la interfaz de usuario en pantalla; recibe un prompt de entrada, realiza la tarea y finaliza devolviendo el resultado, lo cual es ideal para scripts y entornos de CI. Tenga en cuenta que GitHub Actions ejecuta codex exec en la capa inferior, envolviendo la instalación, autenticación y ejecución en un contenedor listo para usar en la nube (el comando se detalla en el artículo [28]).

La documentación oficial define la herramienta como sigue:

Use Codex GitHub Action (openai/codex-action@v1) para ejecutar Codex, aplicar parches o publicar comentarios de revisión en workflows de GitHub Actions. La acción instala el Codex CLI, inicia el proxy de Responses API al proveer una API key y ejecuta codex exec con los privilegios configurados.

Analogía: El maletín de herramientas listo para llevar. Para realizar un trabajo en las instalaciones de un cliente (el runner de GitHub), puede optar por llevar herramientas individuales y ensamblarlas en el lugar (instalar Codex manualmente vía npm, configurar credenciales con codex login y exportar variables de entorno en el runner) o llevar un maletín integrado provisto por el fabricante (codex-action) que al abrirse ya tiene las herramientas instaladas y listas para usar. La ventaja principal del maletín es evitar errores en la configuración del entorno en sistemas remotos y garantizar la seguridad en el manejo de credenciales (se detalla en la sección 05).

La documentación oficial recomienda este action para tres tipos de tareas:

• Publicar retroalimentación automática de Codex en PR o publicaciones de lanzamiento (releases).
• Establecer controles de calidad de código con Codex como un paso obligatorio de la CI.
• Ejecutar tareas repetitivas de Codex (revisiones de código, preparación de lanzamientos, migraciones) definidas en un archivo workflow.

A diferencia del flujo de revisión interactiva en GitHub mediante menciones de comentarios, este action funciona como una GitHub Action estándar que responde a eventos declarados en el bloque on: del archivo de configuración.

💡 Resumen en una frase: openai/codex-action es el "maletín integrado oficial" que instala el Codex CLI en la CI, configura la API key y ejecuta codex exec de forma autónoma; se activa mediante eventos (en lugar de comentarios @) y se utiliza para controles de calidad y revisiones automáticas.

El flujo de ejecución de la acción se estructura de la siguiente manera:

Este diagrama representa el ciclo de la acción: se detecta el evento de PR → se ejecuta checkout para obtener el código → se inicia codex-action usando un prompt de entrada → el resultado se exporta a través de la variable final-message → si hay contenido, se publica como comentario en el PR.

---

03 Workflow mínimo: anatomía del archivo YAML para revisión de PR

Presentamos la plantilla YAML mínima recomendada por la documentación oficial para realizar revisiones automáticas sobre nuevos PR y publicar los comentarios correspondientes.

Analogía: La hoja de asignación de turnos del personal. Este archivo define la colaboración de dos trabajos en la CI: el primer job (codex) actúa como el inspector que revisa el PR y anota sus hallazgos en una nota técnica (el output final-message); el segundo job (post_feedback) actúa como el asistente que lee la nota y, si contiene observaciones, las publica en el PR. Esta separación de tareas es una medida de seguridad diseñada intencionalmente: el inspector opera con permisos de solo lectura para mitigar riesgos, mientras que el asistente cuenta con permisos de escritura estrictamente para publicar el comentario.

Plantilla recomendada (simplificada y lista para implementar):

# Ruta del archivo: .github/workflows/codex-review.yml
name: Codex pull request review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          persist-credentials: false

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          output-file: codex-output.md

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post Codex feedback
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

Explicación detallada de las secciones:

Activador on: el workflow se ejecuta en eventos de PR cuando son abiertos (opened), actualizados con nuevos commits (synchronize) o reabiertos (reopened).

Paso checkout: es obligatorio descargar el código usando checkout antes de invocar a Codex para que la herramienta pueda acceder a la estructura del repositorio. Se configura persist-credentials: false para evitar almacenar credenciales Git en el espacio de trabajo de la CI y se especifica ref: .../merge para evaluar el código resultante tras la fusión propuesta. (La documentación oficial incluye un paso de pre-obtención de ramas base y destino para mayor robustez, el cual se ha omitido en esta plantilla para mantener la estructura clara).

Paso Run Codex (núcleo del flujo):

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt-file: .github/codex/prompts/review.md
    output-file: codex-output.md

Requiere tres parámetros mínimos: openai-api-key para proveer la clave de autenticación (ver sección 05); prompt-file que apunta al archivo markdown con las instrucciones de revisión guardado en el repositorio (se recomienda colocarlo bajo .github/codex/prompts/); y output-file que guarda la respuesta de Codex en un archivo en disco para auditorías.

Bloque outputs y job post_feedback: el job codex exporta la respuesta final de la IA (steps.run_codex.outputs.final-message) a nivel de flujo; el job post_feedback espera a que el primer job termine (needs: codex), valida que el mensaje no esté vacío (if: needs.codex.outputs.final_message != '') y utiliza un script oficial de GitHub para publicar la retroalimentación como comentario en el PR.

El parámetro de salida final-message representa el canal formal de salida de Codex, permitiendo utilizar la respuesta técnica para notificaciones secundarias en Slack, registros de auditoría o validaciones en la canalización.

El prompt de entrada puede definirse mediante prompt-file (apuntando a un archivo markdown o de texto en el repositorio) o prompt (ingresando el texto directamente en el YAML en una línea). Se debe usar solo uno de ellos para evitar fallos de ejecución. Para tareas complejas como revisiones de código, se recomienda usar un archivo independiente para un mejor control de versiones.

💡 Resumen en una frase: La plantilla mínima define dos jobs: codex analiza el repositorio con permisos de lectura y escribe sus observaciones en final-message, mientras que post_feedback publica el comentario en el PR con permisos de escritura específicos; manteniendo los privilegios acotados por seguridad.

---

04 Configuración de parámetros de entrada de la acción

Los parámetros definidos en codex-action corresponden a las opciones del comando codex exec adaptadas a la estructura de archivos YAML de GitHub Actions:

Parámetro (input)	Descripción	Nota
prompt / prompt-file	Instrucción para la tarea (texto directo / archivo en repositorio)	Excluyentes, use solo uno
sandbox	Define el nivel del sandbox	workspace-write / read-only / danger-full-access
model y effort	Especifica el modelo y esfuerzo de razonamiento	Omitir para usar valores por defecto del sistema
output-file	Guarda la respuesta en un archivo en el runner	Útil para persistencia y artefactos
codex-args	Pasa argumentos adicionales al CLI	Matriz JSON (ej. ["--ephemeral"]) o cadena (ej. --profile ci)
codex-version	Fija una versión específica del CLI	Por defecto utiliza la última versión estable
codex-home	Define la ruta del directorio home de Codex	Útil para compartir estados y MCP entre pasos

Aspectos clave a considerar:

El parámetro sandbox define el nivel de aislamiento. Como se detalló en el artículo [15], los niveles son read-only (solo lectura), workspace-write (escritura en área de trabajo) y danger-full-access (acceso completo). En flujos de CI, se recomienda restringir los privilegios al mínimo necesario para completar la tarea. Si la tarea consiste únicamente en revisar código y emitir comentarios, use read-only. Si requiere aplicar correcciones directamente sobre los archivos, configure workspace-write.

Tenga en cuenta que por defecto, codex exec se ejecuta bajo un sandbox de solo lectura (read-only). Si su flujo requiere realizar cambios en el código, debe declarar explícitamente sandbox: workspace-write en el archivo YAML, de lo contrario la ejecución no podrá modificar los archivos.

El parámetro codex-args permite pasar opciones específicas al CLI. Una opción común es enviar --output-schema para validar que la salida estructurada de Codex se ajuste a un esquema JSON definido, facilitando el procesamiento automático del reporte en pasos posteriores de la canalización.

Se recomienda omitir los parámetros model y effort para permitir que el sistema aplique las configuraciones óptimas según la cuenta del usuario, evitando así tener que actualizar el archivo YAML ante cambios de versiones en la API.

Para auditar y depurar la ejecución de Codex en la CI, se recomienda configurar output-file: codex-output.md y agregar un paso final de carga de artefactos (upload-artifact) para almacenar el archivo md resultante de forma independiente, facilitando su revisión fuera de los registros de consola de GitHub Actions.

Por defecto, codex-action inicia un Responses API proxy para gestionar el tráfico de peticiones y proteger la API key en el entorno del runner. Esta arquitectura minimiza la exposición de las credenciales de OpenAI en la máquina virtual, razón por la cual se aconseja usar la acción oficial en lugar de implementar scripts de instalación manuales.

💡 Resumen en una frase: Los parámetros YAML de la acción configuran el comportamiento de codex exec: use sandbox para asignar permisos de escritura de forma explícita si requiere aplicar cambios (ya que el valor por defecto es solo lectura), pase opciones estructuradas mediante codex-args y guarde el reporte en un archivo md con output-file para depuración.

---

05 Seguridad en la gestión de credenciales y límites de acceso en la CI

La seguridad en la gestión de credenciales es un factor crítico en flujos automatizados de CI/CD, ya que los runners de ejecución suelen ser entornos compartidos o expuestos a código externo.

1. Almacenar credenciales en GitHub Secrets

La API key debe declararse en el YAML haciendo referencia al gestor de secretos de GitHub:

openai-api-key: ${{ secrets.OPENAI_API_KEY }}

No incluya la clave de API directamente en el código del archivo YAML. En repositorios públicos o compartidos, las credenciales expuestas en texto plano pueden ser detectadas por rastreadores automatizados de seguridad, comprometiendo su cuenta de OpenAI.

Analogía: Guardar la llave en una caja fuerte y usar una referencia. GitHub Secrets actúa como una caja fuerte para su repositorio. Usted ingresa la clave una sola vez en el panel de configuración; el sistema la almacena de forma encriptada y la enmascara en los registros de salida. El texto en el YAML es únicamente una referencia para solicitar la clave en tiempo de ejecución, manteniendo segura la credencial real.

Para configurarlo, acceda a Settings → Secrets and variables → Actions en su repositorio de GitHub, cree un secreto con el nombre OPENAI_API_KEY y asigne su clave de API de OpenAI.

2. Evitar declarar la credencial a nivel de job o entorno global

Existe un riesgo de seguridad al declarar la credencial como una variable de entorno accesible para todo el job de la CI:

No exponga OPENAI_API_KEY o CODEX_API_KEY como variables de entorno globales (env) en jobs de CI que ejecuten pruebas, scripts de dependencias o actions de terceros. Los scripts de compilación, hooks de npm o herramientas de terceros podrían acceder a ellas y extraerlas.

Asigne la credencial únicamente en el bloque with: del paso específico que invoca a codex-action, evitando declararla en el bloque env global del job para restringir su visibilidad a los demás procesos del runner.

La arquitectura de proxy de Responses API en codex-action ayuda a contener el acceso a la credencial dentro del paso de ejecución correspondiente.

3. Restringir privilegios de ejecución en el runner

Por defecto, el runner de GitHub otorga amplios privilegios de ejecución. Codex permite acotar estos privilegios mediante las siguientes opciones en la acción:

Parámetro	Propósito	Configuración recomendada
safety-strategy	Desactiva privilegios sudo para proteger secretos en memoria	drop-sudo por defecto; use unsafe únicamente en Windows
unprivileged-user	Asigna un usuario de sistema de bajos privilegios para la ejecución	Requiere configurar permisos de lectura/escritura en el directorio de trabajo
read-only	Bloquea la escritura de archivos y el acceso de red en Codex	No exime de limitar los privilegios del proceso en el runner
sandbox	Configura el sandbox de Codex para restringir accesos locales	Use el nivel mínimo necesario (read-only para revisiones)
allow-users / allow-bots	Restringe qué cuentas pueden activar la ejecución de la acción	Por defecto limitado a cuentas con permisos de escritura en el repositorio

Consideraciones sobre seguridad en el runner:

El valor por defecto de safety-strategy es drop-sudo, el cual remueve los permisos de administrador en el entorno antes de iniciar a Codex para prevenir accesos no autorizados a la memoria del sistema. Para runners de Windows, se debe declarar safety-strategy: unsafe, pero se desaconseja el uso de runners compartidos o multitenant en este estado.

La opción read-only restringe el acceso de red y la escritura a nivel de herramienta de Codex, pero debe complementarse con la desactivación de privilegios de administrador a nivel de sistema.

Utilice allow-users o allow-bots para restringir la ejecución automática ante eventos externos (como PR de forks públicos) y evitar que usuarios no autenticados consuman recursos de su API key de forma no autorizada.

Alineado con las directrices de seguridad de las peticiones del artículo [16], limpie o valide la información proveniente de campos externos como títulos de confirmación (commit messages) o descripciones de PR antes de pasarlos a Codex, para prevenir ataques de inyección de instrucciones (prompt injection) que pudieran estar incrustados en comentarios HTML de usuarios externos. Asimismo, coloque el paso de ejecución de Codex al final de la cadena de jobs para evitar que cambios accidentales afecten a pasos posteriores.

💡 Resumen en una frase: La seguridad en la CI requiere: almacenar la API key en Secrets, pasarla únicamente al paso de codex-action (no de forma global al job), mantener activo drop-sudo y limitar los activadores externos mediante allow-users para evitar la exposición de credenciales y consumos no autorizados.

---

06 Flujo 2: Automations en la App de escritorio para tareas periódicas locales

El segundo flujo de automatización se ejecuta a nivel de usuario en su máquina local a través de la App de escritorio de Codex.

La función Automations permite programar la ejecución periódica de tareas específicas en segundo plano. Si Codex detecta cambios o hallazgos relevantes durante el análisis, los enviará a su bandeja de entrada (Triage); de lo contrario, archivará la ejecución de forma silenciosa para evitar alertas innecesarias.

Casos de uso comunes

• Resúmenes de desarrollo periódicos: análisis de los commits en las ramas principales en las últimas 24 horas para generar reportes estructurados de cambios por temas.
• Auditoría periódica de código: análisis diario de los commits locales del usuario para identificar regresiones o proponer optimizaciones.
• Supervisión de procesos: monitoreo periódico del estado de procesos de larga duración o consultas a servicios externos.

Tipos de Automations

Existen dos tipos de tareas programadas en la App de escritorio:

Tipo	Standalone (Independiente)	Thread Automation (De hilo)
Contexto	Inicia un nuevo entorno limpio en cada ejecución	Mantiene el contexto e historial del hilo original
Persistencia	No mantiene historial entre ejecuciones	Registra la secuencia de ejecuciones en el mismo hilo
Destino de salida	Se reporta en la bandeja de entrada (Triage)	Se añade en la conversación del hilo correspondiente
Caso ideal	Generación de reportes independientes o análisis de código	Monitoreo continuo de un proceso o respuestas interactivas

Para tareas de monitoreo con Thread Automation, se recomienda redactar prompts detallados que indiquen claramente qué validar en cada ciclo de ejecución, qué umbral define una notificación de alerta y cuándo dar por finalizado el proceso de monitoreo.

Aislamiento de ejecución: local frente a worktree

En repositorios bajo control de versiones Git, las tareas programadas pueden configurarse para ejecutarse en el directorio principal o en un worktree independiente:

• Ejecución en worktree: la tarea crea un entorno aislado en segundo plano, evitando interferir con las modificaciones o archivos abiertos en su sesión de desarrollo local.
• Ejecución en local: la tarea interactúa directamente sobre su directorio principal, lo cual puede modificar archivos que se encuentre editando en su IDE en ese momento. Use esta opción con precaución.
• Para carpetas no controladas por Git, la ejecución se realiza directamente en el directorio asignado.

Para la mayoría de tareas de automatización, se recomienda elegir la ejecución en worktree para evitar conflictos con su espacio de trabajo activo. Tenga en cuenta que la creación frecuente de entornos de trabajo temporales consume almacenamiento; configure reglas de limpieza automática en la App o archive las ejecuciones finalizadas periódicamente.

Configuración de permisos

La ejecución de Automations en la App de escritorio se rige por las siguientes reglas de permisos:

1. Sandboxing local: las tareas automatizadas adoptan la configuración de sandbox predeterminada de su perfil en Codex. Si requiere que el script de automatización acceda a recursos de red o modifique archivos locales, asegúrese de otorgar permisos mediante workspace-write en su perfil de configuración.
2. Aprobación automática: las ejecuciones automáticas operan bajo la política approval_policy = "never" (siempre que la configuración de su organización lo permita), lo cual evita solicitar confirmación en pantalla antes de ejecutar cada paso. Asegúrese de estructurar el sandbox y las reglas de seguridad de su perfil para limitar el alcance de las tareas automatizadas.

Para validar el comportamiento de una tarea programada, se aconseja ejecutar el prompt manualmente en una conversación convencional antes de guardarlo como una automatización, para depurar la respuesta del modelo y afinar las instrucciones.

⚠️ Para que los procesos de automatización local se ejecuten, su máquina de desarrollo debe estar encendida y la App de escritorio de Codex debe estar activa en segundo plano; si cierra la aplicación, las tareas programadas no se iniciarán hasta la siguiente apertura del entorno.

💡 Resumen en una frase: Automations ejecuta tareas en segundo plano locales que reportan hallazgos en la bandeja de entrada (Triage) si encuentran novedades; se recomienda ejecutar las tareas en worktrees independientes para aislar los cambios y estructurar adecuadamente las políticas de sandbox al operar bajo aprobación automática (approval_policy = "never").

---

07 Práctica: Automatizar un resumen diario de cambios en la App de escritorio

Realizaremos la configuración práctica de una tarea de automatización local en la App de escritorio de Codex para generar reportes diarios de actividad en el repositorio.

Requisitos: contar con la App de escritorio de Codex instalada y activa, y tener cargado un proyecto bajo control de versiones Git con historial de confirmaciones.

Paso 1: Validar el prompt en una conversación convencional

Abra el proyecto en la App, inicie un chat estándar y envíe las siguientes instrucciones en español para comprobar la respuesta del modelo:

Analiza los commits realizados en este repositorio durante las últimas 24 horas y genera un resumen en español con la siguiente estructura:
- Agrupa los cambios por temas o módulos del proyecto (evita listar las confirmaciones individualmente).
- Describe el propósito general de cada grupo en una o dos líneas.
- Si no hay confirmaciones en las últimas 24 horas, responde únicamente: "Sin cambios registrados en el período".

Resultado esperado: Codex consulta el historial de Git local y devuelve un resumen formateado de cambios o indica que no hay confirmaciones. Este paso permite ajustar la claridad de las instrucciones antes de programar la tarea.

Paso 2: Programar la automatización

En la misma conversación, envíe la instrucción para registrar la automatización:

Configura esta tarea de resumen como una automatización standalone que se ejecute diariamente a las 9:00 AM.
Configúrala para que se ejecute en un worktree independiente para proteger mis archivos locales. 
Si el resultado es "Sin cambios registrados en el período", archiva la ejecución automáticamente sin notificarme.

Resultado esperado: Codex analiza la solicitud, genera la plantilla de configuración de la automatización (tipo standalone, frecuencia a las 9:00 AM, entorno worktree) y solicita confirmación del usuario. Haga clic en el botón de confirmación en la interfaz gráfica. También puede crearla manualmente desde la pestaña Automations de la App de escritorio ingresando los parámetros.

Puede definir la frecuencia mediante expresiones estándar de cron (ej. para ejecutar los lunes a primera hora).

Paso 3: Validar el registro en el panel de control

Acceda a la pestaña Automations en la barra de navegación de la App de escritorio.

Resultado esperado: La nueva tarea debe aparecer en la lista de automatizaciones programadas con su frecuencia (9:00 AM), tipo (standalone) y modo de aislamiento (worktree).

Paso 4: Ejecución manual de prueba

Seleccione la automatización en el panel y presione el botón de ejecución manual para forzar una corrida sin esperar al día siguiente.

Resultado esperado:

• El sistema inicia el proceso en segundo plano en un entorno worktree.
• Si el repositorio contiene confirmaciones recientes, se generará una tarjeta con el reporte de cambios en la bandeja de entrada (Triage); si no hay confirmaciones, la ejecución se moverá directamente a la sección de archivados.
• La recepción de la tarjeta de reporte (o su correcto archivado silencioso) confirma que el flujo está configurado correctamente.

Paso 5: Evaluación de resultados

Abra la tarjeta generada en Triage y evalúe la estructura del reporte. Si requiere refinar la presentación, puede editar el prompt de la tarea directamente desde la interfaz gráfica de la automatización. Recuerde archivar periódicamente los reportes antiguos para optimizar el almacenamiento del entorno local.

Completar este ejercicio le brindará la experiencia necesaria para estructurar tareas automatizadas periódicas locales, un flujo aplicable a otras actividades repetitivas en su entorno de desarrollo.

💡 Resumen en una frase: La configuración de tareas locales requiere: probar el prompt en un chat convencional → registrar la automatización indicando el uso de worktree → confirmar el registro en el panel de Automaciones → forzar una ejecución manual para validar el flujo → refinar el prompt según la retroalimentación.

---

08 Resumen

Este artículo ha analizado las dos vías de automatización de Codex, comparando el alcance colaborativo de la integración remota frente al monitoreo local de tareas repetitivas.

Repasemos los conceptos clave:

Objetivo	Flujo recomendado	Puntos clave
Automatización en equipo	GitHub Actions	Se activa mediante eventos de repositorio, se ejecuta en la nube en runners remotos
Tareas del CLI en la CI	openai/codex-action@v1	Instala el CLI de forma autónoma y ejecuta codex-action en modo no interactivo
Controlar flujos de YAML	YAML en .github/workflows/	Los jobs de análisis (read) y publicación (write) deben operar con permisos mínimos separados
Parámetros de ejecución	Entradas del action	El sandbox por defecto es de solo lectura; requiriendo sandbox: workspace-write para aplicar cambios
Proteger credenciales	GitHub Secrets	Almacene claves en Secrets, no las asigne a variables globales del job y mantenga activo drop-sudo
Tareas locales programadas	Automations (App)	Se programan por tiempo, reportan en Triage (bandeja) y se recomienda ejecutarlas en worktrees aislados

Comprender la diferencia entre procesos integrados en la CI del repositorio frente a flujos de monitoreo local en segundo plano le permite delegar tareas administrativas y de control de calidad a Codex de forma segura. La automatización actúa como un filtro inicial constante, optimizando el tiempo de revisión y desarrollo del equipo.

---

El siguiente artículo 28 · Modo no interactivo codex exec: tanto GitHub Actions como Automations utilizan en la capa inferior el comando codex exec. Analizaremos las opciones de este modo no interactivo: control de flujos de salida (stdout y stderr), formateo de eventos con --json y su integración en scripts y tuberías locales de shell con git, gh o sistemas de mensajería externa, permitiéndole diseñar sus propios flujos de automatización a nivel de terminal.

---

Lecturas recomendadas

• Sistema de memoria en Codex: persistencia de directrices e historial entre sesiones
• Consejos para redactar prompts efectivos en entornos de automatización
• Uso de extensiones de IDE en VS Code y entornos similares