Modo no interactivo codex exec: cómo integrarlo en scripts y entornos de CI

📚 Navegación de la serie: El artículo anterior 〔27 Automatización y CI/CD〕 explicó cómo hacer que Codex trabaje de forma automática en la CI del repositorio y cómo configurar tareas periódicas. Este artículo detalla la instrucción principal detrás de estos flujos: codex exec, el "modo no interactivo" que recibe un prompt de entrada y finaliza la ejecución sin abrir la interfaz gráfica. El siguiente artículo 〔29 Integraciones con Slack, Linear y SDK〕 explicará cómo conectar esta herramienta con sistemas de mensajería y flujos de trabajo.

Amigos, hoy hablaremos de un comando que tarde o temprano necesitarán dominar: codex exec.

En el artículo 08 dedicado a la interfaz de línea de comandos (CLI), lo mencionamos brevemente comparándolo con "pedir comida a domicilio": usted define el pedido (un prompt), el sistema prepara la respuesta en segundo plano y se la entrega directamente en la terminal sin requerir que usted supervise el proceso. Aquella sección sirvió de introducción; este artículo profundiza en la estructura interna para comprender cómo opera, cómo procesa las entradas y cómo integrarlo en scripts de automatización.

¿Por qué es necesario dedicarle una sección completa? Porque el modo interactivo (que se inicia al ejecutar codex para abrir la interfaz a pantalla completa) tiene una limitación fundamental: asume la presencia de un humano frente a la pantalla para responder preguntas, aprobar pasos o validar diferencias. Cuando desea programar tareas automáticas como "analizar los commits del día anterior a primera hora", "aplicar correcciones automáticas ante fallos de CI" o "resumir registros de error", no hay un humano disponible para presionar botones. En esos casos, la interfaz interactiva queda suspendida esperando una aprobación que nunca llegará. codex exec resuelve precisamente este tipo de escenarios.

Comprender el uso de codex exec representa el punto de transición entre utilizar Codex como una herramienta de chat y adoptarlo como un componente integrado en su flujo de trabajo automatizado.

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

• La diferencia conceptual entre codex exec y la interfaz de usuario interactiva, y qué tareas automatizadas resuelve.
• La estructura clave de salidas de la herramienta: el progreso e información operativa se envían a stderr, mientras que el resultado final se envía a stdout, facilitando el uso de tuberías (pipes).
• Cómo combinar --json (salida estructurada de eventos) con -o / --output-last-message (guardar la respuesta final en un archivo) para la integración con sistemas de monitoreo y CI.
• El comportamiento del sandbox en modo no interactivo (el cual es de solo lectura por defecto) y la tabla de niveles de seguridad de escritura.
• Cómo enviar datos usando la entrada estándar (stdin), diferenciando el uso de tuberías como contexto frente al comando codex exec -.
• Un ejercicio práctico completo para ejecutar tareas simples, capturar los resultados e integrarlos en scripts de procesamiento por lotes.

⚠️ Los subcomandos, parámetros y comportamientos predeterminados descritos en este documento se basan en la documentación oficial de Codex. Los modelos y versiones se muestran a modo de ejemplo y pueden variar según su cuenta y actualizaciones del sistema.

---

01 Para qué escenarios está diseñado el modo no interactivo

codex exec está diseñado para automatizar tareas en entornos donde no hay intervención humana constante, como scripts de automatización local, tareas programadas por tiempo (cron) y canalizaciones de CI/CD, donde el resultado final debe ser consumido directamente por otros programas.

El modo interactivo (ejecutar codex para abrir la interfaz TUI a pantalla completa) es el entorno ideal para el desarrollo diario, siempre que usted se encuentre presente para interactuar con la herramienta.

Sin embargo, existen tres tipos de tareas en las que la presencia del usuario no es viable o conveniente:

1. Tareas rutinarias y repetitivas. Por ejemplo, "generar un reporte de cambios a partir de los últimos 10 commits del día". Es una tarea sencilla pero monótona que no requiere supervisión activa; abrir la interfaz interactiva, copiar commits y esperar la respuesta de forma manual consume tiempo innecesariamente.

