Cursor utilise beaucoup de CPU ou de mémoire sur Mac : identifier le travail en cours

Cursor peut ralentir un Mac pour plusieurs raisons différentes : une extension occupée, un grand espace de travail en cours de traitement, une tâche d’IA de longue durée ou un processus qui continue de consommer de la mémoire après l’arrêt du travail. Commencez par identifier l’action qui provoque cette augmentation. Un dossier de cache volumineux ne prouve pas que le supprimer corrigera l’utilisation du CPU.

Conserver une comparaison reproductible

Enregistrez le projet et notez la version de Cursor. Ouvrez le Moniteur d’activité, recherchez Cursor et comparez le CPU et la mémoire avant d’ouvrir le projet, pendant la reproduction du problème et après l’arrêt de la tâche. Conservez le même dépôt et la même action pour chaque test.

Si un petit dossier se comporte normalement mais qu’un monorepo ne le fait pas, la portée de l’espace de travail est une piste utile. Si une nouvelle conversation répond alors qu’une longue conversation ne répond pas, testez ce point séparément. Si l’utilisation augmente régulièrement sous une charge de travail répétée, notez la croissance et le temps écoulé. Une seule mesure élevée ne suffit pas à établir une fuite de mémoire.

Séparer l’éditeur du travail qu’il lance

Une session Cursor peut inclure la fenêtre de l’éditeur, des extensions, un serveur de langage, des terminaux et une tâche d’IA. Une partie de ce travail peut continuer pendant que l’éditeur est inactif. Avant de désactiver quoi que ce soit, vérifiez si un terminal exécute encore une compilation, un observateur de tests, un serveur de développement ou un modèle. Arrêtez uniquement une tâche que vous reconnaissez, via le contrôle normal du terminal ou de l’application, après avoir enregistré son travail.

Dans Moniteur d’activité, comparez le processus occupé à trois moments : avec l’espace de travail ouvert mais aucune tâche lancée, pendant l’action qui semble lente, et après la fin de cette action. Notez le nom du processus et si le symptôme est un délai de saisie, une charge CPU élevée ou une mémoire croissante. Un nom de processus auxiliaire ne suffit généralement pas à identifier l’extension responsable ; utilisez les comparaisons suivantes pour la cibler.

Essayez d’ouvrir le dossier réel du projet plutôt que son parent contenant plusieurs dépôts. Ne déplacez ni ne supprimez le projet pour effectuer ce test. Si un espace de travail plus restreint améliore le résultat, déterminez ce que l’espace de travail plus large incluait : des ressources générées, les dépendances d’un autre projet, un observateur actif ou un outil de langage analysant davantage de fichiers. C’est un indice sur l’étendue, pas une raison d’exclure systématiquement tout dossier volumineux.

Par exemple, un serveur de développement qui écrit constamment sa sortie peut être un travail actif que l’éditeur observe. Une exclusion de dossier et l’arrêt de ce serveur testent des explications différentes. Changer les deux à la fois fait perdre la distinction ; notez donc quelle modification unique influe sur l’action répétée.

Tester les extensions avant de réinitialiser l’éditeur

Le guide de performance de Cursor recommande un lancement avec les extensions désactivées. Après avoir enregistré votre travail et quitté Cursor normalement, lancez-le depuis le Terminal avec :

cursor --disable-extensions

Cela suppose que la commande shell cursor est installée. Si elle n’est pas disponible, utilisez la vue Extensions de Cursor pour désactiver les extensions non essentielles aux fins de la comparaison. Notez ce que vous avez désactivé afin que le test soit réversible.

Répétez la même action sur le projet. Si la situation s’améliore, réactivez les extensions une par une jusqu’à ce que le symptôme réapparaisse. Si ce n’est pas le cas, rétablissez l’état précédent des extensions et poursuivez. Ne considérez pas un test avec d’autres fichiers ouverts comme une preuve contre une extension, et ne supprimez pas tout le répertoire des données utilisateur comme étape suivante.

Cibler un test d’extension réussi

Si l’exécution avec extensions désactivées améliore la même action, ne réinstallez pas toutes les extensions et ne supprimez pas leurs réglages. Partez de l’ensemble activé noté et restaurez les extensions une par une s’il n’y a que quelques candidates. Avec de nombreuses extensions, restaurer la moitié à la fois peut réduire le groupe plus vite, à condition que chaque test ouvre le même projet et accomplisse la même action.

