Codex começa a criptografar prompts de subagentes

• O MultiAgentV2 do Codex CLI passou a criptografar mensagens de spawn_agent, send_message e followup_task, causando uma regressão na trilha de auditoria em que o conteúdo delegado deixa de ser legível por humanos no rollout, histórico e rastreamento do agente pai
• Após o PR #26210, incorporado em 5 de junho de 2026, InterAgentCommunication.content fica vazio e o payload é armazenado apenas em encrypted_content; o histórico do destinatário e os logs de comunicação também registram texto cifrado
• O problema independe de assinatura, modelo e plataforma, afeta builds a partir da 0.137.0 com MultiAgentV2 ativado e é separado da #26753, que trata de falhas de validação de requisição no schema da ferramenta de criptografia
• A correção proposta é manter tanto a message criptografada para o modelo receptor quanto um campo obrigatório em texto claro para auditoria local, usando texto cifrado ou ID para identificação da entrega e aplicando o mesmo limite de tamanho aos dados de auditoria em texto claro
• Um protótipo para spawn_agent foi implementado em um commit snapshot separado, mas ainda falta aplicar o mesmo contrato a send_message e followup_task, além das telas de histórico, replay e debug; a issue ainda está Open

---

Escopo de ocorrência e condições da regressão

• O PR de alteração de criptografia #26210 foi incorporado em 5 de junho de 2026, e o alvo são builds a partir da 0.137.0 que o incluem e ativam o MultiAgentV2
• As ferramentas afetadas são spawn_agent, send_message e followup_task, independentemente de assinatura, modelo, sistema operacional ou ambiente de terminal
• Como é uma regressão confirmada no comportamento do código incorporado, e não no estado do ambiente local, o relatório do Codex doctor não se aplica
• O procedimento de reprodução é o seguinte
  1. Ativar o MultiAgentV2 em um build que inclua o PR #26210
  2. Fazer o modelo chamar uma das ferramentas spawn_agent, send_message ou followup_task
  3. Verificar a tarefa do subagente no rollout, histórico ou rastreamento do agente pai
  4. Apenas texto cifrado aparece no lugar da tarefa ou do corpo da mensagem

Informações de auditoria local que desapareceram

• A entrega criptografada em si pode ser entendida como um reforço de privacidade, mas a implementação atual remove o conteúdo legível por humanos também do histórico de rollout local, dos resumos de rastreamento e das telas de auditoria/debug do lado do agente pai
• Como resultado, fica difícil responder às seguintes perguntas em uma revisão posterior do rollout
  • Que tarefa o spawn_agent atribuiu ao agente filho
  • Que mensagem foi enviada ao subagente
  • Por que uma determinada thread filha foi criada
• A issue #26753 trata de um problema em que o schema da ferramenta de criptografia retorna erro 400 durante a validação da requisição; esta issue trata da auditabilidade e capacidade de depuração depois que o schema é aprovado
• O objetivo não é necessariamente reverter a entrega criptografada, mas permitir a leitura local do conteúdo delegado mantendo a criptografia

Fluxo de dados no código atual

• InterAgentCommunication::new_encrypted() inicializa content como uma string vazia e armazena o payload apenas em encrypted_content
  • O construtor comum new() armazena o texto claro em content e deixa encrypted_content vazio
  • O construtor criptografado faz o inverso: esvazia content e coloca o valor em encrypted_content
• to_model_input_item(), quando há encrypted_content, coloca apenas o cabeçalho NEW_TASK ou MESSAGE e o payload criptografado em ResponseItem::AgentMessage
  • Portanto, mesmo que apenas o content em tempo de execução seja preenchido, um ResponseItem legível não é automaticamente persistido
  • É necessário um caminho separado de armazenamento para auditoria local
• communication_from_tool_message() passa a message da ferramenta diretamente para new_encrypted(), criando um objeto de comunicação sem content em texto claro
• O processamento dos argumentos de send_message e followup_task desserializa apenas target e a message criptografada
  • Mensagens vazias são rejeitadas, mas não há um campo acompanhante separado em texto claro
  • O caminho compartilhado de entrega de mensagens usa esse valor diretamente na criação de InterAgentCommunication

Por que o histórico e os logs ficam com texto cifrado

• O caminho de registro no lado receptor salva no histórico da conversa e no rollout o ResponseItem para o modelo criado por to_model_input_item()
  • Em comunicações criptografadas, esse item contém o payload de entrega criptografado, não uma frase de auditoria legível
  • O InterAgentCommunicationMetadata e o respectivo ResponseItem são persistidos juntos no rollout
