Codex comienza a cifrar los prompts de subagentes

• MultiAgentV2 de Codex CLI cifró los mensajes spawn_agent, send_message y followup_task, lo que provocó una regresión en la traza de auditoría donde el contenido delegado deja de ser legible para humanos en el rollout padre, el historial y el rastreo
• Desde el PR #26210, fusionado el 5 de junio de 2026, InterAgentCommunication.content queda vacío y el payload se guarda solo en encrypted_content, mientras que el historial del receptor y los logs de comunicación también registran texto cifrado
• El problema es independiente de la suscripción, el modelo o la plataforma, y afecta a los builds posteriores a la 0.137.0 con MultiAgentV2 activado; es distinto de #26753, que trata fallas de validación de solicitudes en el esquema de herramientas cifradas
• La corrección propuesta consiste en conservar tanto el message cifrado para el modelo receptor como un campo obligatorio en texto plano para auditoría local, usando el cifrado o un ID para identificar la entrega y aplicando el mismo límite de tamaño a los datos de auditoría en texto plano
• Ya existe un prototipo para spawn_agent en un commit snapshot separado, pero aún falta aplicar el mismo contrato a send_message, followup_task y a las pantallas de historial, reproducción y depuración; el issue sigue abierto

---

Alcance del problema y condiciones de la regresión

• El PR de cambio de cifrado #26210 se fusionó el 5 de junio de 2026, y afecta a los builds posteriores a la 0.137.0 que lo incluyan y tengan MultiAgentV2 activado
• Las herramientas afectadas son spawn_agent, send_message y followup_task, y no depende de la suscripción, el modelo, el sistema operativo ni el entorno de terminal
• Como es una regresión observable en el comportamiento del código ya fusionado, y no en el estado del entorno local, el reporte de Codex doctor no aplica
• Los pasos de reproducción son los siguientes
  1. Activar MultiAgentV2 en un build que incluya el PR #26210
  2. Hacer que el modelo invoque spawn_agent, send_message o followup_task
  3. Revisar la tarea del subagente en el rollout padre, el historial o el rastreo
  4. En lugar del cuerpo de la tarea o del mensaje, solo aparece texto cifrado

Información de auditoría local que desapareció

• El cifrado de la entrega en sí puede entenderse como una mejora de privacidad, pero la implementación actual también elimina el contenido legible por humanos del historial local de rollout, los resúmenes de rastreo y las pantallas de auditoría y depuración del lado padre
• Como resultado, en una revisión posterior del rollout se vuelve difícil responder preguntas como estas
  • Qué tarea le asignó spawn_agent al agente hijo
  • Qué mensaje se envió al subagente
  • Por qué se creó un hilo hijo específico
• El issue #26753 trata un problema donde el esquema de herramientas cifradas devuelve errores 400 durante la validación de solicitudes, mientras que este issue se enfoca en la auditabilidad y depurabilidad después de que el esquema ya fue aprobado
• El objetivo no es necesariamente revertir la entrega cifrada, sino mantener el cifrado y al mismo tiempo permitir leer localmente el contenido delegado

Flujo de datos en el código actual

• InterAgentCommunication::new_encrypted() inicializa content como cadena vacía y guarda el payload solo en encrypted_content
  • El constructor normal new() guarda el texto plano en content y deja encrypted_content vacío
  • El constructor cifrado hace lo contrario: vacía content y coloca el valor en encrypted_content
• to_model_input_item() pone en ResponseItem::AgentMessage solo el encabezado NEW_TASK o MESSAGE y el payload cifrado cuando existe encrypted_content
  • Por eso, aunque en runtime se complete content, no se persiste automáticamente un ResponseItem legible
  • Se necesita una ruta de almacenamiento de auditoría local separada
• communication_from_tool_message() pasa directamente el message de la herramienta a new_encrypted(), creando un objeto de comunicación sin content en texto plano
• El procesamiento de argumentos de send_message y followup_task solo deserializa target y el message cifrado
  • Un message vacío se rechaza, pero no existe un campo complementario aparte para texto plano
  • La ruta compartida de entrega de mensajes usa ese valor tal cual para crear InterAgentCommunication

Por qué el historial y los logs conservan texto cifrado

• La ruta de registro del lado receptor guarda en el historial de conversación y en el rollout el ResponseItem para el modelo que genera to_model_input_item()
  • En una comunicación cifrada, ese elemento contiene el payload de entrega cifrado y no un texto de auditoría legible
  • En el rollout se persisten juntos InterAgentCommunicationMetadata y ese ResponseItem