2. Entornos sin interfaz de usuario. Las canalizaciones de CI (runners), servidores en la nube o contenedores Docker no disponen de consolas interactivas donde desplegar la interfaz TUI.

3. Procesamiento de salida para tuberías. Por ejemplo, solicitar que Codex resuma un archivo de registro en una tabla markdown y enviar ese resultado directamente como comentario a un PR mediante gh pr comment en un script. Esto requiere que la salida del comando sea puramente de texto plano y libre de elementos gráficos de la interfaz.

Analogía: La máquina expendedora frente a la cafetería atendida por personal. El modo interactivo funciona como una cafetería: usted realiza un pedido, el mesero interactúa con usted, puede preguntarle si desea agregar azúcar o cambiar un ingrediente y le entrega el producto de forma directa. codex exec actúa como una máquina expendedora: usted ingresa un comando (presiona un botón), el sistema realiza el proceso internamente en un entorno cerrado y el producto final se deposita en la bandeja de salida (stdout) sin necesidad de interacciones secundarias, preguntas o confirmaciones en pantalla. Este diseño permite operar de forma desatendida a cualquier hora y en grandes volúmenes.

En el desarrollo diario, codex exec se implementa en los siguientes casos:

• "El pipeline de CI falló; analizar el error, proponer una solución y enviar el commit de corrección" — se ejecuta completamente en la nube sin intervención del desarrollador.
• "Generar las notas de lanzamiento de la versión a partir de las últimas confirmaciones y guardarlas en un archivo md" — se ejecuta automáticamente mediante un script local.
• "Enviar un registro de error a la herramienta para obtener un diagnóstico rápido y sugerencias de corrección" — se ejecuta en una sola línea de consola, evitando copiar y pegar el texto en el chat interactivo.

💡 Resumen en una frase: codex exec resuelve tareas desatendidas (como una máquina expendedora automática); es el flujo ideal para tareas repetitivas, entornos sin consolas interactivas y flujos de procesamiento en tuberías de comandos.

---

02 Sintaxis básica y primeros pasos

La sintaxis básica de codex exec consiste en declarar la instrucción directamente como argumento del comando, finalizando la ejecución al mostrar el resultado en la terminal:

codex exec "Resume la estructura de este proyecto y enumera 5 puntos críticos a considerar"

El comando analiza el directorio activo, formula un plan de análisis, reporta el avance en la consola y devuelve la respuesta final para luego cerrar el proceso, sin desplegar la TUI interactiva. Esto es el modo no interactivo: realiza la tarea y finaliza el proceso de inmediato.

Analogía: Enviar un correo electrónico con una tarea y esperar la respuesta. El modo interactivo equivale a una llamada telefónica con interacciones constantes. codex exec equivale a enviar un correo formal indicando detalladamente el requerimiento; el destinatario procesa la solicitud en privado y responde con el entregable final por correo. Usted no puede modificar el requerimiento a mitad del proceso, por lo que la instrucción inicial debe ser lo más descriptiva posible.

Variaciones comunes del comando:

# Uso del alias corto 'codex e', idéntico a 'codex exec'
codex e "Explica el propósito de este repositorio"

# Especificar un modelo particular para esta ejecución (use los nombres de su cuenta)
codex exec -m gpt-5.5 "Revisa los cambios locales e identifica posibles errores"

# Ejecutar sin guardar el historial en la base de datos local usando --ephemeral
codex exec --ephemeral "Analiza rápidamente el código y sugiere optimizaciones básicas"

Una diferencia fundamental con el modo interactivo: en la TUI, si el modelo requiere modificar un archivo, detendrá la ejecución para solicitar aprobación; en cambio, codex exec está diseñado para operar sin interrupciones, por lo que no mostrará diálogos de confirmación en la terminal. El nivel de cambios permitido estará determinado por los permisos del sandbox asignados al iniciar el comando, aspecto que detallaremos en la sección 04.

