How I Stopped Cursor from Using 72 GB of Memory

I knew something was wrong when macOS displayed the “Your system has run out of application memory” warning. Cursor was using more than 72 GB in the screenshot. After restarting it, the memory usage quickly climbed above 8 GB again. This was not normal editor usage, so I investigated the running processes, local chat storage, file watchers, and workspace configuration. Here is what I found and how you can prevent the same problem.

What Was Causing It?

There was no single cause. Several problems were multiplying each other:

• Cursor’s local chat database had grown to 9.1 GB.
• Hundreds of Agent conversations and checkpoints were stored locally.
• Old Cursor Helper processes remained alive after Cursor was closed.
• A large multi-root workspace contained nine repositories.
• My home directory was also open as a workspace.
• Multiple Agent windows, language servers, and MCP servers were running.
• Watchman was still monitoring old repositories and Agent worktrees.

Together, these caused Cursor’s renderer and helper processes to consume an extreme amount of memory.

Step 1: Quit Cursor Completely

Closing a Cursor window does not always quit the application. Use Cmd+Q on macOS. It is also a good idea to restart Cursor regularly instead of leaving it running for several days.

After quitting, check whether any Cursor processes remain:

ps -eo pid,ppid,rss,etime,command | awk '(/\/Applications\/Cursor\.app/ || /Cursor Helper/) && !/awk/ && !/CursorUIViewService/'

If the command returns nothing, Cursor has stopped correctly. If you still see processes whose parent process ID (PPID) is 1, they are orphaned processes left behind by an earlier Cursor session.

Step 2: Stop Orphaned Cursor Processes

First, try to stop them gracefully:

pkill -TERM -f '/Applications/Cursor.app|Cursor Helper'

Wait a few seconds and run the process check again. If the processes are still present, force-stop them:

killall -9 "Cursor Helper" "Cursor Helper (Plugin)" "Cursor Helper (Renderer)" Cursor 2>/dev/null

Only run these commands while Cursor is closed. Otherwise, they will terminate your active Cursor session.

Step 3: Check the Cursor Chat Database

Cursor stores Agent conversations, messages, checkpoints, and related data in a local SQLite database. On macOS, check its size with:

ls -lh ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb

In my case, this file was 9.1 GB. A closer inspection showed approximately 4.2 GB of chat message data, 3.2 GB of Agent key-value data, and 693 MB of checkpoints. A very large database increases disk usage and can also increase memory consumption when Cursor loads, searches, or renders conversation history.

Step 4: Delete Old Chats from Cursor

Do not delete state.vscdb manually. Doing so can break Cursor’s chat index and leave old conversations stuck on “Loading Chat.”

Use Cursor’s built-in cleanup commands:

1. Open the Command Palette with Cmd+Shift+P.
2. Run Developer: Delete Old Chats…
3. Select a retention period, such as 14 or 30 days.
4. Wait for the cleanup to finish.
5. Open the Command Palette again.
6. Run Developer: GC Agent KV Blobs.

The second command removes orphaned Agent data that is no longer connected to a visible chat. Run these commands once a month—or every two weeks if you use Agent heavily.

Archiving or closing a chat is not the same as deleting it. To remove one conversation completely, open Chat History, click its three-dot menu, and select Delete.

Step 5: Do Not Open Your Home Directory as a Workspace

Avoid opening paths such as:

/Users/your-name

This can make Cursor, extensions, and file watchers scan large folders such as Library, Downloads, application caches, package caches, virtual machines, and every project under your home directory. Open only the repository or folder you are actively working on.

Step 6: Keep Workspaces Small

A workspace containing many large repositories may start multiple file watchers, Git processes, language servers, search services, and Cursor extension hosts. Instead of opening nine repositories in one workspace, create smaller workspaces for related projects. In most cases, opening one or two repositories is enough.

Step 7: Close Unused Agent Windows

An Agent window is not free. It may run its own renderer, extension host, file watcher, and supporting services. Close unused Agent windows, empty Cursor windows, old background Agent sessions, and workspaces you are no longer using.

Step 8: Disable Unused MCP Servers

Every enabled MCP integration may start another local process or maintain a remote connection. Disable browser automation, project-management integrations, communication tools, and other services when you do not need them. You can enable them again later.

Step 9: Reset Old Watchman Watches

If you use Watchman, old repositories and temporary Agent worktrees may remain registered after Cursor closes. List the watched directories:

watchman watch-list

Remove all existing watches:

watchman watch-del-all

Cursor and your development tools will register the necessary directories again when they restart. If Watchman itself is stuck, stop it:

killall watchman 2>/dev/null

Step 10: Exclude Generated and Dependency Folders

Large generated directories do not usually need to be watched or searched. Add suitable exclusions to your Cursor settings:

{
  "files.watcherExclude": {
    "**/.git/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/vendor/**": true,
    "**/.cache/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/vendor": true
  }
}

Adjust the list for your project. Do not exclude directories that contain source files you need Cursor to index.

Step 11: Monitor Cursor’s Total Memory

Cursor is an Electron application. Its memory is spread across renderers, extension hosts, language servers, and file watchers. To see the total resident memory used by Cursor-related processes:

ps -axo rss,command | awk '/Cursor Helper|\/Applications\/Cursor\.app/ {total += $1} END {printf "Cursor RSS: %.2f GB\n", total / 1024 / 1024}'

The number shown by macOS may also include compressed or swapped application memory, so it can be higher than the machine’s physical RAM.

A Simple Maintenance Routine

1. Quit Cursor with Cmd+Q at the end of the day.
2. Check for orphaned processes after a crash or Force Quit.
3. Delete old chats every few weeks.
4. Run GC Agent KV Blobs after deleting chats.
5. Open only the repositories you are actively using.
6. Keep Agent windows and MCP servers to a minimum.
7. Check state.vscdb before it grows into multiple gigabytes.
8. Reset stale Watchman watches when CPU usage looks unusual.

Final Thoughts

Cursor did not reach 72 GB because of one open source file. The real problem was accumulated Agent history combined with orphaned processes, oversized workspaces, file watchers, language servers, and extra integrations.

Cursor can be a powerful development tool, but Agent-heavy workflows need occasional maintenance. A smaller workspace, a clean chat database, and a complete restart can make the difference between a responsive editor and a system-wide memory warning.