Claude Desktop deixando o computador lento? O que checar antes de culpar o app

Fala aí, beleza? Você abre o Claude Desktop, a máquina começa a engasgar, o ventilador liga sozinho e a conclusão já vem pronta na cabeça: "esse app é um monstro, bora desinstalar"

Calma

Parte do peso vem de comportamentos que já foram relatados publicamente em issues abertas, ou seja, é código, não é você

Outra parte vem de como a SUA instalação está hoje: o que está conectado, quanto histórico local existe, se o app está atualizado

Separar essas duas coisas é exatamente o que evita você trocar de ferramenta à toa

Este post é um roteiro de diagnóstico, não uma promessa de correção oficial: onde não há caminho confirmado, eu digo que não há 🙂

Roteiro de diagnóstico: a ordem certa de checar

Antes de qualquer conclusão, mede

Diagnóstico bom é chato e sequencial, então segue a ordem:

1. Descubra QUAL processo pesa, e não "se o app pesa". No Windows, Gerenciador de Tarefas; no macOS, Monitor de Atividade. Olhe se o vilão é o Vmmem, se é o processo renderer do app, ou se é a soma de vários processos do Claude Desktop juntos

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O erro comum deste passo: ler a linha do app e parar por aí, sem expandir os processos filhos

2. Separe CPU de escrita em disco. A queixa de "tá lento" muitas vezes é I/O, não processamento: o computador está esperando o disco, não a CPU. Adicione a coluna de disco na visualização antes de julgar

O erro comum deste passo: olhar só a coluna de CPU, ver um número baixinho e concluir que está tudo bem enquanto o disco escreve sem parar

3. Confira se o app está atualizado. O Claude Desktop checa atualizações a cada aproximadamente 4 horas e aplica automaticamente no macOS e no Windows. Manualmente, no macOS é em Claude > Check for Updates e no Windows em Help > Check for Updates. No Linux, a atualização é via apt

O erro comum deste passo: assumir que "atualiza sozinho" significa "já está atualizado agora", sem nunca abrir a checagem manual

4. Revise as extensões. No Claude Desktop, elas ficam em Settings > Extensions, com botão Browse extensions pro diretório de extensões. Passe o olho item por item e pergunte: eu uso isso?

O erro comum deste passo: desligar tudo de uma vez, ver melhorar e não saber QUEM era o culpado

5. Revise os conectores ativos da conversa. Clique no botão + na parte de baixo da caixa de chat e escolha Connectors: ali aparecem os servidores MCP conectados e as ferramentas deles

O erro comum deste passo: esquecer que conector ligado é processo rodando, não é enfeite na interface

6. Compare chat novo com conversa longa. Abra um chat do zero, use um pouco, meça. Depois volte pra aquela thread gigante que você arrasta há semanas e meça de novo

O erro comum deste passo: mudar três coisas no mesmo dia e não conseguir dizer qual delas resolveu

Anota o número antes e o número depois de CADA mudança

Sem isso, o resto do post vira achismo

Sintoma: RAM alta com o app parado, sem conversa aberta

Esse é o caso mais comentado no Windows

