Memórias do Codex exfiltram chats de provedores locais sem aviso

Denúncia de exfiltração no Codex

Uma issue aberta no repositório openai/codex (nº 41711, por jagoff2) alega que o recurso de memórias do aplicativo desktop Codex transmite o conteúdo de chats roteados por provedores locais ou de terceiros para a OpenAI, sem aviso ao usuário.

Como o cruzamento de provedores ocorre

Segundo o relato, o seletor de rollouts do gravador de memórias não restringe os candidatos ao provedor que os criou: ele aplica critérios como modo de memória, idade, estado ocioso e tipo de origem, mas não o provedor. O trabalhador de memória usa o provedor ativo da sessão que disparou a geração e serializa itens retidos do rollout anterior em uma nova requisição de modelo. Assim, um rollout criado sob um provedor local pode ser selecionado por uma sessão de memória respaldada pela OpenAI e enviado para ela.

Evidência de captura controlada

O autor executou um teste com o binário Windows 0.150.0-alpha.12.2 (com hash e commit de origem indicados), memórias habilitadas, analytics desativado e todos os exportadores OpenTelemetry definidos como none. Um rollout sintético rotulado com um provedor não-OpenAI foi processado por uma sessão de memória da OpenAI: o Codex enviou um frame WebSocket response.create de 38.095 bytes para chatgpt.com/backend-api/codex/responses, com request_kind = "memory", store = false e prompt_cache_retention de 24h. Cinco dos seis itens do rollout de origem apareceram na requisição, incluindo contexto de ambiente, mensagens do usuário, chamadas e saídas de ferramentas e caminhos locais. A resposta do servidor (modelo gpt-5.6-luna, 8.320 tokens) reproduziu múltiplos canários únicos do conteúdo de origem, o que, segundo o autor, prova processamento remoto do material, não apenas tentativa de conexão.

Alcance do envio e limites da redação

As classes retidas incluem mensagens de usuário e assistente, chamadas de shell locais, chamadas e saídas de funções e ferramentas, buscas na web e comunicações entre agentes. Entradas longas são truncadas no meio, preservando início e fim, com limite de 70% da janela de contexto ou fallback de 150.000 tokens. A função redact_secrets cobre apenas padrões estreitos de credenciais (chaves sk-, identificadores AKIA da AWS, bearer tokens longos e nomes como api_key ou password); em um teste de loopback, ela preservou e-mail, telefone, caminho do Windows, cabeçalho de chave privada e prosa privada. O autor classifica o filtro como útil, mas não como um removedor geral de dados pessoais ou material confidencial.

Controles insuficientes

O tráfego ocorreu com analytics e telemetria desativados, pois esses controles governam outros subsistemas. O controle global decisivo seria desativar completamente as memórias via [features] memories = false - não existe opção que mantenha memórias e proíba a transmissão entre provedores.

Origem da investigação e acusação

O autor relata que a investigação começou após receber um aviso da OpenAI por "cyber abuse", sem que nenhum chat direcionado à OpenAI justificasse a advertência; a atividade relevante existia apenas em chats roteados pelo provedor local privado. Ele afirma acreditar firmemente que a OpenAI usou conteúdo que não tinha direito de receber para policiamento de conta e caracteriza o caso como exfiltração de dados, independentemente de ser design intencional ou bug.

Remédios e respostas exigidas

Entre as correções propostas estão: vincular a seleção e o envio ao provedor de origem do rollout, tornar o processamento entre provedores opt-in com destino e classes de conteúdo declarados, expor recibos auditáveis, documentar o comportamento, adicionar testes automatizados de isolamento de provedor e proibir uso de conteúdo cruzado para moderação de contas. O autor pede que a OpenAI audite ações negativas passadas, reverta as afetadas, notifique os usuários e publique resposta oficial, e lista dez perguntas diretas, incluindo se o comportamento é intencional, quais versões são afetadas e quantos usuários foram penalizados com base nesse canal.