⏱️ Lectura: 12 min
Desde la versión 0.157.0, el daemon de Codex CLI arranca solo: cada sesión interactiva deja corriendo un proceso en segundo plano que sobrevive al cierre de la terminal y se autoactualiza cada hora. El cambio pasó sin aviso explícito en el changelog y generó un reclamo directo a OpenAI: el issue #48195, abierto el 25 de septiembre de 2026 en el repositorio de Codex, pide que ese comportamiento sea opt-in en lugar de venir activado por defecto.
📑 En este artículo
TL;DR
- Desde Codex CLI 0.157.0, abrir una sesión interactiva deja un daemon vivo tras cerrar la terminal.
- El issue #48195, abierto el 25 de septiembre de 2026, pide que daemon_auto_start sea opt-in por defecto.
- Esa versión copia ~374 MB del paquete a ~/.codex/packages/, desacoplado del gestor de paquetes.
- Un updater revisa cambios cada hora y reinicia el backend, lo que puede matar turnos activos.
- Apagar el daemon con app-server daemon stop no mata pid-update-loop, que sigue corriendo después.
Qué es Codex CLI
Codex CLI es la herramienta de OpenAI para programar con agentes de IA desde la terminal: lee archivos, ejecuta comandos y mantiene conversaciones multi-turno con un modelo. Se instala como paquete npm @openai/codex y, desde la versión 0.157.0, cada sesión interactiva activa un daemon de Codex CLI en segundo plano.
El proyecto es de código abierto y se distribuye como paquete de npm bajo @openai/codex, con builds nativas para distintas plataformas. La CLI compite con herramientas como GitHub Copilot CLI o Claude Code, y OpenAI le fue sumando un modo de Remote Control para controlar sesiones desde el celular o la web, algo que necesita un backend compartido entre dispositivos.
Qué pasó con el daemon de Codex CLI
El reportante, un usuario de GitHub identificado como Yihua-Liu-1997, documentó el comportamiento tras actualizar a la versión 0.157.0 instalada con npm install -g @openai/codex en Linux vía WSL2. Según su reporte, abrir una sesión interactiva de codex dispara tres acciones que antes no ocurrían.
Primero, arranca codex app-server --managed-daemon en una sesión propia, sin terminal asociada, y el proceso queda reparentado al PID 1: sigue vivo después de cerrar cada ventana de Codex, hasta que alguien ejecute codex app-server daemon stop o se reinicie la máquina. Segundo, copia el paquete completo de la plataforma (unos 374 MB, con el binario de codex, codex-code-mode-host y las versiones empaquetadas de bwrap, zsh y rg) a ~/.codex/packages/app-server-daemon/releases/<version>/, una copia idéntica a lo que npm acababa de instalar, y corre el daemon desde esa copia. Desde ese momento, la versión del backend queda desacoplada de la que el usuario instaló con su gestor de paquetes. Tercero, lanza un actualizador independiente (codex app-server daemon pid-update-loop) que revisa actualizaciones a los 5 minutos de arrancar y después cada hora, descarga nuevas versiones y reinicia el backend.
Ese reinicio automático puede matar turnos activos de un agente a mitad de ejecución, un problema documentado por separado en el issue #40969, donde se detalla que la actualización fuerza el cierre tras un presupuesto de 60 segundos de espera y que, además, no se puede desactivar. El reportante también describe un efecto secundario sutil: el daemon fija el entorno de la sesión que lo arrancó por primera vez. Si esa primera sesión definía una variable como HTTPS_PROXY para pasar por un proxy corporativo, el daemon sigue usando ese proxy para todas las conexiones salientes, sin importar con qué variables se lancen las sesiones siguientes. Los issues #42457 y #37537, que documentan hooks que reciben el directorio de trabajo o la terminal del daemon en lugar de los de la sesión real, podrían compartir la misma causa de fondo.
Contexto e historia
El issue se abrió el 25 de septiembre de 2026 y, en las primeras horas, otros desarrolladores confirmaron el mismo comportamiento en entornos distintos. Un usuario escribió que algo no debería crear servidores y procesos misteriosos de la nada en un cambio de versión menor sin avisar a la gente, comentario que acumuló 9 reacciones. Otro usuario fue más tajante: calificó la CLI de inusable hasta que se corrija, comentario que sumó 10 reacciones. Un tercer usuario confirmó el problema en Windows 10 LTSC con la misma versión 0.157.0 y encontró que fijar daemon_auto_start = false en config.toml resuelve el síntoma, aunque pidió además que la CLI caiga a modo local cuando el arranque del daemon está bloqueado por permisos, en vez de exigir el flag --no-daemon a mano.
El reclamo no aparece aislado. Issues previos ya habían tocado piezas del mismo problema: el #41188 pide que Codex soporte ejecutables de daemon gestionados externamente en lugar de copiarlos siempre; el #46468 describe que una actualización vía npm deja el app-server en una versión vieja sin que el daemon se recupere solo; y el #48050 reporta que, en Arch Linux, el paquete de Codex 0.157.0 no arranca a menos que se use --no-daemon. Son reportes separados sobre la misma decisión de diseño: convertir una CLI que antes vivía y moría con cada invocación en un cliente que habla con un backend persistente.
Detalles técnicos: el mecanismo del daemon
Lo que distingue a este proceso de un simple job en segundo plano es la combinación de tres mecanismos de sistema operativo. El primero es la reparentización a PID 1, la técnica estándar de Unix para demonizar un proceso: al desvincularse de la sesión que lo creó, deja de recibir señales como SIGHUP cuando esa sesión termina, así que el daemon de Codex CLI corre desde su propio directorio y sobrevive al cierre de la terminal por diseño, no por accidente.
El segundo mecanismo es la copia local versionada. En lugar de ejecutar el binario que el gestor de paquetes dejó en el PATH, el daemon corre desde ~/.codex/packages/app-server-daemon/releases/. Esto resuelve un problema real (poder actualizar el backend sin reinstalar la CLI completa) pero crea otro: hay dos copias del mismo software en el disco, y nada garantiza que estén en la misma versión después de que el actualizador haga su trabajo.
El tercer mecanismo es el propio actualizador, un bucle separado que sondea por versiones nuevas y reinicia el backend si encuentra una. El reportante probó a apagar todo a mano y encontró un bug adicional en el camino: codex app-server daemon stop detiene el proceso app-server, pero no el pid-update-loop, que seguía vivo 70 segundos después y tuvo que matarse manualmente. La secuencia completa que documentó para dejar la máquina limpia es esta:
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemonCon daemon_auto_start en false, una sesión nueva de la TUI ya no dispara ningún daemon. No hay forma documentada de confirmar desde afuera si el proceso quedó completamente apagado: el propio reportante tuvo que revisar procesos a mano con pkill en vez de contar con un comando oficial de verificación.
⚠️ Ojo: detener el proceso con
codex app-server daemon stopno alcanza: el actualizadorpid-update-loopsigue corriendo por separado y hay que matarlo aparte.
| Modo | Qué pasa al abrir codex | Riesgo | Cuándo conviene |
|---|---|---|---|
daemon_auto_start = true (default desde 0.157.0) |
Arranca un daemon persistente y un updater en segundo plano | El backend puede quedar en otra versión que el CLI instalado; los reinicios pueden matar turnos activos | Remote Control o la app de escritorio, donde varias sesiones comparten un backend |
daemon_auto_start = false |
Cada sesión corre el binario instalado directamente, sin proceso en segundo plano | Se pierde la ventaja de un backend compartido entre sesiones | Uso normal de la CLI en una sola terminal, el caso de la mayoría de los reportantes del issue |
flowchart TD
A["Usuario ejecuta codex"] --> B["Arranca app-server --managed-daemon"]
B --> C["Copia ~374 MB a ~/.codex/packages/"]
B --> D["Inicia pid-update-loop"]
D --> E["Revisa actualizaciones cada hora"]
C --> F["El backend queda desacoplado del CLI instalado"]
E --> G["Reinicia el daemon y puede matar turnos activos"]
Impacto y análisis
El contrato implícito de una herramienta de línea de comandos es simple: corre cuando la invocás y termina cuando cerrás la terminal. El daemon de Codex CLI rompe ese contrato sin pedir confirmación, y lo hace justo en el tipo de entorno (terminales de desarrolladores, muchas veces con acceso a proxies corporativos y credenciales) donde un proceso persistente con conexión de red propia genera más fricción.
El patrón de tener un backend compartido no es nuevo: Docker Desktop corre una máquina virtual en segundo plano, y VS Code mantiene un extension host vivo mientras el editor está abierto. La diferencia que señalan los reportes es doble. Primero, la mayoría de esas herramientas avisan explícitamente en la instalación que van a correr un servicio persistente; Codex CLI lo activó en un incremento de versión menor sin cambio visible en el flujo de instalación. Segundo, esas herramientas no suelen autoactualizarse en segundo plano sin control del usuario, y la combinación de proceso persistente más actualización automática más posibilidad de matar trabajo en curso es la que generó más reclamos.
La fragmentación de empaquetado agrava el problema. Los mismos síntomas aparecen con matices distintos según cómo se instaló Codex: con npm en Linux y WSL2, con el paquete de Arch Linux (#48050), y en Windows 10 LTSC. Cada gestor de paquetes espera controlar qué binario corre y en qué versión, y un daemon que se copia y se actualiza a espaldas de ese gestor rompe esa expectativa para cualquier empaquetador que no sea el propio OpenAI.
Qué sigue
Al cierre de este artículo, el issue #48195 está abierto y etiquetado como enhancement, CLI y app-server, sin una respuesta pública de un mantenedor de OpenAI sobre si daemon_auto_start pasará a ser opt-in. El reportante deja tres pedidos concretos si el comportamiento por defecto no cambia: que el daemon se apague solo cuando se desconecta su último cliente, que no se autoactualice ni se copie a sí mismo cuando la instalación vino de un gestor de paquetes (y en su lugar corra el binario ya instalado), y que al menos se pregunte una vez antes de activarlo.
Mientras tanto, la única mitigación confirmada es manual: fijar daemon_auto_start = false en config.toml antes de abrir una sesión nueva, o repetir la secuencia completa de limpieza si el daemon ya está corriendo.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré grep daemon_auto_start ~/.codex/config.toml para ver si tu instalación ya tiene el flag definido, y si no, sumate al issue #48195 para seguir si OpenAI lo cambia.
Preguntas frecuentes
¿Qué hace exactamente el daemon de Codex CLI?
Arranca con la primera sesión interactiva desde la versión 0.157.0, corre en segundo plano sin terminal asociada, copia el paquete de la plataforma a su propio directorio y se actualiza solo cada hora hasta que se detiene a mano o se reinicia la máquina.
¿Cómo desactivo daemon_auto_start en Codex CLI?
Fijando daemon_auto_start = false en ~/.codex/config.toml, o ejecutando codex features disable daemon_auto_start antes de abrir una sesión nueva; si el daemon ya está corriendo hay que detenerlo y matar el proceso pid-update-loop por separado.
¿Por qué Codex CLI empezó a usar un backend persistente en la 0.157.0?
No hay un anuncio oficial que lo explique, pero el diseño coincide con las necesidades de Remote Control y la app de escritorio de OpenAI, que necesitan un proceso compartido entre varias sesiones o dispositivos; el reclamo es que ese mismo diseño se activó también para la CLI de terminal, donde no hace falta.
¿El demonio en segundo plano de Codex afecta solo a instalaciones con npm?
No. Los reportes confirman el mismo problema en Windows 10 LTSC, en WSL2 sobre Linux y en el paquete de Arch Linux, cada uno con una variante distinta del síntoma.
¿Qué es daemon_auto_start?
Es el flag de configuración de Codex CLI que controla si cada sesión interactiva arranca el backend en segundo plano; desde la 0.157.0 viene activado por defecto.
Referencias
- GitHub: issue #48195: reporte original que pide hacer opt-in daemon_auto_start en Codex CLI.
- GitHub: issue #40969: documenta que el auto-update del daemon fuerza el cierre de turnos activos tras 60 segundos.
- GitHub: issue #41188: pide soporte para ejecutables de app-server daemon gestionados externamente.
- GitHub: openai/codex: repositorio oficial de Codex CLI.
- npm: @openai/codex: paquete de instalación de la CLI.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Riku Lu en Unsplash
¿Te sirvió? ¿Te dio otro error? Contalo abajo: las preguntas se responden y le sirven al siguiente que llegue.
Dejar un comentario
0 Comentarios