La méthode par groupes est un raccourci d’investigation, pas la preuve qu’il existe exactement une extension défaillante. Deux extensions peuvent interagir, et désactiver une extension de langage peut aussi retirer des fonctionnalités qui déclenchent la charge. Une fois une candidate identifiée, répétez le test avec toutes les extensions réellement nécessaires activées sauf cette candidate. Vérifiez la complétion de code, les diagnostics et la compilation, ainsi que la réactivité.

Si la comparaison finale désigne toujours une seule extension, notez son nom et sa version. Une désactivation limitée à l’espace de travail peut être plus adaptée que de modifier tous les projets, lorsque cette option existe. Si la désactiver casse une fonctionnalité requise, réactivez-la et conservez la reproduction pour son mainteneur au lieu de considérer un éditeur plus rapide mais incomplet comme le résultat souhaité.

Exclure les sorties générées dont vous n’avez pas besoin

Le travail assisté par IA peut produire des sorties de compilation, des bundles exportés, des images générées et des journaux volumineux. Ouvrir un dossier parent contenant tous les projets peut exposer bien plus d’éléments que la tâche n’en a besoin. Ouvrez d’abord la racine réelle du projet.

Cursor documente .cursorignore pour restreindre l’accès de l’IA aux fichiers du projet, avec des exceptions pour le terminal et les outils MCP. Son guide de performance recommande d’exclure les grands dossiers générés. Cela va au-delà d’une simple modification de l’indexation et n’arrête pas tous les serveurs de langage ni les surveillants du système de fichiers.

Pour un projet où ces répertoires sont réellement des sorties générées, un fichier .cursorignore peut contenir :

dist/
build/
.next/

Inspectez d’abord les dossiers et conservez les règles d’exclusion existantes. Un répertoire nommé build peut contenir des scripts de compilation maintenus manuellement dans votre projet. L’ajout d’un motif ne supprime pas de fichiers, mais peut retirer un contexte utile aux fonctionnalités d’IA. Vérifiez à nouveau l’état de l’indexation et la même action dans l’éditeur par la suite.

Suivre le processus qui fonctionne encore

Le guide sur la pression sur la mémoire du Mac explique pourquoi la mémoire utilisée seule n’est pas une alarme fiable. Fermer un espace de travail inutilisé peut aider une charge de travail active sans en supprimer le contenu.

Vérifier ce qu’une exclusion a changé

Après avoir modifié .cursorignore, inspectez le diff du fichier et testez à la fois l’action lente et une question ordinaire sur du code qui doit rester accessible. Un contexte de projet visible plus restreint n’est utile que si Cursor dispose encore des sources nécessaires à la tâche. Retirez uniquement le nouveau motif s’il a exclu quelque chose d’important ; ne remplacez pas tout le fichier d’ignore par un fichier vide.

Gardez ces limites distinctes. Les règles Git ignore régissent le traitement par Git des fichiers non suivis. Les exclusions d’accès à l’IA de Cursor régissent les fonctionnalités d’IA documentées. Un serveur de langage, une extension ou un observateur de terminal a son propre comportement. Ajouter le même motif partout sans identifier le composant occupé peut masquer des symptômes et retirer des fonctionnalités utiles.

Si le CPU est normal mais qu’une réponse tarde à arriver, étudiez la requête d’IA séparément de l’utilisation des ressources de l’éditeur. Si la mémoire augmente à chaque répétition même après la fin du travail, notez plusieurs relevés comparables et les intervalles écoulés, puis testez si rouvrir l’espace de travail change le schéma. C’est bien plus utile à un mainteneur que de signaler la valeur maximale observée pendant une compilation.

Nettoyer les restes sur le disque uniquement lorsque l’espace disque est le problème

Les caches de Cursor, les anciennes versions d’outils, les historiques de session et les worktrees ont des propriétaires et des besoins de récupération différents. Un worktree peut contenir des modifications non validées ou un commit qui n’existe nulle part ailleurs. Un historique de conversation peut représenter un travail dont vous avez encore besoin.

Utilisez le guide de nettoyage des outils de codage IA pour cette tâche de stockage distincte. En cas de problème persistant de CPU ou de mémoire, envoyez à Cursor le plus petit cas reproductible, la version et la comparaison des extensions. Examinez les journaux avant de les partager, car ils peuvent contenir des noms de projet ou du code. Cela permet de garder le rapport centré sur le ralentissement réel plutôt que sur un résultat de nettoyage sans rapport.