• O log de comunicação estruturado também substitui o content do evento por encrypted_content quando content está vazio
• Nessa estrutura, o texto cifrado entra até nos campos exibidos como mensagem legível por humanos, portanto os requisitos de manter a criptografia da entrega e de preservar dados de auditoria local não estão separados

Contrato proposto de conteúdo duplo

• A message criptografada existente é mantida como payload de entrega para o modelo receptor
• Um campo obrigatório de auditoria em texto claro é adicionado a cada ferramenta de comunicação do MultiAgentV2
  • spawn_agent: task_message
  • send_message, followup_task: um nome consistente, como task_message ou message_text
• Valores de auditoria em texto claro vazios são rejeitados na fronteira do handler
• InterAgentCommunication passa a armazenar os dois valores juntos
  • encrypted_content: message criptografada
  • content: cópia de auditoria legível por humanos
• to_model_input_item() não é alterado, de modo que apenas o texto cifrado seja entregue ao modelo receptor, não a cópia de auditoria local
• O campo em texto claro é persistido na chamada da ferramenta do agente pai e no rollout, e também mantido nas arestas de interação do rastreamento estruturado e no log local de comunicação
• A correlação entre a chamada da ferramenta e o item entregue ao agente filho é determinada por texto cifrado ou ID, não por correspondência de texto claro
  • O campo em texto claro é metadado de auditoria e não substitui o identificador da entrega criptografada
• O novo campo de auditoria em texto claro recebe o mesmo limite obrigatório de tamanho da mensagem de delegação correspondente, para impedir que itens de rollout ou contexto cresçam sem limite

Protótipo de spawn_agent e trabalho restante

• O commit snapshot ignatremizov@df9a7c4 implementa a estrutura proposta para spawn_agent
• O schema v2 de spawn_agent define task_message como campo obrigatório
• Depois da validação de task_message, o código compõe texto claro e texto cifrado juntos
  • content recebe a cópia de auditoria em texto claro
  • encrypted_content mantém o payload criptografado para o modelo receptor
• Na redução do rastreamento de rollout, o conteúdo de auditoria e o conteúdo de correspondência da entrega também são separados, e o conteúdo de auditoria em texto claro é aplicado enquanto a entrega é vinculada pelo texto cifrado
• O trabalho restante é aplicar o mesmo contrato de conteúdo duplo a send_message e followup_task, e fazer todas as telas de histórico, replay e debug voltadas ao usuário lerem a cópia de auditoria em vez do texto cifrado

Critérios de conclusão e estado atual

• Deve ser possível ler o texto claro de spawn_agent, send_message e followup_task v2 nos rollouts e históricos do agente pai
• Mesmo com a criptografia ativada, o modelo filho deve receber apenas o payload de entrega criptografado
• As arestas do rastreamento estruturado de rollout devem conter message_content em texto claro com tamanho limitado
• O log de comunicação deve usar o conteúdo de auditoria em texto claro quando disponível, e não substituir campos de mensagem legíveis por texto cifrado
• Retomada e replay devem preservar a cópia de auditoria sem injetá-la no contexto do modelo filho
• O comportamento existente de comunicação v1 em texto claro não deve mudar
• São necessários testes de regressão para as três ferramentas v2, validando em conjunto dados de auditoria local legíveis e entrada criptografada para o modelo receptor
• Na página fornecida, a issue está Open, e não há resultado indicando que uma correção tenha sido incorporada ao repositório upstream

[GN⁺]

Comentários do Hacker News

