El daemon que sobrevivió a tu terminal: por qué el harness que no puedes gobernar es el riesgo que no puedes medir

Hay una frase que se dice en todas las reuniones de compras de tecnología y que casi nunca se escribe: "si lo hizo un gran lab, debe ser seguro".

Es una frase razonable. Tiene lógica de mercado, tiene lógica de reputación y tiene una ventaja enorme sobre cualquier alternativa: si sale mal, no es tu culpa. Elegiste al proveedor con el mejor equipo de seguridad del mundo. Nadie te va a mirar mal.

El problema es que esa frase no es una evaluación de seguridad. Es una delegación de responsabilidad disfrazada de evaluación de seguridad. Y entre septiembre y octubre de 2026, dos hechos separados por tres semanas la dejaron sin sustento empírico.

El primero: entre mediados de 2025 y mediados de 2026, todos los agentes de código importantes —Claude Code, Cursor, Copilot, Gemini CLI— publicaron al menos un CVE de ejecución remota de código o de exfiltración de datos. El segundo: OpenAI empezó a dejar un daemon corriendo en la máquina de cada usuario de Codex CLI, por defecto, sin preguntar, y con autoactualización cada hora.

Ninguno de los dos fue un backdoor. Y esa es justamente la parte incómoda: no hace falta mala fe para construir la arquitectura que un atacante necesita.

El aviso de rigor antes de seguir: esto no es una acusación de backdoor. El código de Codex CLI es público, el comportamiento está documentado en el repositorio y no hay ningún reporte de exfiltración ni de acceso de OpenAI a equipos de clientes. Todo lo que sigue separa explícitamente lo confirmado de lo que es interpretación. Y la conclusión no depende de atribuir maldad: depende de medir superficie.

1. Qué pasó, exactamente

La cronología importa porque muestra dónde se tomó la decisión. Y la decisión no se tomó en el repositorio público.

El 22 de septiembre de 2026, a las 03:20 UTC, se mergeó el pull request #47179 en openai/codex. El título era una instrucción, no una descripción: "Enable automatic daemon startup by default". La descripción tenía dos frases: promover daemon_auto_start a estable y activarlo por defecto para sesiones interactivas elegibles.

Pero mirá la firma del merge, porque ahí está el dato que casi nadie reportó:

Leé otra vez ese nombre de rama: codex-internal-to-codex-oss. El cambio se escribió, se revisó y se aprobó en el repositorio cerrado de OpenAI. El bot solo lo replicó hacia el código abierto. No hubo discusión pública previa, no hubo RFC, no hubo forma de bloquearlo antes de que entrara.

Tres días después salió Codex CLI 0.157.0, y las notas de release lo mencionaron en una sola línea: "Enabled automatic background-server startup for eligible interactive sessions."

Ese mismo 25 de septiembre, un usuario en Linux bajo WSL2 —que había instalado la versión con npm install -g @openai/codex— notó algo raro en su sistema y abrió el issue #48195. Diecisiete días más tarde, el 12 de octubre, ese issue llegó al primer lugar de Hacker News. En 0.160.0 el comportamiento seguía igual.

Esto es lo que un usuario de Codex CLI tiene hoy en su máquina, según el propio código y el README del daemon:

La consecuencia más concreta es la penúltima fila. Si arrancaste Codex una vez en un proyecto con un GH_TOKEN o un HTTPS_PROXY configurado, ese entorno puede seguir usándose horas después, en otro proyecto, sin que nadie te pregunte. Usuarios del issue reportaron exactamente eso: proxies que se quedan pegados y credenciales que aparecen donde no deberían.

2. Lo que esto NO es (y por qué la honestidad te hace más fuerte)

Sería fácil —y sería un error— escribir este artículo como escándalo. Vamos a lo que es verdad, incluso cuando debilita el titular:

No es un backdoor. No hay una puerta trasera, no hay exfiltración reportada, no hay acceso de OpenAI a la máquina de nadie. Un backdoor es un canal deliberado y oculto. Esto es una feature de conveniencia, anunciada en una línea, con el código a la vista.

No es una decisión maliciosa. La explicación más simple es la correcta: OpenAI está construyendo agentes que sobreviven a la sesión (modo persistente, tareas propias, trabajo hasta que los duermas). Un daemon que mantiene el backend caliente y actualizado es la infraestructura obvia para eso. El default es de producto, no de ataque.

