A ZCode, ferramenta de programação com IA da Zhipu, foi denunciada por um desenvolvedor em 18 de setembro por empacotar e enviar em segundo plano todo o espaço de trabalho do usuário, incluindo o histórico completo do Git, o cache de arquivos grandes do LFS e configurações locais da máquina. Ainda naquela noite, a ZCode divulgou um pedido de desculpas, reconhecendo que os envios ocorreram, atribuindo o problema a uma função de "indexação de repositório" e afirmando que já havia sido corrigido.
O que os desenvolvedores descobriram
Quem trouxe os detalhes a público primeiro foi o blogueiro de tecnologia Ferstar. Em seu blog, ele desmontou o mecanismo de snapshot local da ZCode: após o login, um processo em segundo plano iniciado junto com o programa empacota todo o espaço de trabalho, criptografa o conteúdo dos arquivos com AES-256-CTR e depois envolve a chave com uma chave pública RSA fornecida pelo servidor, enviando tudo diretamente para o Alibaba Cloud OSS por meio de upload via formulário. A chave privada usada para descriptografar fica apenas na nuvem — o próprio usuário não consegue abrir seus arquivos .enc.
A amostra que ele apresentou é concreta: o espaço de trabalho descompactado tinha 345MB, e após a criptografia ficou com 313MB, com 42411 arquivos na lista. A maior parte pertence ao diretório .git, somando 86,6% do total, sendo 196,1MB de cache do LFS e 102,2MB de objetos do Git; código-fonte e configurações somam apenas cerca de 46MB. Há dois momentos de disparo: um antes de cada envio de prompt, outro após a conclusão de uma tarefa, ao atualizar o Repo Wiki; em uma única sessão, chegaram a ser registrados 62 snapshots.
No mesmo dia, um desenvolvedor abriu uma issue no repositório público de feedback da Zhipu, com um título que enfileira três "por quês": por que enviar silenciosamente todo o histórico do Git, por que criptografar de um jeito que nem o próprio usuário consegue abrir, e por que nem sequer existe um interruptor para desativar a função. A issue menciona ainda que, após falhas de envio local, o sistema tentava novamente repetidas vezes, chegando a 564 tentativas registradas. Outro desenvolvedor reproduziu o comportamento em sua própria máquina: um snapshot de projeto com 748MiB, sendo 98,91% ocupado pelo .git, na versão ZCode 3.12.3.
O interruptor que não funciona é o ponto mais afiado dessa polêmica. Segundo Ferstar, os interruptores de "otimizar experiência" e "indexação de snapshot de repositório" na interface controlam apenas se o servidor vai usar os dados para treinar modelos — o empacotamento e o envio locais continuam acontecendo normalmente. O histórico do Git pode guardar chaves já excluídas há muito tempo, configurações antigas abandonadas, registros de branches nunca enviados e domínios de rede interna — coisas que não aparecem mais no código atual, mas continuam intactas dentro do .git.
O que diz a Zhipu
O pedido de desculpas da ZCode atribui os envios à função de "indexação de repositório": ao gerar a página do Repo Wiki, isso pode disparar o envio de dados do repositório, que são apagados na nuvem imediatamente após a geração do Wiki, sem serem armazenados. A função vinha ativada por padrão no lançamento, afetando alguns usuários, e já foi corrigida.
As medidas corretivas anunciadas são três: abrir em breve o código-fonte do repositório da ZCode, convidando uma avaliação de terceiros e tornando pública a evolução da revisão; e, ainda no mesmo dia, conceder a todos os usuários uma redefinição extra da cota semanal. Vários pontos não foram esclarecidos na nota e, por ora, não podem ser verificados: quantos usuários e repositórios foram afetados, quanto tempo os dados de fato permaneceram no OSS, se a "destruição" passou por auditoria independente, e qual é o número da versão após a correção. O cronograma da abertura do código também ficou apenas como "em breve".
No mesmo dia, a Zhipu também lançou um novo modelo, o GLM-5.3-FlashX, destacando velocidade de saída de 200 tokens por segundo. Um desenvolvedor comentou em seu blog, unindo os dois fatos com ironia: enquanto todo mundo pergunta para onde foi o código, a Zhipu está ocupada lançando um modelo novo.
O que os desenvolvedores na China podem fazer agora
Boa parte dos usuários da ZCode testa a ferramenta em projetos de empresas, e o histórico do Git costuma ser mais sensível para uma empresa do que o próprio código atual. Para quem ainda tem versões antigas instaladas, três passos são recomendados: primeiro, atualizar para a versão corrigida; depois, verificar se a pasta local ~/.zcode/v2/checkpoints ainda guarda snapshots pendentes de envio; e, por fim, trocar todas as chaves e tokens que apareceram no histórico, sem contar que a suposta "destruição" cubra o que já foi enviado.
Ferstar sugere um método ainda mais radical: no macOS, usar chflags uchg; no Linux, chattr +i, para travar a pasta de snapshots como somente leitura, bloqueando a geração de snapshots já na camada do sistema de arquivos. O custo é que as funções de rollback de checkpoint e linha do tempo deixam de funcionar.
Agentes de programação precisam ler o repositório para funcionar, e a indexação local em si não é nenhuma novidade. A divergência está nos limites: ler localmente e enviar para a nuvem são coisas diferentes, assim como enviar o código atual e enviar todo o histórico também são coisas diferentes. Se a abertura de código prometida pela Zhipu realmente acontecer, será possível verificar por conta própria quais caminhos o módulo de snapshot realmente empacotava e onde os interruptores estão de fato conectados.
Fontes: análise de engenharia reversa do blog de tecnologia Ferstar sobre o mecanismo de snapshot e a composição dos arquivos, issue pública no zai-org/feedback, Ifeng Tech, CocoLoop, Elliot's Harness Lab; comunicado de desculpas da ZCode para verificação da atribuição, status da correção e medidas de compensação.