Un mensaje que un agente le envía a otro dentro de Codex CLI ya no queda legible en el historial local. Desde el , abierto el 13 de junio de 2026 por el usuario ignatremizov en el repositorio (más de 98.000 estrellas y 14.600 forks) fue abierto el 13 de junio de 2026 por ignatremizov.- La causa es el , que reporta errores 400 al validar esquemas cifrados, no un problema de auditoría.- La solución propuesta agrega un campo de auditoría sin cifrar, separado del payload que recibe el modelo.- Al cierre de esta nota el issue seguía abierto, sin un pull request de fix vinculado.
Introducción
Codex CLI es la herramienta de línea de comandos de OpenAI para trabajar con agentes de código. Su función MultiAgentV2 permite que un agente padre reparta trabajo entre varios subagentes: uno revisa tests, otro refactoriza un módulo, otro investiga un bug. Para que eso funcione, los agentes se mandan mensajes entre sí usando tres llamadas de herramienta: spawn_agent (crear un subagente con una tarea), send_message (mandarle contexto adicional) y followup_task (asignarle una tarea de seguimiento).
Hasta la versión 0.137.0, esos mensajes se guardaban en texto plano dentro del historial local (rollout), lo que permitía a cualquier desarrollador revisar después qué le había pedido un agente a otro. El PR #26210 cambió eso a propósito, como parte de un endurecimiento de privacidad para el transporte de mensajes entre agentes. El problema, según documenta el issue #28058, es que ese cambio no distingue entre cifrado para el modelo y legible para el humano que audita.
Ese historial no es un detalle cosmético. Equipos que usan Codex CLI en entornos de trabajo colaborativos dependen del rollout para responder preguntas después de que ocurrió el trabajo: qué le pidió un agente a otro, en qué orden, y si el resultado se desvió de la tarea original. Cuando esa fuente deja de ser legible, la auditoría pasa a depender de que alguien haya guardado el prompt original en otro lado, algo que no todos los flujos de trabajo hacen por defecto.
Qué pasó
El reporte es preciso sobre el mecanismo. La estructura InterAgentCommunication, definida en codex-rs/protocol/src/protocol.rs (líneas 735 a 791 del commit fde21ba), tiene dos campos relevantes: content, un String de texto plano, y encrypted_content, un Option<String> opcional. El constructor original, new(), llena content con el texto real y deja encrypted_content en None.
El constructor nuevo, new_encrypted(), invierte esa lógica: inicializa content como cadena vacía y guarda el mensaje únicamente en encrypted_content. Cuando MultiAgentV2 cifra la entrega a un subagente, usa new_encrypted(). El resultado es que el historial local, la reducción de traza y cualquier superficie de depuración del lado del agente padre pierden el texto legible de la tarea o el mensaje.
El autor del issue lo resume con tres preguntas concretas que, después del cambio, ya no se pueden responder inspeccionando el rollout: qué tarea recibió un subagente en un spawn_agent, qué mensaje se le mandó con send_message, y por qué existía un hilo hijo determinado al revisar el historial más tarde.
Contexto e historia del cifrado en MultiAgentV2
MultiAgentV2 es la segunda generación del sistema de subagentes de Codex CLI: la primera versión coordinaba agentes con mensajes en texto plano de punta a punta. El cifrado que introdujo el PR #26210 busca que el contenido de un mensaje entre agentes no quede expuesto en superficies donde no debería, algo razonable si Codex CLI corre en entornos compartidos o si el payload viaja por canales que un tercero podría inspeccionar.
El propio reporte aclara que no está pidiendo revertir esa entrega cifrada. La objeción es más específica: cifrar la entrega al modelo no debería implicar borrar, también, la copia legible que un humano necesita para auditar qué se delegó. Son dos preocupaciones distintas que el PR #26210 resolvió con un solo mecanismo.
Vale la pena distinguir este issue del , con las etiquetas CLI, bug y subagent, sin un pull request de corrección vinculado todavía. El reporte deja explícita la forma que debería tener el fix: un campo de auditoría no cifrado, independiente del message que ve el modelo, guardado en los metadatos de rollout, historial y traza.
Para equipos que ya corren MultiAgentV2 en flujos donde la auditoría importa (revisión de cumplimiento, depuración de incidentes, control de qué le delegan sus agentes a otros agentes), la recomendación práctica hasta que exista un fix es no depender del rollout cifrado como única fuente de verdad: registrar la tarea del lado del orquestador antes de que MultiAgentV2 la cifre.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré grep -o "encrypted_content" ~/.codex/sessions/*/rollout.jsonl sobre tu propia sesión de MultiAgentV2 y confirmá si tu historial local ya perdió el texto legible de las tareas delegadas.
Preguntas frecuentes
¿Qué es MultiAgentV2 en Codex CLI?
Es el sistema de Codex CLI que permite que un agente coordine subagentes usando las llamadas spawn_agent, send_message y followup_task para repartir tareas de código entre varios agentes.
¿Qué cambió exactamente el PR #26210?
Cifró el payload del mensaje que ve el modelo destinatario y, como efecto colateral, dejó vacío el campo content que antes guardaba el texto legible en el historial local.
¿Cómo sé si mi instalación está afectada?
Si corrés una build posterior a la 0.137.0 con MultiAgentV2 habilitado, revisá tus archivos de rollout: si ves encrypted_content lleno y content vacío en los mensajes entre agentes, estás viendo el comportamiento del issue #28058.
¿El cifrado en sí tiene alguna falla de seguridad?
No según lo que documenta el issue. El reclamo no es sobre la fortaleza del cifrado, sino sobre la pérdida de una copia legible para auditoría humana local.
¿En qué se diferencia del issue #26753?
El #26753 describe errores 400 al validar el esquema de herramientas cifradas cuando el modelo no está configurado para aceptarlas: la llamada falla antes de completarse. El #28058 ocurre después, cuando el mensaje ya se entregó con éxito pero no queda registro legible de su contenido.
¿Ya existe una corrección disponible?
No al momento de esta nota. El issue seguía abierto, sin pull request de fix vinculado, aunque el reporte propone una solución concreta: un campo de auditoría sin cifrar, separado del payload cifrado.
Referencias
: cambio que introduce el cifrado de mensajes en MultiAgentV2.- : repositorio principal de Codex 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.
SOCIAL SHARE CARD GENERATOR