⚠️ Requisito del repositorio Git: por motivos de seguridad, Codex requiere que el comando se ejecute en un directorio bajo control de versiones Git (se puede omitir usando --skip-git-repo-check). Esto previene modificaciones accidentales o no reversibles en sus archivos. Si intenta ejecutar el comando fuera de un repositorio Git, el proceso se cancelará. Puede usar --skip-git-repo-check únicamente en entornos aislados o de pruebas temporales si está seguro de la seguridad del directorio.

💡 Resumen en una frase: codex exec "instrucción" (o su alias codex e) ejecuta tareas de forma directa sin interrupciones ni confirmaciones en pantalla; requiere ejecutarse en directorios Git por seguridad, a menos que use --skip-git-repo-check en entornos de prueba seguros.

---

03 Estructura de salidas: stderr para operaciones y stdout para el resultado

Esta es una de las decisiones de diseño más útiles de codex exec para facilitar su integración en scripts y tuberías de terminal.

Al ejecutar una tarea, Codex genera abundante información complementaria: sus pensamientos internos, qué comandos ejecuta, qué archivos lee... Sin embargo, el script que invoca la herramienta generalmente solo requiere la respuesta final (el resumen o el código generado). Si toda la información se mezclara en un único canal de salida, la respuesta final se contaminaría con los registros operativos, dificultando su procesamiento.

Codex resuelve esto separando las salidas en dos canales de comunicación estándar:

Los registros de progreso y operaciones se envían a stderr (salida de error estándar), mientras que la respuesta final se envía a stdout (salida estándar). Aunque en la consola de la terminal se muestren ambos flujos de forma integrada, las tuberías (|) y los redireccionamientos de archivos (>) consumen únicamente stdout por defecto, lo que permite capturar la respuesta limpia fácilmente.

Analogía: La construcción y la entrega de una obra. El proceso de construcción genera ruido, polvo y escombros (equivalente a stderr, información operativa visible durante la obra pero que no forma parte del producto final). Al concluir, se hace entrega de la llave del inmueble limpio y terminado (stdout). Ambos canales operan de forma independiente para que al recibir el inmueble no se mezclen los materiales de desecho del proceso de obra.

Ejemplo para guardar el resultado final en un archivo conservando la visualización del avance en pantalla usando tee:

codex exec "Genera las notas de lanzamiento de los últimos 10 commits" | tee release-notes.md

Resultado esperado: la consola muestra el proceso operativo detallado (proveniente de stderr), y al finalizar se despliega la respuesta estructurada; simultáneamente, el archivo release-notes.md contiene únicamente el resumen limpio de cambios, libre de registros de progreso o depuración.

A partir de esta división de flujos se estructuran los siguientes comandos comunes:

Objetivo	Comando	Mecanismo
Guardar únicamente el resultado en un archivo	codex exec "..." > out.md	El operador > captura únicamente stdout; stderr se muestra en consola
Guardar y visualizar el resultado	codex exec "..." | tee out.md	tee divide stdout para guardarlo en disco y mostrarlo en la terminal
Enviar el resultado al portapapeles	codex exec "..." | pbcopy	El portapapeles recibe únicamente la respuesta final limpia
Guardar registros de progreso y resultados por separado	codex exec "..." > out.md 2> logs.txt	El operador 2> redirecciona stderr (logs) a un archivo independiente

Evite usar el operador de redireccionamiento combinado 2>&1 en sus scripts si desea extraer únicamente el resultado de Codex, ya que este comando mezcla el flujo de progreso (stderr) con la respuesta (stdout), contaminando el archivo final con los registros operativos del agente.

💡 Resumen en una frase: codex exec envía los registros de depuración a stderr y la respuesta final a stdout (separando el proceso operativo del producto entregado), permitiendo capturar respuestas limpias mediante redireccionamientos (>) o tuberías (|) sin mezclar registros de progreso.

---

04 Configuración de permisos y niveles del sandbox en modo no interactivo

Dado que codex exec se ejecuta sin supervisión humana constante, los límites de modificación de archivos en su sistema se rigen estrictamente por la configuración del sandbox.