• Este título é fácil de interpretar errado. Mais precisamente, significa que o Codex começou a criptografar prompts de subagentes para ocultá-los do usuário.
  O título original era “Codex starts encrypting prompts, uses ciphertext for inference instead”.

  • Parece bastante provável que isso tenha sido introduzido porque o modo ultra do GPT-5.6 distribui o trabalho entre vários subagentes. Antes, esse modo só estava disponível na interface web e provavelmente correspondia ao antigo modo pro.
    Se ele foi treinado com rollouts completos de aprendizado por reforço em que agentes interagem entre si, a OpenAI parece querer tratar esses prompts como rastros brutos de raciocínio, impedindo que outros os usem diretamente para treinamento.
    Também há indícios de que o blob compactado opaco retornado pelo endpoint dedicado de compressão talvez não seja texto, mas uma representação da conversa em espaço latente; o fato de a fidelidade da compressão da OpenAI ser muito maior que a de outros fornecedores reforça essa hipótese. Eles podem ter aplicado uma técnica semelhante aos prompts dos subagentes, e fico curioso se também usam blobs criptografados ao criar subagentes de diferentes tipos de modelo.
  • É absurdo que dezenas a centenas de agentes probabilísticos sejam executados no computador local e que nem sequer seja possível inspecionar as instruções que esses agentes receberam.
    Já aconteceu de eu examinar subagentes e fluxos de trabalho do Claude e concluir: “isso nem deveria ter sido executado”. Já usuários do Codex acabam tendo de gastar tokens às cegas em instruções de encaminhamento criptografadas que o orquestrador passa aos subagentes e em operações de shell.
  • Uma parte considerável da propriedade intelectual do Codex provavelmente está mais na composição, ordem e orquestração dos prompts do que na base de código.
    Nós também tentamos permitir que empresas escolhessem o provedor de IA preferido ou obrigatório e suas próprias chaves de API, oferecendo um plano simples de preços, mas logo percebemos que os prompts de backend poderiam vazar para os clientes. Com rastros detalhados de execução, seria relativamente fácil fazer engenharia reversa do que fazemos, então acabamos abandonando essa ideia.
  • No começo pensei que fosse alguma tecnologia como criptografia homomórfica, mas no fim parece ganância comum.
  • Não é a primeira vez que o Codex criptografa algo. O excelente endpoint de compressão já vinha retornando blobs criptografados enormes havia pelo menos 5 meses.

• Agora entendo por que minha ferramenta local para inspecionar sessões de agentes de programação parou de funcionar em algumas situações.
  É uma decisão de design interessante; fico curioso para saber quantas pessoas vão aceitar comandos externos criptografados a serem executados no computador do usuário.

  • Os incentivos da OpenAI não parecem estar exatamente alinhados aos dos usuários, incluindo clientes corporativos. Vale conferir também declarações recentes de Alex Karp e Satya Nadella.
    Esconder o conteúdo do usuário por meio de criptografia é o tipo de abordagem que a RIAA usava com DRM por preocupação com violação de direitos autorais; fico em dúvida se isso também é uma escolha hostil ao usuário.
  • Se você usa o modo YOLO, já está assumindo esse risco, e o que importa são as chamadas de ferramentas. As chamadas de ferramentas em si não podem ser criptografadas.

• Continuo usando o endpoint Chat Completions justamente por causa desse tipo de comportamento. A OpenAI vem empurrando sutilmente os usuários para longe do Chat Completions e em direção à Responses API, que é mais fácil de ofuscar.
  No Chat Completions, dá para controlar diretamente o procedimento de inferência; ativando recursos experimentais e configurando algumas opções meio confusas, é possível até criar um agente personalizado de busca em árvore de Monte Carlo (MCTS) com os modelos GPT-5.6 atuais.
  No VS Copilot, é possível usar até gpt5.5 com o token de API do usuário e configurações de modelo, mas a família gpt5.6 atualmente não funciona. Suspeito que seja porque ele não força reasoning_effort para none de modo a satisfazer o novo comportamento de aumento das barreiras de entrada.

  • Fico curioso sobre o que exatamente é essa técnica de MCTS mencionada aqui. De todo modo, o processo de pensamento fornecido é resumido de forma excessivamente abstrata e pouco útil, e também questiono se é realmente possível controlar completamente o procedimento de inferência.
  • MCTS é a sigla de busca em árvore de Monte Carlo (Monte Carlo Tree Search).
  • Eu preferiria que MCTS não fosse usado aqui como buzzword. O método a que isso se refere não é MCTS no sentido rigoroso.
  • A Responses API oferece muitas vantagens em relação ao Chat Completions: https://developers.openai.com/api/docs/guides/migrate-to-res...
    Todos os modelos novos que estão saindo hoje em dia são modelos de raciocínio, então, de acordo com as recomendações, deve-se usar a Responses API.

