Cursor com alto uso de CPU ou memória no Mac: encontre o trabalho que está consumindo recursos

O Cursor pode deixar um Mac lento por vários motivos diferentes: uma extensão ocupada, um workspace grande sendo processado, uma tarefa de IA de longa duração ou um processo que continua consumindo memória depois que o trabalho termina. Comece descobrindo qual ação provoca o aumento. Uma pasta de cache grande não é evidência de que apagá-la vai corrigir o uso de CPU.

Mantenha uma comparação reproduzível

Salve o projeto e anote a versão do Cursor. Abra o Monitor de Atividade, procure por Cursor e compare CPU e memória antes de abrir o projeto, durante a reprodução do problema e depois que a tarefa parar. Mantenha o mesmo repositório e a mesma ação em cada teste.

Se uma pasta pequena se comporta normalmente mas um monorepo não, o escopo do workspace é uma pista útil. Se um chat novo responde bem enquanto uma conversa longa não, teste isso separadamente. Se o uso sobe continuamente sob uma carga de trabalho repetida, registre o crescimento e o tempo decorrido. Uma única leitura alta não estabelece um vazamento de memória.

Separe o editor do trabalho que ele inicia

Uma sessão do Cursor pode incluir a janela do editor, extensões, um servidor de linguagem, terminais e uma tarefa de IA. Parte desse trabalho pode continuar enquanto o editor está ocioso. Antes de desativar qualquer coisa, verifique se um terminal ainda está executando um build, um observador de testes, um servidor de desenvolvimento ou um modelo. Interrompa apenas uma tarefa que você reconhece, pelo controle normal do terminal ou da aplicação, depois de salvar o trabalho dela.

No Monitor de Atividade, compare o processo ocupado em três momentos: com o workspace aberto mas sem nenhuma tarefa iniciada, durante a ação que parece lenta e depois que essa ação termina. Anote o nome do processo e se o sintoma é atraso na entrada, uso alto de CPU ou aumento de memória. O nome de um processo auxiliar, por si só, raramente identifica a extensão responsável, então use as próximas comparações para restringir.

Tente abrir a pasta real do projeto em vez da pasta pai que contém vários repositórios. Não mova nem exclua o projeto para fazer esse teste. Se um workspace menor melhorar o resultado, determine o que o workspace mais amplo incluía: recursos gerados, dependências de outro projeto, um observador ativo ou uma ferramenta de linguagem lendo mais arquivos. Isso é evidência sobre o escopo, não um motivo para excluir todo diretório grande.

Por exemplo, um servidor de desenvolvimento gravando saída repetidamente pode ser trabalho ativo que o editor observa. Excluir uma pasta e parar esse servidor testam explicações diferentes. Alterar os dois ao mesmo tempo elimina a distinção, então registre qual única alteração afeta a ação repetida.

Teste extensões antes de redefinir o editor

O guia de desempenho do Cursor recomenda uma execução com extensões desativadas. Depois de salvar o trabalho e encerrar o Cursor normalmente, inicie-o pelo Terminal com:

cursor --disable-extensions

Isso pressupõe que o comando de shell cursor esteja instalado. Se ele não estiver disponível, use a visão de Extensões do Cursor para desativar extensões não essenciais para a comparação. Mantenha um registro do que você desativou para que o teste seja reversível.

Repita a mesma ação no projeto. Se melhorar, restaure as extensões uma a uma até o sintoma voltar. Se não melhorar, restaure o estado anterior das extensões e continue. Não trate um teste com arquivos diferentes abertos como prova contra uma extensão, e não remova o diretório inteiro de dados do usuário como próximo passo.

Restrinja um teste de extensão bem-sucedido

Se a execução com extensões desativadas melhorar a mesma ação, não reinstale todas as extensões nem descarte as configurações delas. Parta do conjunto habilitado registrado e restaure uma de cada vez quando houver poucos candidatos. Com muitas extensões, restaurar metade de cada vez pode restringir o grupo mais rápido, desde que cada teste abra o mesmo projeto e conclua a mesma ação.