Y no alcanza con decir "es open source". Acá hay un matiz que vale la pena entender, porque se repite en toda la industria: el repositorio es público, sí, pero es un espejo downstream de un monorepo interno. Vos podés leer el código, pero no podés participar de la decisión. No hay revisión previa, no hay veto, no hay gobernanza. Lo que tenés es transparencia post-hoc: te enterás después de que se mergeó, probablemente después de que salió en un release.

Eso no es lo mismo que auditabilidad. Auditar es poder influir; leer es poder enterarte tarde. La distinción importa porque es exactamente la que se borronea cuando alguien dice "pero si es open source".

3. La evidencia: nueve CVEs, un solo patrón

Ahora dejemos el caso puntual y miremos el conjunto, porque acá aparece el argumento que no depende de OpenAI ni de un daemon específico.

Entre mediados de 2025 y mediados de 2026, los agentes de código de frontera acumularon un historial de vulnerabilidades que —leído en orden— no parece una lista de bugs. Parece el mismo bug encontrado muchas veces.

Para agosto de 2026, el conteo de registros CVE entre diciembre de 2025 y julio de 2026 ya era de nueve, sumando también al servidor de referencia mcp-server-git. Y hay un detalle que los propios auditores remarcan: ninguno es una brecha de Anthropic, de Google o de Anysphere. Son vulnerabilidades de producto. No hubo explotación en producción reportada por fuente primaria.

Es decir: no fue que a un lab "se le escapó" algo grave. Fue que todos construyeron la misma clase de error.

Y la clase de error es siempre la misma:

Los casos concretos lo confirman uno por uno:

Claude Code, CVE-2026-21852 (Check Point Research, 27 de abril de 2026): archivos de proyecto maliciosos lograban RCE y robo de tokens de API a través de los hooks y la configuración MCP del agente. Parcheado en 2.0.65. El vector no era el modelo: era el archivo de configuración que el agente lee y obedece.

Cursor, CVE-2026-26268: la propia advisory del vendor dice, textual, que "No user interaction was required as Git executes these commands automatically". Ahí está el problema de fondo: si tu política de seguridad es "yo reviso los comandos que ejecuta el agente", esa política no cubre esta clase de fallo, porque el comando no lo ejecuta el agente: lo ejecuta git, un rato después, solo.

Codex, Heapjack (reportado el 12 de agosto de 2026, parcheado en ocho días, publicado el 20 de septiembre): un componente node_repl que Codex Desktop escribe en ~/.codex/config.toml al momento de instalar. Sin opt-in, sin setting para desactivarlo, y como vive en la configuración compartida, los usuarios del CLI lo heredan sin que nadie les pregunte. El resultado: abrís el repositorio de otra persona, le preguntás algo sobre el código y quien escribió ese repositorio obtiene ejecución de comandos en tu máquina, sin prompt, sin nada en pantalla, incluso desde el modo más restringido del sandbox.

4. La tesis: el riesgo vive en el harness, no en el modelo

Un harness es todo lo que se interpone entre la decisión del modelo de actuar y la acción aterrizando en un sistema real. La definición más precisa que encontré lo enumera sin adornos:

Seis componentes. Ninguno es el modelo. Los seis son los que tienen el privilegio.

Y acá está la asimetría que casi nadie verbaliza: el modelo es la única parte que no podés inspeccionar, y es también la parte con menos privilegio. El modelo no toca tu disco, no lee tu .env, no tiene tu token de GitHub. Lo que tiene todo eso es el harness. El modelo propone; el harness dispone.

Por eso el hallazgo empírico anterior no es una anécdota de seguridad: es una ley de composición. Si todos los CVEs están en el harness, entonces el radio de explosión es una propiedad del harness. Y si el radio de explosión es una propiedad del harness, entonces:

Y ahora la pregunta incómoda: en un agente de vendor, ¿quién gobierna el harness?

No vos. El vendor. Vos sos el inquilino.

5. El contraargumento honesto (donde te van a atacar)

Si publicás la tesis anterior sin este capítulo, te la desarman en un comentario. Porque hay una versión fuerte del argumento contrario y es esta:

Y tiene razón. Vamos a concederlo entero, porque es verdad y porque concederlo es lo que hace defendible el resto:

Concesión 1: "custom" no significa "más seguro". Significa "con menos ojos". La superficie de un agente es enorme y los labs tienen presupuestos de red team que un equipo chico no tiene.