Por defecto, codex exec se ejecuta en un sandbox de solo lectura (read-only), lo que le permite analizar el código, leer archivos y generar reportes, pero le impide modificar archivos en el disco o ejecutar comandos con efectos secundarios. Si su tarea requiere aplicar cambios, debe otorgar permisos de escritura de forma explícita.

Este diseño preventivo garantiza que las tareas automatizadas no realicen modificaciones destructivas o no deseadas en el repositorio si se produce un error en la interpretación de las instrucciones.

Analogía: Asignar llaves de acceso a un contratista en su ausencia. Al programar un servicio técnico en su domicilio mientras usted no está, no le entrega acceso a la caja fuerte ni a todas las habitaciones. Por defecto, le permite el ingreso únicamente a la sala de estar (modo de solo lectura). Si requiere realizar trabajos de plomería, le entrega específicamente la llave de la cocina (permisos de escritura acotados al directorio de trabajo con workspace-write). La llave de acceso total que permite alterar toda la estructura de la casa (danger-full-access) se reserva únicamente para entornos de demolición o completamente aislados.

El nivel del sandbox se define mediante el parámetro --sandbox (o -s), según los siguientes niveles:

Nivel del sandbox	Alcance de acción	Caso de uso recomendado
read-only (por defecto)	Lectura y análisis de archivos; bloqueo de escritura y red	Revisiones de código, auditorías, generación de reportes y resúmenes
workspace-write	Lectura y escritura limitada al directorio de trabajo del proyecto	Aplicar correcciones automáticas de errores, formatear código o escribir documentación
danger-full-access	Acceso completo al sistema operativo sin restricciones de red o archivos	Únicamente en entornos aislados (runners dedicados en contenedores o CI independientes)

Ejemplos de comandos según su nivel de privilegios:

# Modo de solo lectura por defecto: ideal para auditorías de seguridad sin alterar archivos
codex exec "Analiza los cambios recientes en busca de riesgos de seguridad"

# Permitir escritura únicamente en el proyecto: Codex puede modificar el código para resolver un error
codex exec --sandbox workspace-write "Corrige los fallos reportados en las pruebas unitarias"

# Acceso completo en un runner aislado de CI: ejecución desatendida sin límites locales
codex exec --sandbox danger-full-access "Instala dependencias del sistema y compila el binario"

Recomendaciones de seguridad importantes:

1. El parámetro --full-auto se encuentra en desuso (deprecated). En scripts antiguos de Codex es común encontrar la opción --full-auto. Ha sido reemplazada oficialmente por --sandbox workspace-write para declarar de forma más explícita el alcance de los permisos otorgados.

2. Reserve danger-full-access exclusivamente para runners de CI aislados. Ejecutar tareas programadas en su máquina de desarrollo local con este nivel de privilegios expone su sistema a ejecuciones de red o modificaciones no controladas.

3. Use --ignore-user-config e --ignore-rules para una ejecución limpia en servidores. El parámetro --ignore-user-config evita que Codex lea el archivo local $CODEX_HOME/config.toml, y --ignore-rules ignora las políticas locales de .rules, garantizando que la tarea automatizada se ejecute con una configuración estándar e idéntica en cualquier máquina del equipo.

Un error común al migrar scripts locales a la CI es asumir que Codex heredará la configuración de permisos del perfil del desarrollador. En entornos automatizados, al operar bajo una instalación limpia, la herramienta aplicará el sandbox de solo lectura predeterminado. Si su tarea requiere modificar código en la CI, debe incluir explícitamente --sandbox workspace-write en la declaración del pipeline.

💡 Resumen en una frase: codex exec opera en modo de solo lectura por defecto; si requiere aplicar modificaciones locales, debe declarar --sandbox workspace-write. Evite usar --full-auto (en desuso) y use --ignore-user-config en scripts de CI para asegurar una ejecución estandarizada.

---

05 Integración de flujos de datos estructurados: --json y -o

Cuando el resultado de Codex debe ser consumido por otros programas o scripts de procesamiento secundario, el análisis de texto plano (Markdown) puede resultar inestable. Codex provee dos herramientas complementarias para estructurar los datos de salida.

