Codex CLI activa un daemon de 374 MB por defecto

¿Qué cambió en Codex CLI a partir de la versión 0.157.0?

Desde la 0.157.0, abrir una sesión interactiva de codex dejó de ser una operación efímera. El CLI levanta por defecto un daemon persistente (codex app-server --managed-daemon) que corre en su propia sesión, sin TTY, y que sigue vivo después de cerrar todas las ventanas de Codex: queda reparentado al PID 1 hasta que alguien ejecute codex app-server daemon stop o se reinicie la máquina.

El daemon copia además el paquete completo de la plataforma — alrededor de 374 MB con codex, codex-code-mode-host y binarios incluidos como bwrap, zsh y rg — a ~/.codex/packages/app-server-daemon/releases/<versión>/. La copia es idéntica byte a byte a lo que el gestor de paquetes acababa de instalar, pero a partir de ahí el backend queda desacoplado de la versión del CLI que el desarrollador cree estar usando.

También arranca un actualizador desprendido (codex app-server daemon pid-update-loop) que busca actualizaciones 5 minutos después del inicio y luego cada hora, descarga nuevas releases y reinicia el backend. Ese reinicio puede matar turnos activos, un problema reportado aparte y que el autor del reporte señala que sigue abierto.

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días

Todo esto está documentado en el reporte #48195 del repositorio público de OpenAI Codex, abierto el 25 de septiembre de 2026 por un usuario que corre Codex CLI 0.157.0 instalado con npm install -g @openai/codex sobre Linux en WSL2.

¿Por qué los desarrolladores lo comparan con malware?

El tono del hilo se endureció con los días. El 12 de octubre, un usuario resumió el comportamiento como un rasgo típico de malware y agregó que ni siquiera cree que haya sido accidental; el comentario reunió una docena de reacciones. Otro fue más lejos y se preguntó si el producto ya opera como un virus, especulando con que esos procesos podrían servir para armar una red con las IP residenciales de los usuarios.

Antes, los comentarios más votados eran operativos, no ideológicos. Uno de los primeros, con 17 reacciones, sentenció que el CLI es inusable hasta que esto se arregle. Otro desarrollador confirmó el mismo problema en Windows 10 LTSC con la 0.157.0 y aportó dos pedidos concretos: que el arranque del daemon sea opt-in y que, cuando el sistema operativo bloquee su elevación, el CLI caiga automáticamente a modo local en lugar de exigir la bandera --no-daemon.

El detalle que más incomoda no es el daemon en sí, sino la pérdida de control sobre la ejecución. El daemon fija el entorno de la sesión que lo arrancó primero: si lanzas Codex con un proxy distinto por invocación, todas las conexiones salientes pasan por el proxy de esa primera sesión. Un reporte del 12 de octubre describe el mismo patrón con variables de entorno de trabajo: si usas direnv con archivos .envrc y arrancas Codex en dos directorios con valores distintos, el agente sigue leyendo los del primero — algo que rompe flujos que dependen de nombres comunes como GH_TOKEN.

El problema de fondo: quién ejecuta realmente tu código

Un comentarista identificó bien el límite que se cruzó: la identidad del CLI instalado y la identidad del proceso que ejecuta el código dejaron de ser la misma cosa. Una vez que el CLI se copia a un directorio de releases gestionado y un actualizador en segundo plano puede reemplazar esa copia, el proceso que atiende un turno ya no es necesariamente el artefacto que el usuario instaló.

Su propuesta es concreta y vale como pedido para cualquier proveedor de agentes: que el daemon exponga un recibo de ejecución por cada conexión de cliente, con versión del CLI, digest y generación del binario del daemon, estado del actualizador y generación del entorno heredado. Sin eso, un cliente no puede distinguir si le está respondiendo el binario que instaló o una copia posterior.

El problema se agranda porque la salida documentada es invisible. Un comentarista del 12 de octubre revisó la referencia oficial de configuración y encontró cero filas sobre daemon_auto_start, mientras la misma página sí documenta check_for_update_on_startup. La nota de la versión 0.157.0 despachó el cambio en una sola frase, hablando de inicio automático de servidor en segundo plano para sesiones interactivas elegibles, sin nombrar el proceso persistente, la copia del paquete ni el actualizador horario.

El contexto que agrava la percepción de riesgo

La desconfianza no salió de la nada. BleepingComputer documentó en septiembre dos escapes del sandbox de Codex, uno de ellos capaz de ejecutar comandos sin aprobación y sin mostrar nada en pantalla. El más incómodo involucraba un componente llamado node_repl que Codex Desktop escribe en el archivo global ~/.codex/config.toml durante la instalación: sin opt-in y sin opción para desactivarlo, y como la entrada vive en la configuración compartida, los usuarios del CLI lo heredaban sin que nadie se lo preguntara. OpenAI corrigió ambos fallos en Codex Desktop build 26.818.21641 y en Codex CLI 0.149.0, dentro de los ocho días posteriores al reporte.