Existe relato aberto de que o Claude Desktop sobe uma máquina virtual Hyper-V a cada inicialização, mesmo pra quem só usa o chat, e ela aparece como processo Vmmem no Gerenciador de Tarefas (Issue #29045, consumo de aproximadamente 1,8 GB de RAM, reportada desde fevereiro de 2026)

O caso ganhou repercussão na imprensa de tecnologia: o Neowin cobriu em junho de 2026 e apurou que até aquele momento não havia correção nem posicionamento público da Anthropic

E tem mais: há relato de 9 processos do app somando 1,18 GB de RAM sem nenhuma conversa aberta (Issue #40633)

O que fazer: identifique o processo antes de acusar o app inteiro, porque "Claude Desktop pesado" e "uma VM subindo junto" são problemas diferentes, com respostas diferentes

E feche o app de verdade quando terminar, minimizar não é fechar

Prevenção: se a máquina é apertada, não deixe o app subindo junto com o sistema, abra quando for usar

Sintoma: disco escrevendo sem parar e CPU alta com o app ocioso

Esse aqui é o que mais engana, porque a máquina fica lenta "do nada"

No Windows, há relato de cerca de 25% de CPU e aproximadamente 5 MB/s de escrita contínua com o app OCIOSO, e a causa apontada é a forma como ele persiste o cache de conversas: o persistQueryClient (TanStack Query) regrava o blob inteiro do cache, de cerca de 45 MB, no IndexedDB a cada mutação

Sacou a conexão? Nesse relato do Windows, quanto maior o cache de conversas, maior o blob que é regravado inteiro a cada mutação

O resultado é assustador: 67,9 GB escritos em 4 horas ociosas (Issue #58799)

No macOS o sintoma é parecido, mas o relato aponta OUTRO caminho: cerca de 13 GB gravados em menos de 1 hora ligados ao diretório vm_bundles/claudevm.bundle/, com picos de CPU do apfsd e do indexador do Spotlight, e escrita sustentada de 2.000 a 5.000 KB/s contra um limite de watchdog do macOS de cerca de 99 KB/s, na versão 1.569.0 (Issue #43390)

Ou seja: disco sofrendo nos dois sistemas, mecanismo relatado diferente em cada um

Não junte os dois numa explicação só, senão você trata o sintoma errado

O que fazer: meça a escrita em disco (não só a CPU) e feche o app quando não estiver usando, principalmente em notebook

Prevenção: aqui não tem ajuste de configuração do seu lado que desligue esse comportamento, a causa apontada está no código do app. O que sobra pra você é reduzir o tempo com ele aberto e acompanhar a issue

Sintoma: você digita e a mensagem demora a aparecer

Tem coisa mais irritante? Você escreve e a letra aparece com atraso, tipo conexão discada

Há relato de travamentos periódicos de digitação no app de desktop no Windows ligados ao volume de dados locais sincronizados pelo renderer: sync de 88 MB de LocalStorage e callbacks de IndexedDB acima de 200 ms bloqueando a main thread (Issue #55149)

E tem um caso ainda mais extremo, com mais de 18 segundos de lag de input, atribuído a um loop de renderização do React (Issue #31643)

O que é a main thread aqui? É a fila única onde o app desenha a tela E processa o que você digita

Se alguém ocupa essa fila com um bloco pesado de dados, sua tecla fica esperando a vez

É por isso que conversa muito longa e histórico local grande cobram caro no app de desktop

O que fazer: quebre a tarefa em conversas novas em vez de esticar uma thread infinita

Prevenção: trate chat longo como custo, não como conveniência

E se a lentidão for na RESPOSTA e não na digitação, o suspeito pode ser outro: vale checar antes se o problema está no modelo lento, e não no app

Sintoma: engasga ao abrir chat novo ou alternar entre conversas

Tem gente que só sente o peso em dois momentos: ao criar chat novo e ao trocar de chat

Existe relato exatamente desse padrão, com stutter de cursor e carga de compositing de GPU do Electron nessas duas ações, e sem caminho exposto para desativar a aceleração de hardware na distribuição Windows/MSIX (Issue #77857)

E aqui vai o aviso importante, porque a internet adora repetir "desliga a aceleração de hardware" como se fosse remédio universal

Não é 😛

Há relato de busy-loop de 100% de CPU antes mesmo de pintar a interface quando isHardwareAccelerationDisabled=true, com a flag sendo persistida automaticamente após crash de GPU, o que deixa o app inutilizável no Linux (Issue #76307)

Ou seja: a "solução" pode te trancar do lado de fora

Tome cuidado

Também existe relato de renderer consumindo mais de 80% do total de CPU no macOS, inclusive ocioso (Issues #32010 e #32012)

O que fazer: registre o padrão antes de aplicar qualquer flag. É só ao trocar de chat? É sempre? É só depois de horas aberto?

Esse registro é o que separa "meu app engasga" de "meu app engasga NO compositing", e a segunda frase é a que resolve alguma coisa

Sintoma: parece o app, mas é o que você plugou nele

Essa é a parte que quase ninguém checa

Extensões e servidores MCP não são configuração, eles RODAM, e entram na conta de recurso da máquina igual qualquer outro programa

Onde revisar:

• Extensões: Settings > Extensions no Claude Desktop, com o botão Browse extensions levando pro diretório de extensões
• Conectores da conversa: botão + na parte de baixo da caixa de chat, opção Connectors, que mostra os servidores MCP conectados e as ferramentas de cada um

E onde mora a configuração dos servidores MCP locais:

macOS:   ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Método, e esse é o pulo do gato: desligue UM por vez e meça de novo

Se você desligar seis extensões de uma vez e o problema sumir, você não descobriu nada, só perdeu seis extensões

Prevenção: manter conectado só o que você usa de fato

Aquele servidor MCP que você plugou pra testar num sábado e nunca mais abriu? Ele continua ali, trabalhando pra ninguém

Nem tudo é peso: quando o problema é permissão ou requisito

Dois desvios que viram falso diagnóstico com facilidade

Primeiro: permissão no macOS. O Claude Desktop precisa de Acesso Total ao Disco pra ler arquivos, e sem isso as leituras falham em silêncio

O caminho é Ajustes do Sistema > Privacidade e Segurança > Acesso Total ao Disco

Repara no efeito: falha em silêncio parece travamento, e travamento parece lentidão, e aí você culpa a máquina quando era um botão de permissão

Segundo: requisito de hardware. Os requisitos publicados oficialmente são de versão de sistema operacional, macOS 11 (Big Sur) ou posterior e Windows 10 ou posterior, com app disponível pra macOS, Windows e Linux (beta)

Não existe piso oficial de RAM publicado pra você apontar como culpado, então "meu PC não é da Nasa" não é diagnóstico, é desabafo haha

O que fazer: confirme permissão e versão de sistema ANTES de concluir que a máquina não aguenta

Se o app nem chega a abrir direito, o roteiro é outro e passa por instalação no Windows, não por consumo de recurso

O que fazer agora

Recapitulando a ordem, que é o que importa aqui:

1. Medir por processo, separando CPU de escrita em disco
2. Confirmar que o app está atualizado
3. Cortar extensões e conectores que você não usa, um por vez
4. Encurtar conversas em vez de esticar uma thread eterna
5. Só então concluir alguma coisa

E o limite honesto: boa parte do que está aqui é bug reportado publicamente, com relato de consumo alto em idle, escrita massiva em disco e renderer dominando a CPU

Isso não é configuração do usuário, e o estado de cada relato pode mudar de uma versão pra outra

Então acompanhar as issues faz parte da resposta, não é fuga do problema

Próximo passo prático: refaça a medição depois de CADA mudança, uma de cada vez

É mais lento? É

Mas é a única forma de saber o que resolveu, em vez de sair mexendo em tudo e rezar

Até o próximo post! 😀