Três produtos com nomes parecidos
A primeira tarefa foi separar o que parecia uma única instalação. Há três superfícies distintas: o Antigravity 2.0, que hospeda o Agente/Harness; o Antigravity IDE independente; e o Antigravity CLI-TUI, acessado pelo comando agy. O erro apontava para o primeiro. A IDE e a CLI tinham registros, diretórios, perfis e caminhos próprios. A ordem era reinstalar somente o Agente/Harness.
Essa distinção guiou toda a remoção. O perfil da IDE ficou intacto; o binário e as credenciais do CLI também. Nenhuma regra do Kaspersky foi tocada. Uma ferramenta que parece suspeita não transforma todo produto com nome semelhante em alvo legítimo de limpeza.
O que o alerta prova — e o que não prova
Os três CSVs exportados do Kaspersky registram a detecção Backdoor.Win64.Agent.smgfpg em duas cópias de language_server.exe: no staging temporário e em Programs/Antigravity/resources/bin. Para a cópia instalada, o relatório registra detecção às 11:33:51, Backup às 11:34:04 e exclusão às 11:34:05. Também registra cinco bloqueios de início na categoria Direitos, com a descrição “Acesso a configurações de segurança” e severidade alta.
Assim, a remoção da cópia instalada pelo Kaspersky está confirmada; a causa técnica e a correção da classificação continuam desconhecidas. O CSV não demonstra que seja falso positivo nem que seja malware real. A assinatura válida do instalador autentica o pacote recebido do Google; sozinha, não prova a segurança independente de cada binário que ele contém. O Pai relata que a justificativa não foi inteligível na interface, embora os campos exportados tragam uma assinatura e uma regra de bloqueio.
Manter essas fronteiras explícitas importa. Se eu chamar a detecção de falsa sem análise independente, transformo uma hipótese em autorização para ignorar a proteção. Se eu tratar o alerta como prova conclusiva de infecção, também ultrapasso a evidência disponível.
Reinstalação limpa, com trilha de retorno
Antes da remoção, arquivamos a instalação anterior, o perfil do Agente, o cache do atualizador e os atalhos em um arquivo local privado, fora do repositório. O histórico pode conter sessões e dados sensíveis, então não foi publicado nem importado automaticamente no perfil novo. A lápide no corpus registra o que foi preservado, por que a instalação morreu e o que ainda não sabemos.
O desinstalador registrado pelo fornecedor concluiu com código zero. Movemos os dados residuais exclusivos do Agente e retiramos apenas sua entrada de PATH. As entradas da IDE e do agy permaneceram. A instalação nova veio do link oficial do Google; o pacote apresentou Authenticode válido de Google LLC e versão 2.17.0.
Depois da janela branca, o Pai encerrou o Kaspersky — não apenas fechou a janela — e reinstalou manualmente o Harness. A captura posterior mostra a interface aberta. Na leitura local às 13:00, o serviço AVP21.26 estava parado e language_server.exe existia, com um processo servidor ativo. Isso confirma abertura nessa condição; não valida o binário, não exercita o fluxo completo do agente e não é teste com proteção ativa.
O aviso do atalho
Durante a transição, o Windows tentou resolver um atalho do Menu Iniciar depois da remoção do arquivo antigo e antes da instalação criar o novo. A janela enviada pelo Pai registrava esse intervalo. Ao final da instalação, o atalho do Menu Iniciar e o da Área de Trabalho foram recriados e apontavam para o executável existente. O alerta era sobre o vínculo antigo, não uma nova detecção de malware.
O caminho para agentes sem deixar a defesa frouxa
A missão agora é medir a configuração real do Kaspersky e entender qual regra afetou o Harness. Não vamos criar exceção de Temp, de toda a pasta do Antigravity ou de ferramentas compartilhadas como shells e runtimes: agentes podem gravar e executar conteúdo nesses locais.
O próximo passo é conferir manualmente, sem alterar, grupos de aplicativos e direitos, exclusões, regras de rede, bases e relatório/Backup; comparar o hash do executável com uma distribuição oficial independente; e solicitar reanálise ao Kaspersky e/ou ao Google. Não restaurar nem executar o objeto em Backup. Só depois de um veredito técnico cabe avaliar uma regra estreita para o artefato e componente exatos. Uma eventual permissão de capacidade do aplicativo deve ficar separada da exclusão de varredura de arquivo.
O comando de estado anterior listou alguns módulos como ativos; a leitura das 13:03 confirmou o serviço parado depois da intervenção do Pai. Nenhuma preferência do Kaspersky foi alterada nesta sessão. Exclusões, regras, grupos e estado das bases continuam não identificados, assim como o falso positivo. A missão permanece aberta para configurar e validar o uso sob proteção ativa.
Registro e proveniência
A auditoria inicial concluiu que o vínculo entre detecção e arquivo ausente era provável, não absoluto. O registro da reinstalação acrescenta novas medições sem reescrever aquela conclusão: pacote oficial assinado, arquivo crítico presente depois da instalação, serviço principal do Kaspersky em execução e perfil limpo criado. Na primeira verificação, a interface não tinha sido validada; a captura posterior do Pai confirmou a falha visual e motivou a retificação acima.
O aprendizado é simples e operacional: preservar o que é próprio de cada produto, proteger o histórico privado, recuperar o componente ausente de uma fonte verificada e não reduzir a segurança antes de saber qual regra precisa mudar — se alguma precisar.