1. El parámetro --json: reportar el flujo operativo en formato JSON Lines (JSONL). Al incluir --json (o su equivalente --experimental-json), el flujo de stdout cambia de texto plano a JSON Lines (un objeto JSON independiente por cada línea de salida), reportando cada evento y cambio de estado del agente en tiempo real.

Analogía: Transmitir el reporte de actividad de forma estructurada en lugar de una crónica narrativa. Sin el parámetro --json, Codex describe sus pasos narrativamente en la consola; con el parámetro activo, exporta una bitácora detallada con campos estandarizados (hora, paso ejecutado, tokens consumidos, estado de éxito o error) que un programa secundario puede procesar fila por fila.

Ejemplo de salida estructurada enviada a jq para visualización:

codex exec --json "Resume la estructura del repositorio" | jq

Cada línea de la salida representa un evento estructurado con tipos definidos, como thread.started (inicio de hilo), turn.started / turn.completed / turn.failed (ciclos de ejecución) e item.completed (acciones realizadas, como llamadas a herramientas o búsquedas locales), incluyendo los consumos de tokens en la propiedad usage:

{"type":"thread.started","thread_id":"0199a213-81c0-7800-8aa1-bbab2a035a53"}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"El repositorio contiene docs e index.html."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"output_tokens":122}}

Esta estructura facilita la validación de errores en los scripts y el registro de estadísticas de uso de la API de forma automática.

2. El parámetro -o / --output-last-message: guardar únicamente la respuesta final. Si no requiere analizar la bitácora JSONL y solo desea almacenar la respuesta final de texto plano en un archivo para publicarla en un canal de comunicación, use -o <ruta> (o su versión larga --output-last-message):

codex exec "Genera un reporte del estado de salud del proyecto" -o ./health-report.md

Una característica útil: al usar -o, la respuesta final se escribe en el archivo y simultáneamente se imprime en stdout, permitiendo enviar el flujo a otros procesos de terminal de forma concurrente.

Comparación de escenarios de uso:

Requerimiento	Opción recomendada	Comportamiento
Validar el éxito de subprocesos, capturar errores o registrar el consumo de tokens en base de datos	--json	Convierte stdout en un flujo de eventos JSONL
Guardar el reporte Markdown final en un archivo físico	-o <ruta>	Escribe la respuesta en el archivo y la conserva en stdout
Analizar el flujo de eventos en la CI y guardar la respuesta de usuario de forma simultánea	Combinar --json y -o	Los eventos JSONL se procesan en stdout y la respuesta limpia se escribe en el archivo

La combinación de ambos parámetros es la estructura recomendada para integrar Codex en flujos de integración continua (CI/CD), permitiendo a los scripts monitorear la salud de la ejecución en base al flujo JSONL y disponer del reporte en texto plano para notificaciones externas.

💡 Resumen en una frase: Use --json para obtener un flujo estructurado de eventos en formato JSONL útil para scripts de monitoreo, y use -o para almacenar la respuesta final limpia en un archivo manteniendo la salida en stdout; combinando ambos en la CI para un control completo.

---

06 Uso de tuberías de entrada estándar (stdin)

Además de enviar los resultados de Codex hacia otros procesos, es común requerir alimentar a Codex con la salida de comandos previos del sistema. Esto se gestiona mediante la entrada estándar (stdin) de la terminal.

Existen dos flujos de trabajo según el origen de las instrucciones:

Flujo A: instrucción definida en el comando y datos en la tubería (instrucción + contexto). Se utiliza cuando usted define una directiva fija en el comando y le pasa la salida de otra herramienta como material de análisis.

Si el comando recibe datos por stdin y adicionalmente se declara un prompt como argumento, Codex interpretará el prompt como la instrucción a ejecutar y los datos de stdin como el contexto de análisis.

Ejemplo para analizar fallos de pruebas unitarias enviando la salida de error:

npm test 2>&1 \
  | codex exec "Analiza los fallos reportados en las pruebas unitarias y sugiere la corrección mínima" \
  | tee test-summary.md

