El investigador Oren Yomtov de Accomplish AI divulgó el 15 de septiembre de 2026 dos fugas de sandbox de Codex. BleepingComputer informó los hallazgos el 20 de septiembre y dijo que OpenAI había solucionado los problemas en agosto. El problema más grave, llamado Heapjack por el investigador, se describió como ejecución de comandos sin sandbox desde el modo read-only. El segundo, llamado Overpatch, ampliaba la autoridad de escritura de archivos mediante la ruta de parches en modo workspace-write.
La acción inmediata para usuarios es clara: actualizar Codex CLI y Codex Desktop a versiones corregidas o posteriores. La consecuencia de gobernanza es más amplia. Un agente de código que revisa repositorios no confiables no solo lee código. Recorre instrucciones, helpers, herramientas, operaciones de archivo y puntos locales de integración. Si el límite alrededor de esos componentes es débil, una revisión rutinaria puede convertirse en una ruta de acción a nivel del host.
Qué se divulgó
Accomplish dijo que informó ambas fallas a OpenAI el 12 de agosto de 2026 y que ambas fueron corregidas en ocho días. Su informe identificó Codex CLI 0.149.0 como la versión mínima corregida para Overpatch y Codex Desktop build 26.818.21641 como la versión mínima corregida para Heapjack. BleepingComputer resumió de forma independiente las mismas rutas afectadas y reportó una declaración de OpenAI agradeciendo a los investigadores y diciendo que los problemas habían sido tratados.
El registro público revisado aquí no demuestra explotación en el mundo real. Tampoco significa que toda instalación de Codex fuera vulnerable al momento de publicación. Es una historia de divulgación y respuesta, no evidencia de una intrusión confirmada en clientes.
Por qué importa Heapjack
Heapjack es la lección de control más importante porque apunta a un límite de confianza dentro de un helper. Accomplish dijo que la herramienta JavaScript de Codex Desktop usaba contextos confiables y no confiables dentro de un solo proceso Node.js. El lado confiable usaba un token para probar autoridad ante un proceso padre nativo. El problema, según el informe, fue que ambos contextos compartían el mismo heap de V8, por lo que el código no confiable podía buscar el token en datos de memoria y enviar solicitudes al padre.
Ese patrón es común en sistemas de agentes. Un equipo puede decir que el modelo está dentro de una sandbox, mientras herramientas auxiliares, puentes de runtime, extensiones de navegador o servidores MCP llevan autoridad fuera de ella. La revisión de seguridad debe preguntar dónde vive la autoridad real, qué rutas de memoria e IPC cruzan el límite y si el agente puede influir en el proceso que aplica sus límites.
Por qué importa Overpatch
Overpatch tiene otra forma. Involucró la ruta de parches que decide dónde puede escribir el agente. Accomplish describió una técnica en la que nombrar una ruta como un directorio padre ampliaba el acceso de escritura y luego una ruta mediante enlace simbólico permitía escribir fuera del espacio de trabajo previsto. La versión corregida importa, pero la lección de diseño importa más: las herramientas que modifican archivos son motores de política, incluso cuando parecen comodidad para desarrolladores.
Para agentes de código, la política de escritura debe ser explícita e inspeccionable. La guía de aprobaciones de Maetra trata de acciones con consecuencias, pero el mismo principio aplica al desarrollo local: escribir fuera del espacio de tarea es otra clase de acción y debe llevar una barrera más fuerte.
Qué deben inventariar los equipos
La primera tarea defensiva no es un lema sobre IA segura. Es inventario. Los equipos deben saber qué agentes de código están instalados, qué helpers de escritorio están habilitados, qué versiones de CLI se usan, qué configuración global se escribió y qué repositorios se tratan como no confiables. La guía de Maetra para descubrir agentes da un modelo práctico para conectar agentes, propietarios, herramientas e historial de cambios.
La segunda tarea es evidencia. Un parche no está completo solo porque un gestor de paquetes diga que la versión cambió. Los equipos necesitan registros de versiones instaladas, estado de reinicio, cambios de configuración y cualquier actividad previa sospechosa. La guía de Maetra sobre registros de auditoría de IA explica por qué un revisor posterior necesita la solicitud, la política, la llamada de herramienta y el efecto observado, no solo el estado final del ticket.
Análisis de Maetra
La divulgación de Codex recuerda que los guardrails de agentes no pueden vivir todos dentro del propio agente. Las reglas de prompt, el comportamiento del modelo y las etiquetas de espacio de trabajo ayudan, pero los controles más fuertes se ubican fuera del componente que se intenta contener. Para agentes de código, eso significa política de herramientas versionada, helpers aislados, confianza explícita en repositorios, permisos de escritura estrechos, sockets monitoreados y un rastro de evidencia que sobrevive al fin de la sesión.
Los equipos deben evitar exagerar la divulgación. Los problemas reportados fueron corregidos rápido, y ninguna fuente pública revisada aquí prueba explotación activa. Aun así, el problema de control subyacente es duradero: las máquinas de desarrollo ahora ejecutan agentes que inspeccionan código hostil y se conectan a herramientas locales poderosas. Trate esos agentes como automatización privilegiada, no como ventanas de chat con tema de código.