O método de grupos é um atalho de investigação, não uma prova de que existe exatamente uma extensão defeituosa. Duas extensões podem interagir, e desativar uma extensão de linguagem também pode remover recursos que acionam a carga de trabalho. Quando surgir um candidato, repita o teste com todas as extensões que você realmente precisa habilitadas, exceto esse candidato. Verifique a conclusão de código, os diagnósticos e o build, além da capacidade de resposta.

Se a comparação final ainda apontar para uma extensão, registre o nome e a versão dela. Desativar apenas no workspace pode ser mais adequado do que alterar todos os projetos, onde essa opção existir. Se desativá-la quebrar um recurso necessário, restaure-a e guarde a reprodução para o mantenedor dela, em vez de tratar um editor mais rápido mas incompleto como o resultado desejado.

Exclua saída gerada de que você não precisa

O trabalho assistido por IA pode produzir saída de build, pacotes exportados, imagens geradas e logs grandes. Abrir uma pasta pai que contém todos os projetos pode expor muito mais material do que a tarefa precisa. Abra primeiro a raiz real do projeto.

O Cursor documenta .cursorignore para restringir o acesso da IA aos arquivos do projeto, com exceções para o terminal e ferramentas MCP. Seu guia de desempenho recomenda excluir pastas geradas grandes. Isso é mais amplo que uma mudança apenas de indexação, e não impede todo servidor de linguagem ou observador de sistema de arquivos.

Para um projeto em que esses diretórios realmente são saída gerada, um arquivo .cursorignore pode conter:

dist/
build/
.next/

Inspecione as pastas primeiro e preserve as regras de ignore existentes. Um diretório chamado build pode conter scripts de build mantidos manualmente no seu projeto. Adicionar um padrão não apaga arquivos, mas pode remover contexto útil dos recursos de IA. Verifique novamente o estado de indexação e a mesma ação no editor depois.

Acompanhe o processo que ainda está funcionando

O guia de pressão da memória no Mac explica por que a memória usada sozinha não é um alarme confiável. Fechar um workspace não utilizado pode ajudar uma carga de trabalho ativa sem apagar seu conteúdo.

Verifique o que uma exclusão alterou

Depois de alterar .cursorignore, inspecione o diff do arquivo e teste tanto a ação lenta quanto uma pergunta comum sobre código que deve continuar acessível. Um contexto visível de projeto menor só é útil se o Cursor ainda tiver o código-fonte necessário para a tarefa. Remova apenas o novo padrão se ele excluiu algo importante; não substitua o arquivo de ignore inteiro por um vazio.

Mantenha esses limites separados. As regras de ignore do Git governam o tratamento do Git para arquivos não rastreados. As exclusões de acesso da IA do Cursor governam os recursos de IA documentados. Um servidor de linguagem, uma extensão ou um observador de terminal tem comportamento próprio. Adicionar o mesmo padrão em todos os lugares sem identificar o componente ocupado pode ocultar sintomas e remover funcionalidades úteis.

Se a CPU estiver normal mas uma resposta demorar a chegar, investigue a solicitação de IA separadamente do uso de recursos do editor. Se a memória aumentar a cada repetição mesmo depois que o trabalho terminar, registre várias leituras comparáveis e os intervalos decorridos, depois teste se reabrir o workspace muda o padrão. Isso é muito mais útil para um mantenedor do que relatar o maior número visto durante um build.

Limpe sobras de disco apenas quando o espaço em disco for o problema

Caches do Cursor, versões antigas de ferramentas, históricos de sessão e worktrees têm donos e necessidades de recuperação diferentes. Uma worktree pode conter alterações não commitadas ou um commit que não existe em nenhum outro lugar. Um histórico de chat pode ser um trabalho de que você ainda precisa.

Use o guia de limpeza de ferramentas de programação com IA para essa tarefa de armazenamento separada. Para problemas persistentes de CPU ou memória, envie ao Cursor o menor caso reproduzível, a versão e a comparação de extensões. Revise os logs antes de compartilhá-los, porque eles podem conter nomes de projetos ou código. Isso mantém o relatório sobre a lentidão real em vez de um resultado de limpeza não relacionado.