• Fico curioso se eles talvez impeçam o uso da assinatura do GPT em ferramentas alternativas de execução. Se não fizerem isso, não é um grande problema, e o codex cli em si é uma ferramenta de execução surpreendentemente comum

  • Parece pouco provável. Toda a arquitetura do app-server existe justamente para dar suporte a esse tipo de integração, então remover isso do Codex exigiria desmontar uma parte enorme
    Eu também consigo integrar com muita facilidade usando a API RPC do app-server, por isso uso o Codex mais do que qualquer outra coisa; hoje, uso quase tudo por meio da minha própria integração, em vez da TUI pública do Codex
    Mas, se eles criptografarem os prompts, que são a entrada real de inferência no disco local, para que só o backend da OpenAI consiga vê-los, então, mesmo que a integração seja fácil, não será possível entender o que está acontecendo. É difícil entender por que a equipe considerou isso uma boa escolha
  • A Anthropic e o Google já cobram uma taxa extra quando se usa suas próprias ferramentas de execução, e esse é todo o motivo para usar a OpenAI
    Se a OpenAI seguir o mesmo caminho, pretendo voltar para o Claude ou comprar mais um Spark e rodar localmente
  • Enquanto a Anthropic estiver à frente na adoção empresarial, acho que não vão bloquear. Não sei como isso mudaria se a OpenAI assumisse a liderança com uma grande vantagem, mas espero que, até lá, os modelos abertos fiquem melhores do que o gpt-5.6 sol
  • O próprio Codex começou a oferecer um proxy que encapsula a assinatura, então parece pouco provável que bloqueiem
    https://github.com/openai/codex/blob/main/codex-rs/responses...
  • Recentemente, Tibo, da OpenAI, pediu no Twitter que compartilhassem como executar GPT pelo Claude Code, então não parece que sejam contra o uso de ferramentas alternativas de execução

• O título anterior no HN soava como se a inferência fosse feita diretamente sobre texto cifrado, o que gerou muita confusão. Para isso, seria preciso uma criptografia homomórfica muito mais avançada do que a que se conhece atualmente

  • Na prática, o que fizeram foi criptografar o conteúdo que o agente envia ao subagente para que apenas o backend da OpenAI possa ver o texto em claro
    Antes, o agente enviava prompts em texto claro ao subagente, e eles também ficavam nos logs e nos dados da sessão; por isso, mesmo ao usar o recurso experimental de subagentes, era possível abrir os dados e verificar o funcionamento interno
    Agora, ao usar Sol ou Terra, o texto cifrado criado pelo backend é entregue ao subagente, e o subagente o usa novamente na inferência do backend da OpenAI. Luna parece não ser afetado, e não é a sessão inteira que é criptografada, apenas as mensagens delegadas entre agentes
    A inferência interna da OpenAI não ocorre sobre texto cifrado, mas, para o usuário local, o que aparece é apenas texto cifrado em vez de texto em claro. Para deixar isso claro, o título foi alterado para “Codex starts encrypting sub-agent prompts”
  • Como havia “inferencing” no título, eu também pensei imediatamente em criptografia homomórfica ou operações sobre texto cifrado

• Houve um relato recente no Twitter de que um subagente GPT-5.6 apagou por engano o diretório home de um usuário
  Fico me perguntando se, ao impedir que se veja o que o subagente pretende fazer, as salvaguardas também não falharam
  https://x.com/mattshumer_/status/2076794038456385546?s=20

• Isso é uma forma de passar chaves de cache pelo cliente para reduzir o uso de tokens. Como é fácil contornar usando outras ferramentas de subtarefas, não pode ser uma defesa contra destilação de modelos

• Fico curioso sobre exatamente onde a criptografia acontece. Eu achava que o agente principal chamava o subagente localmente; então fico na dúvida se, no Codex, o subagente é chamado nos servidores da OpenAI antes de chegar ao ambiente local

  • Antes, o agente enviava prompts em texto claro ao subagente, e eles também ficavam nos logs e nos dados da sessão, facilitando observar o funcionamento interno
    No Sol ou no Terra, em vez do prompt, é enviado um texto cifrado gerado pelo backend da OpenAI, e o subagente o usa novamente na inferência do backend. Luna parece não ser afetado; como não é a sessão inteira, mas apenas as mensagens delegadas entre agentes que são criptografadas, agora só o backend da OpenAI consegue descriptografar esse conteúdo

• Eu estava me perguntando por que os serviços de revenda do mercado clandestino chinês tinham parado de funcionar desde ontem; provavelmente foi por causa dessa mudança

  • Esses mercados clandestinos não apenas agregam assinaturas para revenda, mas também armazenam os dados e os vendem para lugares que treinam modelos. A criptografia é útil para impedir pelo menos esta segunda prática, e tem o mesmo objetivo de outras técnicas reveladas antes, mas com uma implementação muito mais limpa

• O principal objetivo parece ser dificultar tentativas de fazer proxy de grandes volumes de solicitações e respostas de usuários para usá-las no treinamento de modelos concorrentes

  • A intenção de impedir que outros fornecedores vejam por dentro o modo como a OpenAI gerencia múltiplos agentes parece clara
    Mas é uma implementação ruim: usuários pagantes ficam sem nenhum meio de descobrir a causa quando algo dá errado, o que torna difícil usar adequadamente o recurso de múltiplos agentes