2 pontos por GN⁺ 2026-03-03 | 1 comentários | Compartilhar no WhatsApp
  • Quando o recurso Cowork é ativado no macOS, um bundle de máquina virtual (VM) de cerca de 10 GB é criado automaticamente no sistema, causando uma queda acentuada de desempenho
  • Esse arquivo é armazenado em ~/Library/ e, mesmo após ser apagado, é recriado no dia seguinte
  • Quando isso acontece, há aumento no uso de CPU (24%~55%), mais swap, lentidão na UI e outras degradações contínuas de desempenho
  • Como solução temporária, apagar o bundle da VM e as pastas de cache traz cerca de 75% de melhora no desempenho, mas com o tempo o sistema volta a ficar lento
  • Vários usuários apontam falta de transparência e desperdício de armazenamento, e pedem configurações para escolher se a VM deve ser criada, além de aviso prévio

Visão geral do problema

  • Após usar o recurso Cowork, o Claude Desktop fica muito lento, com atraso na inicialização, travamentos na UI e lentidão nas respostas
  • A perda de desempenho piora gradualmente mesmo durante a sessão, e o arquivo bundle da VM cresce até 10 GB e é recriado automaticamente
  • O problema foi reproduzido em ambiente macOS (8 GB de RAM)

Resultados da investigação

  • O bundle de VM criado pelo recurso Cowork fica em ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
  • Mesmo ao apagar esse arquivo, ele é recriado dentro de um dia, sem que ocorra limpeza automática (cleanup)
  • Ao apagar o bundle da VM e o cache, o uso de armazenamento cai de 11 GB → 639 MB, e a velocidade de trabalho melhora cerca de 75%
  • Porém, poucos minutos após reiniciar, o uso de CPU sobe de 24% → 55%, e os swapins aumentam de 20K → 24K+
  • Isso sugere possível degradação de desempenho causada por vazamento de memória ou carga de trabalho acumulada

Comportamentos observados

  • Uso de CPU de 24%~55% mesmo em estado ocioso
  • A atividade de swap continua aumentando, com perda de desempenho em poucos minutos
  • Recriação de um bundle de VM de 10 GB a cada sessão do Cowork
  • Melhora temporária após limpeza (75%), mas nova degradação com o tempo

Solução temporária

  • Feche o Claude Desktop e apague a VM e o cache com os comandos abaixo
    rm -rf ~/Library/Application\ Support/Claude/vm_bundles  
    rm -rf ~/Library/Application\ Support/Claude/Cache  
    rm -rf ~/Library/Application\ Support/Claude/Code\ Cache  
    
  • Essa medida pode melhorar temporariamente o desempenho, mas reinicializações periódicas continuam sendo necessárias
  • Alguns usuários alteraram a permissão da pasta da VM para chmod 000 para evitar a recriação

Feedback dos usuários

  • Mesmo com o Cowork desativado, a VM roda e consome memória
  • Alguns usuários relatam bundles de VM que cresceram para mais de 21 GB
  • A VM é reprovisionada automaticamente ao iniciar o app e até o arquivo compactado (rootfs.img.zst) permanece, causando desperdício duplicado de armazenamento
  • Até usuários que nunca usaram o Cowork encontraram bundles de 10 GB, percebidos como vazamento de memória
  • Usuários de Mac com armazenamento limitado enfatizam a necessidade de uma opção de desativação

Questões de transparência e confiança

  • Os usuários criticam o fato de o app ocupar 12~20 GB de disco e 2 GB de RAM sem aviso prévio
  • Foram sugeridos avisos na instalação ou na primeira execução, opção para escolher o pré-download da VM e um toggle para desativar o Cowork
  • Alguns dizem entender a intenção do design de sandboxing por VM, mas afirmam que a falta de explicação prejudica a confiança do usuário
  • Muitos concordam com a opinião de que “um app usar recursos do sistema sem o usuário saber reduz a confiança”

1 comentários

 
GN⁺ 2026-03-03
Comentários do Hacker News
  • Olá, aqui é Felix, da Anthropic. Eu cuido do Claude Cowork e do Claude Code
    O Cowork é construído sobre um harness de agente do Claude Code que roda dentro de uma VM Linux, executado via Apple Virtualization Framework ou Microsoft Host Compute System
    Fazemos isso por três motivos
    (1) para fornecer um ambiente de computador isolado onde o Claude possa escrever código livremente em nome do usuário
    (2) porque isso oferece uma garantia de fronteira de segurança mais robusta do que outras soluções de sandbox
    (3) para oferecer uma experiência de uso mais segura para usuários sem perfil técnico
    Ainda assim, sabemos que há trade-offs e estamos avaliando ideias para melhorar isso para quem não quiser usar o Cowork ou quiser usá-lo sem VM

    • Como feedback, se o Cowork vai usar 10 GB de armazenamento, ele deveria avisar o usuário com antecedência e permitir remoção com um clique
      Reduzir a “fadiga de aprovação” (approval fatigue) pode ser vantajoso para a Anthropic no curto prazo, mas no longo prazo não beneficia o usuário
      Acho melhor interromper esse padrão antes que ele se consolide
    • Gostaria que fornecessem uma imagem de contêiner oficial ou semi-oficial para o sandbox do Claude. Seria bom poder usar a VM do Cowork também fora dele
    • A explicação é excelente, mas na prática há reclamações de que o Cowork causa queda de desempenho e consumo excessivo de energia
    • Eu não sabia que o Cowork rodava sobre uma VM. Se isso tivesse sido comunicado claramente no marketing, provavelmente eu teria usado muito antes
    • Tentei executar o Claude Desktop em uma VM de Mac (dentro do UTM) e encontrei um erro relacionado ao Apple Virtualization Framework
      Como eu já estava rodando dentro de uma VM, parece que ocorreu um erro de virtualização aninhada. Seria bom melhorar a mensagem de erro ou fazer o Cowork pular sua própria VM quando já estiver dentro de outra
  • É impressionante como os apps hoje em dia abusam do acesso ao disco
    Por exemplo, o Apple Podcasts baixa 120 GB de arquivos de podcast sem motivo e não apaga depois. Aparecia como “System Data”, e eu tive que caçar em um drive externo

    • O problema de “System Data” no macOS é realmente terrível. Por causa de Docker, biblioteca de música, cache etc., a cada 1 ou 2 anos preciso fazer uma instalação limpa
    • Se você olhar a pasta ~/Library/Messages, ela ocupa mais de 100 GB por causa da sincronização do iMessage. Isso deveria ser descarregado para a nuvem
    • Mesmo na era do 5G, não entendo por que arquivos de áudio ainda são baixados por padrão. Streaming basta
    • Também perdi um dia inteiro de trabalho porque, por causa de um problema no backup do Time Machine, 300 GB de 512 GB apareciam como “System Data”
    • Para resolver esse tipo de problema, uso ferramentas como Mole. Também uso o CLI do warp/gemini para encontrar e apagar caches desnecessários
  • Estou sentindo ao mesmo tempo a bênção e a maldição do “vibe coding”. É literalmente a dualidade da programação por vibe

  • O sandbox em VM é o núcleo do Cowork. Para oferecer geração de código com segurança, um ambiente isolado é indispensável
    Sugiro uma UI que permita ao usuário conceder acesso apenas a pastas específicas e exiba um alerta quando for necessária permissão de escrita

  • Na verdade, mesmo sem LLM, o ideal é desenvolver dentro de uma VM
    Ferramentas como Vagrant ainda são úteis
    O principal público do Cowork são não desenvolvedores, e faz sentido abordá-lo como uma IA assistente que escreve código
    Especialistas trabalham em um Mac Mini separado, mas usuários comuns não podem fazer isso, então a VM é uma solução realista

    • Hoje em dia há muitos provedores de VPS, então é fácil montar um ambiente em lugares como exe.dev, sprites.dev, shellbox.dev
    • Eu prefiro devcontainer para projetos complexos. Com Docker e NixOS, dá para criar um ambiente de desenvolvimento mais leve e flexível
    • No macOS, Lima foi a melhor escolha para mim. Deixo o Claude Code na imagem e monto apenas os diretórios necessários. Funciona de forma muito mais fluida do que o Vagrant
    • Houve até quem reagisse dizendo, em tom de piada, “então você também usa camisinha para programar?”, como crítica a um suposto excesso de obsessão com segurança
  • Ouvi dizer que funcionários da Anthropic estão desenvolvendo o Claude Code com o próprio Claude Code
    A IA aumenta o acabamento do produto, mas a queda de qualidade é o problema. No fim, desenvolvedores experientes voltarão a ser necessários
    Os usuários iniciais têm a responsabilidade de testar o produto como se fossem cobaias

    • Fico em dúvida se esses produtos 1st party conseguem competir com open source. Se há alternativas gratuitas e melhores, não vejo motivo para usar
    • Vendo os problemas de qualidade dentro da Anthropic, parece que a maioria dos funcionários está em nível júnior ou abaixo. O time do Bun parece ser uma das poucas exceções
  • Nos últimos 30 minutos, enquanto eu organizava meu notebook com o DaisyDisk, encontrei a VM de 10 GB do Cowork
    É comum que apps ocupem espaço de armazenamento sem necessidade, e quase não há recursos de limpeza
    O Xcode também continua guardando SDKs e simuladores de vários sistemas operacionais mesmo quando não é executado há muito tempo

    • Para resolver esse tipo de problema, basta usar DevCleaner
    • Fico me perguntando por que, havendo crond e find no macOS, esse tipo de limpeza não é automatizado
  • Como o Cowork usa o Apple Virtualization Framework, ocorre erro de VM aninhada
    Isso traz limitação de funcionalidade, desperdício de espaço e latência. O sandbox Seatbelt usado pela OpenAI pode ser uma alternativa melhor
    Link relacionado

    • Mas eu acho que o Seatbelt é quase inútil. Fico curioso para saber por que alguém tentaria executar o Cowork dentro de uma VM. Não basta usar a própria VM dele?
    • Além disso, o Seatbelt é quase sem documentação
  • É incômodo, mas esse tipo de sandbox é justamente a essência de ferramentas agentic
    Ferramentas executadas sem sandbox embutido vão acabar causando perda de dados algum dia

  • Provavelmente alguém dentro da Anthropic mandou um prompt de “melhore o desempenho do app” e esse foi o resultado