# Cursor High CPU or Memory on Mac: Find the Busy Work

> Test extensions, workspace scope and generated files to diagnose Cursor CPU and memory use without wiping project data or chat history.

Published: 2026-10-23 | Updated: 2026-10-25

Cursor can make a Mac feel slow for several different reasons: a busy extension, a large workspace being processed, a long-running AI task or a process that keeps consuming memory after the work stops. Start by finding which action causes the increase. A large cache folder is not evidence that deleting it will fix CPU usage.

## Keep one reproducible comparison

Save the project and note Cursor's version. Open **Activity Monitor**, search for Cursor, and compare CPU and memory before opening the project, while reproducing the problem and after the task stops. Keep the same repository and action for each test.

If a small folder behaves normally but a monorepo does not, workspace scope is a useful lead. If a new chat is responsive while one long conversation is not, test that separately. If usage rises steadily under a repeated workload, record the growth and elapsed time. One large reading alone does not establish a memory leak.

## Separate the editor from work it launches

A Cursor session may include the editor window, extensions, a language server, terminals and an AI task. Some of that work can continue while the editor is idle. Before disabling anything, check whether a terminal is still running a build, test watcher, development server or model. Stop only a job you recognize through the terminal or application's normal control, after saving its work.

In Activity Monitor, compare the busy process at three points: with the workspace open but no task started, during the action that feels slow, and after that action finishes. Record the process name and whether the symptom is input delay, high CPU or increasing memory. A helper process name by itself rarely identifies the responsible extension, so use the next comparisons to narrow it down.

Try opening the actual project folder rather than its parent containing several repositories. Do not move or delete the project to perform this test. If a smaller workspace improves the result, determine what the broader workspace included: generated assets, another project's dependencies, an active watcher or a language tool scanning more files. This is evidence about scope, not a reason to exclude every large directory.

For instance, a development server repeatedly writing output may be active work that the editor observes. A folder exclusion and stopping that server test different explanations. Changing both at once loses the distinction, so record which single change affects the repeated action.

## Test extensions before resetting the editor

Cursor's [performance guide](https://cursor.com/help/troubleshooting/performance) recommends an extension-disabled run. After saving work and quitting Cursor normally, launch it from Terminal with:

```
cursor --disable-extensions
```

This assumes the `cursor` shell command is installed. If it is unavailable, use Cursor's Extensions view to disable nonessential extensions for the comparison. Keep a record of what you disabled so the test is reversible.

Repeat the same project action. If it improves, restore extensions one at a time until the symptom returns. If it does not, restore the prior extension state and continue. Do not treat a test with different files open as proof against an extension, and do not remove the whole user-data directory as the next step.

## Narrow a successful extension test

If the extension-disabled run improves the same action, do not reinstall all extensions or discard their settings. Start from the recorded enabled set and restore one at a time when there are only a few candidates. With many extensions, restoring half at a time can narrow the group faster, provided each test opens the same project and completes the same action.

The group method is an investigation shortcut, not proof that there is exactly one faulty extension. Two extensions may interact, and disabling a language extension can also remove features that trigger the workload. Once a candidate emerges, repeat the test with all the extensions you actually need enabled except that candidate. Check code completion, diagnostics and the build as well as responsiveness.

If the final comparison still points to one extension, record its name and version. A workspace-only disable can be more suitable than changing every project, where that option exists. If disabling it breaks a required feature, restore it and keep the reproduction for its maintainer instead of treating a faster but incomplete editor as the desired result.

## Exclude generated output you do not need

AI-assisted work can produce build output, exported bundles, generated images and large logs. Opening a parent folder containing every project can expose far more material than the task needs. Open the actual project root first.

Cursor documents [`.cursorignore`](https://cursor.com/docs/reference/ignore-file) for restricting AI access to project files, with exceptions for terminal and MCP tools. Its performance guide recommends excluding large generated folders. This is broader than an indexing-only change, and it does not stop every language server or filesystem watcher.

For a project where these directories really are generated output, a `.cursorignore` file can contain:

```
dist/
build/
.next/
```

Inspect the folders first and preserve existing ignore rules. A directory called `build` might contain hand-maintained build scripts in your project. Adding a pattern does not delete files, but it can remove useful context from AI features. Recheck the indexing state and the same editor action afterward.

## Follow the process that is still working

| Observation | What to investigate next |
| --- | --- |
| The problem disappears without extensions | Restore extensions individually |
| Only one large workspace triggers it | Project root, generated output and language tools |
| CPU settles when an AI task ends | Task workload and concurrency |
| Memory keeps increasing during the same repeated action | A reproducible report with version and timing |
| The whole Mac slows down | Memory pressure and other active apps |

The [Mac memory-pressure guide](https://mole.fit/blog/mac-memory-pressure-explained) explains why used memory alone is not a reliable alarm. Closing an unused workspace can help an active workload without deleting its contents.

## Check what an exclusion changed

After changing `.cursorignore`, inspect the file diff and test both the slow action and an ordinary question about code that should remain accessible. A smaller visible project context is only useful if Cursor still has the source needed for the task. Remove just the new pattern if it excluded something important; do not replace the whole ignore file with an empty one.

Keep these boundaries separate. Git ignore rules govern Git's treatment of untracked files. Cursor's AI-access exclusions govern the documented AI features. A language server, extension or terminal watcher has its own behavior. Adding the same pattern everywhere without identifying the busy component can hide symptoms and remove useful functionality.

If CPU is normal but an answer is slow to arrive, investigate the AI request separately from editor resource use. If memory rises on every repetition even after the work finishes, record several comparable readings and the elapsed intervals, then test whether reopening the workspace changes the pattern. That is much more useful to a maintainer than reporting the largest number seen during a build.

## Clean disk leftovers only when disk space is the problem

Cursor caches, old tool versions, session histories and worktrees have different owners and recovery needs. A worktree may contain uncommitted changes or a commit that exists nowhere else. A chat history may be work you still need.

Use the [AI coding-tool cleanup guide](https://mole.fit/blog/how-to-clean-up-ai-coding-tools-mac) for that separate storage task. For persistent CPU or memory trouble, send Cursor the smallest reproducible case, the version and the extension comparison. Review logs before sharing them because they can contain project names or code. This keeps the report about the actual slowdown rather than an unrelated cleanup result.

---

Canonical HTML page: https://mole.fit/blog/cursor-high-cpu-memory-mac
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt