Severe Memory Leak (~4.16GB per window) & Massive Swap (28GB) AFTER Closing Project Window

[enesbulut]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am reporting a severe memory leak that occurs specifically after closing a project window on macOS.

While actively working in a repository, RAM consumption is completely normal. However, when I close the project window (clicking the red ‘X’ on macOS) and leave the app running in the background, the memory usage for that specific closed instance slowly climbs up to exactly ~4.16 GB and stays there permanently.

Since I work with 3-5 different repositories a day, closing them leaves multiple “ghost” processes consuming ~4GB each. This quickly exhausts the physical RAM and forces the system to use heavy Swap Memory.

The Real Impact (Why this is critical): This issue caused such extreme system freezes and lag on both my and my teammate’s machines (M2 Pro 16GB) that we genuinely believed our hardware was no longer sufficient for our workflow. Because of this specific memory leak, we were forced to upgrade and purchase two brand new M4 Pro MacBooks with 24GB of RAM.

Only after spending thousands of dollars on new hardware did we realize that the exact same RAM spiking issue persists on the new machines. Because of these lingering “ghost” processes, I recently caught my macOS Swap Memory usage spiking up to an astonishing 28 GB. This is not just a performance issue; it is severely degrading our SSD lifespans (wear and tear).

Steps to Reproduce

Open any repository in Cursor on macOS.
Observe Activity Monitor (RAM usage is completely normal).
Close the project window using the red ‘X’ on macOS (do not Quit the app entirely with Cmd+Q, just close the window).
Watch the Activity Monitor: The RAM usage for the background process starts climbing slowly until it hits exactly ~4.16 GB and plateaus.
Open and close multiple projects throughout the day to see RAM exhaust completely and Swap memory spike to 20+ GB.

Expected Behavior

When a project window is closed, all child processes (including MCP servers, language servers, and extension hosts tied to that specific window) should receive a SIGTERM and terminate cleanly. The memory should be fully released back to the system immediately, rather than climbing to 4GB and becoming an orphaned ghost process.

Operating System

MacOS

Version Information

Version: 2.6.13
VSCode Version: 1.105.1
Commit: 60faf7b51077ed1df1db718157bbfed740d2e160
Date: 2026-03-06T06:17:49.499Z (3 days ago)
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.2.0

For AI issues: which model did you use?

Composer 1.5, Opus, Gemini

For AI issues: add Request ID with privacy disabled

HARDWARE IMPACT: This issue was so severe that it caused extreme system freezes on both my and my teammate’s machines (M2 Pro 16GB). We actually thought our hardware was bottlenecking and could no longer handle modern development, so we both recently spent a lot of money to upgrade to M4 Pro 24GB MacBooks, only to discover that the exact same RAM spiking issue persists. It is clearly a specific memory leak in Cursor, not a hardware limitation.

I noticed on the forum that other users recently reported issues like “MCP server process leaks consuming 3-5GB”. I suspect my issue is directly related to this. It seems that child processes are becoming orphaned and failing to terminate when a window is closed. Please prioritize investigating this, as it is causing severe SSD wear and tear due to the 28GB swap usage.

Additional Information

I noticed on the forum that your team is aware of similar issues (like “MCP server process leaks” and “RAM not resetting”). I strongly suspect my issue is directly related. It seems that child processes become orphaned and enter an endless loop when a window is closed.

Please prioritize a proper cleanup mechanism for child processes upon window close. This is causing massive frustration, hardware damage risks (28GB swap), and forced unnecessary hardware upgrades for your users.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report and the video.

I took a look at your Activity Monitor screenshot. The top process is extension-host (user) apiv3.wask.co, using several GB, and there are a few more extension-host processes tied to wask-backend-services taking a few hundred MB each. This is a third-party AI extension, and it’s very likely the main cause of the memory issue.

We recently had an almost identical case. A user had multiple AI extensions running alongside Cursor’s built-in AI. Memory usage was over 30 GB, and after disabling them it dropped to about 1,5 GB: Cursor causing extremely high CPU and memory usage (extension-host processes)

Try this first:

1. Disable the wask.co extension (and any other third-party AI extensions), restart Cursor, and check Activity Monitor again.
2. If you want to confirm it’s the cause, run cursor --disable-extensions from Terminal and compare memory usage.

Also, there’s a known macOS issue where closing the window with the red button doesn’t always fully shut down child processes. So even after fixing the extension issue, I’d recommend using Cmd+Q to fully quit Cursor between repo sessions instead of just closing windows.

A couple questions:

• What other extensions do you have installed? (in Terminal: cursor --list-extensions)
• Are you using MCP servers? (check for .cursor/mcp.json in your projects)

Running Cursor’s built-in AI together with third-party AI extensions often causes this kind of resource spike. Cursor already includes built-in AI features, so extra layers can conflict and eat memory.

Let me know how it goes after disabling the wask.co extension.strong text

[enesbulut]

@deanrie

cursor --list-extensions

Hey, thank you so much for the detailed response and for taking the time to look into the Activity Monitor screenshot! You completely hit the nail on the head.

I went ahead and did a major cleanup of my extensions based on your advice. I removed about 7-8 unnecessary extensions, but most importantly, I uninstalled the third-party AI extensions that were running alongside Cursor.

I checked my .obsolete extension logs, and I can confirm that the following heavy extensions were active and have now been removed:

• anthropic.claude-code (Claude Code / Cline)

• codium.codium (Codium AI)

• Microsoft IntelliCode

The result: It worked like magic!

1. The RAM consumption immediately dropped back to normal levels (staying in MBs).

2. The memory leak is completely gone.

3. Most surprisingly, clicking the red ‘X’ button to close the window now actually terminates the processes properly without leaving them orphaned in the background!

To answer your other question: No, I am not currently using any custom MCP servers (.cursor/mcp.json does not exist in my projects).

It seems running multiple AI extensions (especially Claude Code and Codium) on top of Cursor’s built-in AI creates a massive conflict in the extension-host process, preventing it from receiving the shutdown signal when the macOS window is closed.

I’ll also make it a habit to use Cmd + Q for fully quitting Cursor between sessions, just to be safe.

Thanks again for saving me from that 28GB Swap nightmare! I hope this thread helps anyone else experiencing the same memory leak due to third-party AI extensions.

[deanrie]

Great, I’m glad we figured it out. Third-party AI extensions on top of Cursor’s built-in AI are one of the most common causes of these memory leaks.

It’s also good that MCP servers aren’t involved, so your current setup should be stable.

If you notice memory going up again, try cursor --disable-extensions as a quick check to see if extensions are the cause, and use Cmd+Q instead of the button to fully quit all processes.