Cursor consuming ~22 GB RAM across dozens of helper processes — IDE becomes extremely slow

[erraoudy (Said)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor is using a massive amount of memory on my machine, even though I have 64 GB of RAM available. The editor is running extremely slowly — lag on typing, slow file switching, slow AI responses, and the whole system becomes sluggish. Looking at Activity Monitor, Cursor alone appears to be eating well over 20 GB across its helper processes, which seems unreasonable.

Environment

• Cursor Version: 3.1.17
• VSCode Version: 1.105.1
• Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
• Date: 2026-04-19T19:33:58.189Z
• Electron: 39.8.1
• Chromium: 142.0.7444.265
• Node.js: 22.22.1
• V8: 14.2.231.22-electron.0
• OS: Darwin arm64 25.4.0 (macOS, Apple Silicon)
• System RAM: 64 GB

What I’m seeing in Activity Monitor

Top Cursor-related processes:

• Cursor Helper (Renderer) — 5.14 GB
• Cursor Helper (GPU) — 3.51 GB
• Cursor Helper (Renderer) — 2.97 GB
• Cursor Helper (Plugin): extension-host (retrieval) chargepanda — 932 MB
• Cursor Helper (Plugin): extension-host (agent-exec) chargepanda — 699 MB
• tsserver[5.9.2]: semantic — 813 MB
• tsserver[5.9.2]: semantic — 594 MB
• Cursor Helper (Plugin): extension-host (user) chargepanda — 566 MB
• Cursor Helper (Plugin): extension-host (user) thinkcapital-nextjs — 526 MB
• Cursor Helper (Plugin): extension-host (user) wp-aicache — 440 MB
• Cursor Helper (Plugin): extension-host (user) stories-app — 417 MB
• ~15 additional Cursor Helper (Renderer) processes — 450 MB to 665 MB each

Total Cursor footprint: roughly 21–22 GB.

I have 4 workspaces open (chargepanda, thinkcapital-nextjs, wp-aicache, stories-app), but each Renderer process averaging 500 MB–5 GB and the number of helper processes still seems excessive.

Questions

1. Why is a single Renderer process consuming over 5 GB of RAM? Is there a memory leak?
2. Why are there so many duplicate Cursor Helper (Renderer) processes in the 500 MB–700 MB range?
3. Is the extension-host spawning a separate plugin process per workspace expected behavior? Can this be consolidated?
4. Why is Cursor Helper (GPU) using 3.51 GB?
5. Are there any settings, flags, or workarounds to reduce this footprint until a fix is released?

Impact

The IDE is nearly unusable during long coding sessions. I have to restart Cursor multiple times per day to reclaim memory, which breaks my workflow — losing AI context, re-indexing projects, reopening files. On a 64 GB machine this should not be happening.

Screenshot of Activity Monitor attached for reference.

Please investigate and advise.

Thanks.

Steps to Reproduce

Steps to Reproduce

1. Fully quit Cursor (Cmd+Q) and relaunch. At this point everything runs fast and memory usage is normal.
2. Open a workspace with a medium-to-large codebase (in my case a Next.js project + a WordPress plugin project).
3. Start a long AI chat session using Agent mode, where the agent spawns multiple subagents and edits many files across the workspace over time.
4. Keep the conversation going for an extended period (typically 30–60+ minutes, with dozens of tool calls, file reads, and file edits).
5. Observe in Activity Monitor that Cursor Helper (Renderer) and Cursor Helper (GPU) processes gradually grow from normal sizes (~300–800 MB) into multi-GB territory (5 GB+ for a single Renderer, 3.5 GB for GPU).
6. The editor becomes progressively slower — typing lag, delayed file switching, slow AI responses, and eventually the whole system becomes sluggish.
7. Quitting and relaunching Cursor temporarily fixes it, but the issue returns after another long agent session.

Expected behavior

Memory should be released after agent tasks complete, file edits finish, and conversation context is no longer actively used. Long chat sessions should not cause unbounded memory growth.

Actual behavior

Memory keeps growing over the lifetime of a chat session and is never reclaimed until Cursor is fully restarted. This strongly suggests a memory leak in either the Renderer process handling the chat UI, the agent/subagent execution pipeline, or the file edit/diff tracking system.

Additional notes

• The issue is reproducible — it happens every time I run a long agent session with many subagents and file edits.
• It does not happen (or happens much more slowly) during normal editing without the AI chat.
• Restart is the only workaround I’ve found, which means losing all AI context and re-indexing the project.

Expected Behavior

Expected Behavior

Cursor should manage memory efficiently during long AI chat sessions, even when the agent uses multiple subagents and edits many files. Specifically:

• Cursor Helper (Renderer) processes should stay within a reasonable range (roughly 300–800 MB per process) and not grow into multi-GB territory over the lifetime of a single chat.
• Cursor Helper (GPU) should not exceed ~500 MB under normal usage.
• Memory used by completed agent tasks, finished subagent runs, and old conversation context should be released (garbage collected) once it is no longer needed.
• Opening multiple workspaces should not multiply memory usage linearly to the point where a 64 GB machine becomes sluggish.
• Users should not need to restart Cursor multiple times per day just to reclaim RAM and keep the IDE responsive.

In short: long agent sessions with many file edits should be a supported, stable workflow — not a trigger for unbounded memory growth.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report. The Activity Monitor stats and the repro steps really help.

On the issue itself, this is a known class of problems where the renderer memory grows during long agent sessions, especially when lots of tool calls, file reads, and diff tracking build up in the composer state. We’re tracking it internally, but I can’t share an ETA for a fix yet.

Quick answers to your questions:

1. Renderer 5+ GB: yep, that’s a leak. Composer state like file context, tool call results, and diff tracking can pile up and doesn’t always get freed during long sessions.
2. Lots of renderer processes at 500 to 700 MB: each workspace window gets its own renderer, plus extra ones for some surfaces. With 4 workspaces open, it adds up fast.
3. Extension host per workspace: expected behavior. User, retrieval, and agent exec get spawned per workspace. We can’t consolidate this, it’s a VS Code architecture choice.
4. GPU 3.5 GB: also not normal. It’s likely tied to renderer growth via shared textures and layers. It usually drops if you close heavy tabs.

Workarounds for now:

• Keep only 1 to 2 workspaces open at a time and close the rest. On your setup, this should help the most.
• Restart Cursor after especially long agent sessions like 30 to 60+ minutes with lots of edits, before things start lagging.
• Use Cmd+Shift+P then run Developer: Open Process Explorer. You can see which process is growing in real time and kill it without a full restart.
• If you use extensions, check Extension Monitor at Settings > Application > Experimental > Extension Monitor Enabled. Sometimes part of the growth comes from extensions.

If you can, please send the Request ID from one of the heavy agent sessions where the growth was most noticeable. You can grab it from the chat menu in the top right corner > Copy Request ID. That’ll help us match your case to internal traces. We’ll reply in the thread when we have an update on the fix.

[Mads_Gerber]

I experience the exact same thing. Never experienced it before yesterday. But now Cursor is basically unusable for me.

[erraoudy (Said)]

Thanks a lot for the detailed reply, really appreciate it. Good to know the renderer leak is already tracked internally.

Please find attached a few Request IDs from recent heavy agent sessions where the memory growth was most noticeable:

c13c2ac7-2ad5-4403-aeee-488aa56aaf78
587e2106-5091-4090-8492-17b32e6f0f6f
d3019362-472e-41b5-9441-f5346ef78d5f

Looking forward to a fix, this issue makes working on large projects really hard, especially during long agent sessions where I rely on the composer state staying healthy.

Thanks again!

[deanrie]

@erraoudy thanks for the Request ID, I’ve attached it to our internal tracking. If there’s an update on the fix, I’ll reply here in the thread. For now, the most practical thing is that the workarounds from the previous message 1 to 2 workspaces at a time plus restarting Cursor after long agent sessions have the biggest impact for your usage.

@Mads_Gerber sounds like the same class of issue. If you can, please share:

• Cursor version Cursor Settings > About and your OS
• a Request ID from a heavy agent session chat menu in the top right > Copy Request ID
• a screenshot of Activity Monitor or Task Manager showing the top Cursor processes by memory

This will help us match your case to scenarios we’re already tracking. The issue is on our side, and I can’t give an ETA for a fix yet.

[kakaRicky]

I also encountered the same issue, and the memory usage was quite close — 22.33GB. Could this number be a coincidence? However, I didn’t save the monitor information for each process. Thinking back to what I did before the problem occurred, I asked the Agent to globally search for all logical locations where a certain interface’s fields might be constructed within a project. This task theoretically required the Agent to match and load a large number of files. But this time, I manually terminated the instruction halfway through, and then immediately asked another question in the same conversation. Shortly after, I received the system’s insufficient memory warning on my Mac.