• El log estructurado de comunicación también sustituye content por encrypted_content como content del evento cuando content está vacío
• En esta estructura, incluso los campos que deberían mostrarse como mensajes legibles terminan conteniendo texto cifrado, así que no se separa el requisito de mantener el cifrado de entrega del de conservar datos de auditoría local

Contrato de doble contenido propuesto

• El message cifrado existente se mantiene como payload de entrega para el modelo receptor
• Se añade un campo obligatorio de auditoría en texto plano a cada herramienta de comunicación de MultiAgentV2
  • spawn_agent: task_message
  • send_message, followup_task: un nombre consistente como task_message o message_text
• En el límite del handler, se rechazan valores vacíos para esa auditoría en texto plano
• InterAgentCommunication almacena ambos valores
  • encrypted_content: el message cifrado
  • content: una copia legible para auditoría
• to_model_input_item() no cambia, de modo que al modelo receptor se le sigue entregando solo el texto cifrado, no la copia local de auditoría
• Las invocaciones de herramientas padre y los rollouts persisten el campo en texto plano, y también lo conservan en las aristas de interacción del rastreo estructurado y en los logs locales de comunicación
• La correlación entre la invocación de la herramienta y los elementos de entrega al hijo se determina por texto cifrado o ID, no por coincidencia de texto plano
  • El campo en texto plano es metadato de auditoría y no reemplaza el identificador de la entrega cifrada
• Al nuevo campo de auditoría en texto plano se le aplica el mismo límite de tamaño que al mensaje delegado correspondiente, para evitar que el rollout o los elementos de contexto crezcan sin límite

Prototipo de spawn_agent y trabajo pendiente

• El commit snapshot ignatremizov@df9a7c4 implementa la estructura propuesta para spawn_agent
• El esquema v2 de spawn_agent define task_message como campo obligatorio
• Después de realizar la validación de task_message, se construyen juntos el texto plano y el cifrado
  • content contiene la copia de auditoría en texto plano
  • encrypted_content mantiene el payload cifrado para el modelo receptor
• En el resumen de rastreo del rollout también se separan el contenido de auditoría y el contenido de coincidencia de entrega y se vincula la entrega mediante el cifrado mientras se aplica el contenido de auditoría en texto plano
• El trabajo pendiente es aplicar este mismo contrato de doble contenido a send_message y followup_task, y hacer que todas las pantallas de historial, reproducción y depuración orientadas al usuario lean la copia de auditoría en lugar del texto cifrado

Criterios de finalización y estado actual

• En el rollout padre y el historial debe poder leerse el texto plano de spawn_agent, send_message y followup_task v2
• Incluso con el cifrado activado, el modelo hijo debe recibir solo el payload cifrado de entrega
• Las aristas estructuradas del rastreo de rollout deben incluir message_content en texto plano con tamaño limitado
• Los logs de comunicación deben usar el contenido de auditoría en texto plano cuando exista, y no sustituir los campos de mensaje legible con texto cifrado
• La reanudación y reproducción deben conservar la copia de auditoría, pero no inyectarla en el contexto del modelo hijo
• El comportamiento existente de comunicación v1 en texto plano no debe cambiar
• Se necesitan pruebas de regresión para las tres herramientas v2 que validen tanto los datos locales de auditoría legibles como la entrada cifrada al modelo receptor
• En la página proporcionada, el issue sigue en estado Open y no hay indicios de que la corrección ya haya sido fusionada en el repositorio principal

[GN⁺]

Opiniones en Hacker News

