- 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
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
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
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
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
~/Library/Messages, ela ocupa mais de 100 GB por causa da sincronização do iMessage. Isso deveria ser descarregado para a nuvemEstou 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
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
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
crondefindno macOS, esse tipo de limpeza não é automatizadoComo 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
É 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