Resultado esperado: la salida de error de las pruebas unitarias se envía a Codex como contexto de análisis; el prompt define la instrucción de corrección; la respuesta final limpia se despliega y se almacena en el archivo test-summary.md.

Ejemplo para procesar logs de sistema:

tail -n 100 system.log \
  | codex exec "Identifica errores críticos en estos registros y sugiere 3 pasos de solución" \
  > error-report.md

Flujo B: la instrucción y los datos provienen de la tubería (codex exec -). Se utiliza cuando todo el prompt (instrucción e información) es generado dinámicamente por otro comando o se almacena en un archivo externo. Para indicar explícitamente a Codex que consuma la entrada estándar como el prompt completo, se añade el guion - al final del comando:

# Usar el contenido de un archivo de prompt externo como la instrucción completa
cat doc-prompt.txt | codex exec -

# Construir un prompt dinámico en un script e inyectarlo en Codex
printf "Resume el estado del servicio en base al siguiente registro:\n\n%s\n" "$(curl -s https://api.status.com)" \
  | codex exec -

Esta opción permite desacoplar los prompts de los archivos de script, facilitando la administración de las plantillas de instrucciones en archivos markdown independientes que pueden actualizarse sin modificar el código del pipeline.

💡 Resumen en una frase: Para enviar datos a codex exec use: prompt en el comando + datos en la tubería para analizar logs o fallos (el prompt es la orden y la tubería es el insumo), o use codex exec - para inyectar todo el prompt dinámicamente desde un archivo o script externo.

---

07 Continuar sesiones previas: codex exec resume

El modo no interactivo permite encadenar ejecuciones en secuencia. Si requiere realizar un análisis inicial y posteriormente aplicar cambios basándose en los resultados, puede enlazar las sesiones mediante el comando resume.

Este comando evita tener que reenviar los reportes anteriores en cada ejecución, optimizando el consumo de tokens y manteniendo la coherencia de la conversación.

Flujo de trabajo en dos fases recomendado:

# Fase 1: analizar la estructura en busca de problemas de concurrencia
codex exec "Revisa el código de la base de datos en busca de condiciones de carrera"

# Fase 2: aplicar las correcciones sobre la misma sesión en segundo plano
codex exec resume --last "Aplica las correcciones recomendadas para evitar las condiciones de carrera detectadas"

El parámetro --last asocia la ejecución actual al último hilo registrado en el directorio activo. Si requiere apuntar a una sesión específica registrada en el historial, declare su identificador único al final del comando:

codex exec resume <SESSION_ID> "Completa la documentación del módulo de autenticación"

Consideraciones sobre el historial:

• Para consultar sesiones previas y obtener sus identificadores, use el historial local.
• Las ejecuciones iniciadas con el parámetro --ephemeral no se almacenan en la base de datos local y, por lo tanto, no admiten el uso de resume.

💡 Resumen en una frase: Use codex exec resume --last para continuar la ejecución en el último hilo registrado del directorio (ideal para flujos de dos fases), o especifique un SESSION_ID para retomar un historial concreto; tenga en cuenta que las ejecuciones temporales con --ephemeral no son persistentes.

---

08 Práctica: Configurar un flujo de procesamiento por lotes desatendido

Configuraremos un flujo local para generar resúmenes automáticos de archivos markdown del repositorio mediante un script de consola desatendido, validando el comportamiento de las tuberías y redireccionamientos.

Requisitos: contar con Codex CLI instalado y ejecutar las pruebas dentro de un repositorio Git activo.

Paso 1: Validar una ejecución simple de solo lectura

Ejecute la siguiente consulta en su terminal:

codex exec "Identifica el lenguaje de programación principal utilizado en este repositorio"

Resultado esperado: la consola muestra el progreso del análisis en segundo plano y finaliza imprimiendo el nombre del lenguaje en texto plano, regresando al indicador habitual de la terminal sin abrir menús interactivos.

Paso 2: Validar el direccionamiento limpio de stdout

Redireccione la salida a un archivo de texto para comprobar el aislamiento de los logs:

codex exec "Identifica el lenguaje de programación principal utilizado en este repositorio" > lang.txt