• Este título se presta a malentendidos. Más precisamente, significa que Codex empezó a cifrar los prompts de los subagentes para ocultárselos al usuario.
  El título original era “Codex starts encrypting prompts, uses ciphertext for inference instead”.

  • Parece muy probable que se haya introducido porque el modo ultra de GPT-5.6 distribuye el trabajo entre varios subagentes. Antes, este modo solo estaba disponible en la UI web, y probablemente correspondía al antiguo modo pro.
    Si lo entrenaron con rollouts completos de aprendizaje por refuerzo en los que los agentes interactúan entre sí, parece que OpenAI quiere tratar estos prompts como rastros de razonamiento en bruto, para impedir que otros los usen directamente para entrenar.
    También hay indicios de que el blob de compresión opaco que devuelve el endpoint dedicado de compresión podría no ser texto, sino una representación en el espacio latente de la conversación; y el hecho de que la fidelidad de compresión de OpenAI sea mucho mayor que la de otros proveedores refuerza esta suposición. Podrían haber aplicado una técnica similar a los prompts de subagentes, y me da curiosidad si también usan blobs cifrados al generar subagentes de distintos tipos de modelo.
  • Que en una computadora local se ejecuten decenas o cientos de agentes probabilísticos, y que ni siquiera puedas inspeccionar las instrucciones que recibieron esos agentes, es absurdo.
    Al revisar subagentes y flujos de trabajo de Claude, alguna vez llegué a la conclusión de que “esto no debió ejecutarse en primer lugar”; en cambio, los usuarios de Codex tienen que gastar tokens a ciegas en instrucciones de delegación cifradas y tareas de shell que el orquestador les pasa a los subagentes.
  • Es probable que una parte importante de la propiedad intelectual de Codex esté en la composición, el orden y la orquestación de prompts, más que en el código base.
    Nosotros también intentamos permitir que las empresas eligieran su proveedor de IA preferido u obligatorio y sus propias claves de API, además de ofrecer un plan de precios simple, pero pronto nos dimos cuenta de que los prompts del backend podían filtrarse a los clientes. Si alguien conseguía rastros de ejecución detallados, podía hacer ingeniería inversa de lo que hacemos con relativa facilidad, así que finalmente abandonamos esa idea.
  • Al principio pensé que era alguna tecnología como el cifrado homomórfico, pero al final parece simple codicia.
  • No es la primera vez que Codex cifra algo. Su excelente endpoint de compresión lleva al menos 5 meses devolviendo enormes blobs cifrados.

• Ahora entiendo por qué mi herramienta local para inspeccionar sesiones de agentes de programación dejó de funcionar en algunas situaciones.
  Es una decisión de diseño interesante: me pregunto cuánta gente aceptará comandos externos cifrados que se ejecutarán en la computadora del usuario.

  • Los incentivos de OpenAI no parecen estar exactamente alineados con los de los usuarios, incluidos los clientes empresariales. Vale la pena revisar también comentarios recientes de Alex Karp y Satya Nadella.
    Ocultar el contenido al usuario mediante cifrado es la misma estrategia que usaba la RIAA con el DRM por miedo a la infracción de copyright; me pregunto si esto también es una decisión hostil hacia el usuario.
  • Si usas el modo YOLO, ya estás asumiendo ese riesgo, y lo importante son las llamadas a herramientas. Las llamadas a herramientas en sí no se pueden cifrar.

• Por este tipo de comportamiento sigo usando el endpoint de Chat Completions. OpenAI ha estado empujando sutilmente a los usuarios a salir de Chat Completions y pasar a la Responses API, que es más fácil de ofuscar.
  En Chat Completions puedes controlar directamente el procedimiento de razonamiento; si activas funciones experimentales y configuras algunas opciones algo confusas, incluso puedes crear un agente personalizado de búsqueda de árbol de Monte Carlo (MCTS) con el modelo GPT-5.6 actual.
  En VS Copilot se puede usar hasta gpt5.5 con el token de API del usuario y la configuración del modelo, pero la familia gpt5.6 no funciona actualmente. Supongo que es porque no fuerza reasoning_effort a none para satisfacer el nuevo comportamiento de aumento de barreras de entrada.

  • Me da curiosidad qué es exactamente la técnica MCTS mencionada aquí. De todos modos, el proceso de pensamiento que se proporciona está resumido de forma demasiado abstracta y no sirve de mucho; también dudo que realmente puedas controlar por completo el procedimiento de razonamiento.
  • MCTS es la sigla de búsqueda de árbol de Monte Carlo (Monte Carlo Tree Search).
  • Preferiría que aquí no se abuse de MCTS como palabra de moda. El método al que se refiere no es MCTS en sentido estricto.
  • Responses API ofrece muchas ventajas sobre Chat Completions: https://developers.openai.com/api/docs/guides/migrate-to-res...
    Todos los modelos nuevos que están saliendo hoy son modelos de razonamiento, así que, según las recomendaciones, hay que usar Responses API.

• Me pregunto si podrían bloquear el uso de las suscripciones de GPT en herramientas de ejecución alternativas. Si no lo hacen, no sería un gran problema, y codex cli en sí es una herramienta de ejecución sorprendentemente común y corriente.

  • Parece poco probable. Toda la arquitectura de app-server existe justamente para soportar ese tipo de integración, así que para quitarlo de Codex tendrían que desarmar una parte enorme.
    Yo también uso Codex más que nada porque es muy fácil integrarlo con la API RPC de app-server, y ahora lo uso casi todo a través de una integración propia, más que mediante la TUI pública de Codex.
    Pero si cifran en el disco local el input real de inferencia, como los prompts, para que solo el backend de OpenAI pueda verlo, aunque la integración siga siendo fácil, ya no se podrá entender qué está ocurriendo. Me cuesta entender por qué el equipo consideró que esto era una buena opción.
  • Anthropic y Google ya cobran cargos adicionales si usas sus propias herramientas de ejecución, y esa es toda la razón para usar OpenAI.
    Si OpenAI toma el mismo camino, pienso volver a Claude o comprar otro Spark para ejecutarlo localmente.
  • Mientras Anthropic vaya por delante en adopción empresarial, no creo que lo bloqueen. No sé qué cambiará si OpenAI se pone al frente con una gran ventaja, pero espero que para entonces los modelos abiertos sean mejores que gpt-5.6 sol.
  • Como Codex mismo empezó a ofrecer un proxy que envuelve la suscripción, parece poco probable que lo bloqueen.
    https://github.com/openai/codex/blob/main/codex-rs/responses...
  • Recientemente, Tibo de OpenAI pidió en Twitter que compartieran cómo ejecutar GPT con Claude Code, así que no parece que estén en contra del uso de herramientas de ejecución alternativas.

• El título anterior en HN era muy engañoso, porque sonaba como si se estuviera haciendo inferencia directamente sobre texto cifrado. Para eso haría falta cifrado homomórfico mucho más avanzado que lo que se conoce actualmente.

  • En realidad, lo que hicieron fue cifrar lo que el agente le envía al subagente, para que solo el backend de OpenAI pueda ver el texto en claro.
    Antes, el agente enviaba prompts en texto claro al subagente, y también quedaban tal cual en los logs y datos de sesión, así que incluso al usar la función experimental de subagentes se podían abrir los datos y ver el funcionamiento interno.
    Ahora, si usas Sol o Terra, se le pasa al subagente un texto cifrado creado por el backend, y el subagente lo vuelve a usar para la inferencia en el backend de OpenAI. Luna no parece estar afectado, y no se cifra toda la sesión, sino solo los mensajes delegados entre agentes.
    La inferencia interna de OpenAI no ocurre sobre el texto cifrado, pero para el usuario local solo se ve texto cifrado en vez de texto en claro. Para aclararlo, cambié el título a “Codex starts encrypting sub-agent prompts”.
  • Como el título incluía “inferencing”, yo también pensé de inmediato en cifrado homomórfico u operaciones sobre texto cifrado.

• Recientemente hubo un reporte en Twitter de que un subagente GPT-5.6 borró por error el directorio home de un usuario.
  Me pregunto si, al impedir ver qué intenta hacer el subagente, también terminaron fallando las salvaguardas.
  https://x.com/mattshumer_/status/2076794038456385546?s=20

• Esto es una forma de pasar claves de caché a través del cliente para reducir el uso de tokens. Como se puede eludir fácilmente usando otras herramientas de subtareas, no puede ser una defensa contra la destilación de modelos.

• Me pregunto exactamente dónde ocurre el cifrado. Yo pensaba que el agente principal llamaba localmente al subagente, pero me queda la duda de si Codex está estructurado para llamar al subagente desde los servidores de OpenAI antes de llegar al entorno local.

  • Antes, el agente enviaba al subagente un prompt en texto claro, y quedaba tal cual en los logs y datos de sesión, por lo que era fácil inspeccionar el funcionamiento interno.
    En Sol o Terra, en lugar del prompt se entrega un texto cifrado generado por el backend de OpenAI, y el subagente lo vuelve a usar para la inferencia en el backend. Luna no parece estar afectado, y como no se cifra toda la sesión sino solo los mensajes delegados entre agentes, ahora ese contenido solo puede descifrarlo el backend de OpenAI.

• Me preguntaba por qué desde ayer no funcionaba el servicio de reventa del mercado negro chino; probablemente se deba a este cambio.

  • Estos mercados negros no solo agrupan suscripciones para revenderlas, sino que también almacenan datos y luego los venden a lugares que entrenan modelos. El cifrado sirve para bloquear al menos esto último, y aunque el objetivo es el mismo que el de otros métodos revelados antes, la implementación es mucho más limpia.

• El objetivo principal parece ser dificultar los intentos de proxyear grandes volúmenes de solicitudes y respuestas de usuarios para usarlos en el entrenamiento de modelos competidores.

  • Parece claro que quieren impedir que otros proveedores vean cómo OpenAI gestiona sistemas multiagente.
    Pero es una implementación pésima, porque los usuarios pagos no tienen ninguna forma de averiguar la causa cuando algo sale mal, lo que hace difícil usar bien la función multiagente.