Concesión 2: los labs parchean rápido, y eso es una fortaleza real. Heapjack se reportó el 12 de agosto y se arregló en ocho días. Los dos escapes del sandbox de Codex se reportaron y se parchearon en poco más de una semana. Eso es respuesta de primer nivel, y negarlo sería deshonesto.

Concesión 3: vos vas a escribir bugs igual. Si construís un gate de aprobación, tenés buenas chances de escribir el mismo error de parseo de allowlist que ya se escribió cuatro veces en la industria. No hay inmunidad por ser pequeño.

Entonces, ¿qué queda? Queda una diferencia que no es de calidad: es de naturaleza del riesgo.

Fijate que esto cambia el eje de la discusión. La pregunta deja de ser "¿quién es más competente en seguridad?" —donde el lab gana— y pasa a ser "¿quién puede demostrar qué pasó y detenerlo?" —donde el lab, por diseño, no puede.

6. La versión que resiste: gobernable vs. no gobernable

Entonces no es "custom vs. vendor". Es gobernable vs. no gobernable. Y eso sí se puede medir, con cinco propiedades concretas:

Y ahora volvé a la tercera fila, porque es la que rompe el modelo mental de todo el sector.

Durante años, la respuesta estándar a "hay una vulnerabilidad en tu agente" fue actualizá. Todo el ecosistema de seguridad de software está construido sobre esa premisa: aparece el CVE, sale el parche, actualizás, cerrás el incidente. Es el consejo que dan todas las guías, incluidos los índices de CVEs de agentes de código: "la única pregunta que importa es si estás en una build parcheada".

El daemon de Codex hace que ese consejo no se pueda ejecutar de forma verificable.

Porque el daemon corre su propia copia, la actualiza solo cada hora y la desacopla del gestor de paquetes. Podés pinear tu instalación de npm con precisión quirúrgica y el proceso que realmente atiende las sesiones puede estar en otra versión. La mitigación que todos creíamos tener —fijar la versión y auditar el cambio— deja de ser un control y se convierte en una ilusión administrativa.

7. El caso Wagner: la prueba que sí tenemos en casa

Este artículo no es teoría. En Wagner Solutions operamos un harness propio, y lo medimos. Dos datos, de nuestro propio laboratorio:

El punto no es que nuestro harness sea más seguro que Codex. El punto es lo que pudimos hacer cuando falló. Sabemos exactamente qué versión corrió, qué archivos tocó, cuánto tardó y por qué falló. Podemos revertir, podemos apagar, podemos probar. No tuvimos que abrir un ticket ni esperar un release.

Y hay un detalle que vale más que cualquier benchmark: en v2 el agente dijo que había terminado, y no había hecho nada. Sin un verificador adversarial que mida el estado del mundo en vez de creerle al reporte, ese fallo es invisible. Eso no lo arregla un modelo mejor. Lo arregla un harness que no le cree al agente.

8. El test de las cuatro preguntas

Si de todo esto te llevás una sola herramienta, que sea esta. Antes de instalar cualquier agente de código —de OpenAI, de Anthropic, de Google o de quien sea— hacé cuatro preguntas y exigí respuestas verificables, no de marketing:

9. Por qué el mercado elige la coartada

Y acá viene la parte incómoda, la que explica por qué este artículo va a tener razón y aun así no va a cambiar el comportamiento del mercado.

Porque comprarle al lab no es una decisión de seguridad. Es una transferencia de responsabilidad.

Cuando elegís el agente del gran proveedor, comprás algo que ningún harness propio puede darte: la respuesta a "¿y por qué elegiste eso?". Si el agente del lab filtra credenciales, es un incidente del vendor. Si tu harness propio filtra credenciales, es tu incidente. El costo reputacional es asimétrico, y los incentivos del que decide no coinciden con los del que se expone.

Nadie fue despedido por elegir OpenAI. Esa frase no es un chiste: es una descripción del criterio de compra real.

Y hay una ironía final. La misma estructura de incentivos que hace racional comprar la coartada es la que produce el daemon: un default que minimiza fricción comercial (el backend siempre caliente, el agente siempre disponible, cero configuración) y maximiza superficie. Nadie escribió un backdoor. Escribieron la opción más cómoda, y la comodidad resultó ser el vector.

El agente que sobrevive al cierre de tu terminal no es el problema. El problema es que te enteraste tres semanas después, por un issue de GitHub, y que tu único control —la versión que creías estar corriendo— no era el que estaba corriendo.

Eso no se arregla con un modelo mejor. Se arregla con un harness que puedas gobernar.