A eso se suma Plugin4Shell, la vulnerabilidad de ejecución remota de código reportada por Help Net Security que afectó a Claude Code, Codex, GitHub Copilot y Gemini CLI. Lo relevante para esta discusión es que, según Help Net Security, el mismo checkout de git se vuelve a ejecutar en la actualización automática en segundo plano, que ese medio describe como el comportamiento por defecto en Claude Code y Codex. Es decir: la revisión de seguridad que hiciste de un plugin deja de ser la revisión que importa, porque el pin puede cambiar solo. OpenAI parcheó Codex en la versión 0.146.0.

¿Cuánto pesa esto en un producto con 20 millones de usuarios?

El contraste entre adopción y confianza es la clave para leer este episodio. Memeburn reportó que Codex cruzó los 20 millones de usuarios activos el 21 de agosto de 2026, subiendo desde 15 millones una semana antes, y que a comienzos de 2026 la cifra era de unas 600.000 personas activas semanales. El ingeniero líder del producto, Tibo Sottiaux, comunicó el hito con reinicios de cuota acumulables para los suscriptores, en medio de una ola de quejas por límites que se agotaban más rápido de lo esperado.

La confianza, en cambio, no crece al mismo ritmo. Una encuesta informal de SD Times a 103 desarrolladores encontró que el 87% usa o planea adoptar herramientas de IA para código, pero solo el 31% confía en la exactitud del output y apenas el 4% declara confianza alta. El sentimiento favorable bajó al 58%, desde más del 70% en años anteriores.

Y hay una señal de fondo sobre el retorno real: un estudio de investigadores de Harvard sobre más de 700 empresas y 300 millones de eventos de trabajo, citado por Ars Technica, encontró que la introducción de agentes de código sube un 30% las líneas de código, un 20% los commits y un 23% los pull requests, pero no cambia de forma estadísticamente significativa la tasa de resolución de issues y epics. Más código, no necesariamente más producto — otra razón para no regalar control sobre qué procesos corren en tu máquina.

Cómo desactivar el daemon hoy (paso a paso)

El propio reporte incluye el workaround que funciona en la 0.157.0:

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'   # no lo detiene 'daemon stop'
rm -rf ~/.codex/packages/app-server-daemon

Con la bandera apagada, una sesión nueva de TUI ya no arranca el daemon. Dos advertencias verificadas en el hilo: en Windows, fijar daemon_auto_start = false en config.toml resuelve el problema; y daemon stop deja el actualizador pid-update-loop vivo, según el reporte original seguía activo 70 segundos después y hubo que matarlo a mano.

¿Qué significa esto para tu startup?

La lección no es que Codex sea inseguro, sino que el software que instalas dejó de ser el software que ejecuta tu trabajo. Eso tiene consecuencias directas en cualquier equipo que use agentes de código.

Audita qué corre en tus máquinas y contenedores. Verifica con ps aux | grep app-server si hay daemons vivos en las laptops del equipo, en runners de CI y en contenedores de desarrollo. Si administras una flota, conviene fijar daemon_auto_start = false como política por defecto y habilitarlo solo donde tenga sentido (una máquina de control remoto, por ejemplo).
Fija versiones y asume que el backend se autoactualiza. El paquete del daemon se copia a un directorio propio y puede actualizarse cada hora, con reinicios capaces de matar turnos activos. Si tu pipeline depende de una versión concreta del CLI, no basta con pinear el paquete: hay que asegurarse de que el backend efectivamente corre lo que crees.
Revisa la higiene de secretos y variables de entorno. El daemon hereda el entorno de la primera sesión, así que tokens como GH_TOKEN, perfiles de AWS o proxies quedan fijados por una corrida anterior. Usa credenciales de alcance corto, rótalas con frecuencia y no dependas de variables por directorio para aislar entornos.
Pide trazabilidad a tus proveedores de agentes. La propuesta de recibo de ejecución es un buen estándar para exigir: qué binario, qué versión y qué generación del daemon atendió cada turno. Si vendes software a empresas con requisitos de cumplimiento, vas a necesitar esa respuesta tarde o temprano.

Conclusión

Un daemon persistente que se autoactualiza y que fija el entorno de la primera sesión es una decisión de producto, no un detalle técnico. Es razonable para una app de escritorio o un modo de control remoto; es sorprendente como comportamiento por defecto de una herramienta que el desarrollador invoca desde la terminal, y más cuando la forma de apagarlo no aparece en la referencia oficial de configuración. Para un founder, la lectura útil es doble: primero, controla qué procesos viven en tus máquinas de desarrollo; segundo, cada proveedor de agentes tendrá que demostrar qué código se ejecutó realmente. La adopción de estas herramientas ya está resuelta; la confianza todavía no.

Fuentes

¿te gustó o sirvió lo que leíste?, Por favor, comparte.

WhatsApp X LinkedIn

Leíste lo que hace la IA. ¿Y en tu negocio?

En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.

👥 Probar 7 días