Resultado esperado: el avance se despliega en pantalla durante el procesamiento (stderr), pero al finalizar, el archivo lang.txt contiene únicamente el texto de respuesta limpia, libre de textos de estado o avance.

Paso 3: Analizar la estructura de eventos en formato JSON

Ejecute el comando solicitando la salida estructurada de eventos:

codex exec --json "Genera una lista de las carpetas de este proyecto"

Resultado esperado: stdout devuelve líneas con estructuras JSON independientes (JSONL) indicando los eventos del ciclo de vida (thread.started, turn.started, turn.completed). Valide la estructura de los datos impresos.

Paso 4: Guardar la respuesta final manteniendo stdout

Compruebe el funcionamiento del parámetro de guardado final:

codex exec "Describe en una línea el propósito de este proyecto" -o summary-line.md

Resultado esperado: la respuesta final se imprime en la terminal y de forma simultánea se escribe en el archivo summary-line.md en texto plano.

Paso 5: Implementar un procesamiento por lotes mediante un script de bucle

Estructure un script de consola simple para iterar sobre los archivos markdown del proyecto y generar reportes individuales de forma desatendida (usando --ignore-user-config para estandarizar la ejecución):

for file in *.md; do
  echo "=== Procesando: $file ==="
  codex exec --ignore-user-config "Explica el propósito de las primeras 5 líneas del archivo $file"
done

Resultado esperado: el bucle local recorre los archivos markdown del directorio, invoca a Codex de forma no interactiva para cada uno y despliega en pantalla la información estructurada de forma consecutiva sin requerir aprobaciones intermedias. Este flujo representa la base para tareas desatendidas en la CI.

Al completar estos pasos, habrá experimentado el comportamiento de las salidas, el manejo de eventos y la estructuración de scripts desatendidos con codex exec.

💡 Resumen en una frase: La práctica de procesamiento por lotes consta de cinco pasos: validar la ejecución directa desatendida → comprobar el redireccionamiento de stdout en un archivo → analizar el flujo JSON de eventos → validar el comportamiento de -o → implementar un script en bucle para procesamiento secuencial; estableciendo las bases para su integración en pipelines de CI.

---

09 Resumen

Este artículo ha detallado el funcionamiento del modo no interactivo de Codex mediante codex exec, destacando los mecanismos de control de salidas y seguridad de ejecución.

Repasemos los aspectos clave:

Objetivo	Comando / Parámetro	Puntos clave
Ejecutar tareas desatendidas	codex exec "instrucción"	Finaliza el proceso tras responder, diseñado para automatización
Capturar respuestas limpias	Redirección de stdout (>)	Las respuestas limpias van a stdout; la depuración de progreso va a stderr
Escribir cambios en archivos	--sandbox workspace-write	El sandbox por defecto es de solo lectura; requiere activación explícita para modificar código
Monitorear flujos en scripts	Parámetro --json	Transmite el avance operativo en formato estructurado JSONL
Guardar respuestas en archivos	Parámetro -o <ruta>	Escribe la respuesta final en un archivo y la mantiene activa en stdout
Inyectar datos dinámicos	codex exec - / Tuberías	Permite desacoplar prompts e inyectar logs o variables desde el shell
Enlazar tareas secuenciales	Comando resume	Retoma el contexto de la última sesión en la carpeta para flujos de dos fases

Adoptar el modo no interactivo le permite integrar las capacidades de análisis de Codex directamente en sus herramientas locales de terminal y scripts de automatización, extendiendo el alcance del desarrollo asistido por IA en sus flujos diarios.

---

El siguiente artículo 29 · Integraciones con Slack, Linear y SDK: explicaremos cómo extender el alcance de la automatización desatendida de codex exec conectándolo con herramientas de comunicación y gestión de tareas de su equipo, como configurar canales de Slack, registrar tareas en Linear o invocar la API directamente mediante el SDK oficial.

---

Lecturas recomendadas

• Empaquetar flujos complejos con Skills de Codex
• Funcionamiento de las tareas en la nube con Codex Cloud
• Uso de MCP para conectar herramientas y APIs externas