Severe memory leak in Composer 2 exhausts 32GB RAM and causes hard system crash

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor appears to have a severe memory leak when using Composer 2. While simply migrating a landing page from one project to another, memory usage spiked uncontrollably, completely exhausting my 32GB of RAM. The Linux Kernel’s OOM (Out of Memory) killer intervened to terminate the Cursor process, but shortly after the OOM notification, the entire operating system locked up, forcing me to perform a hard reboot via the physical power button.

Steps to Reproduce

1- Open Cursor IDE on Linux.

2- Open Composer 2 and start migrating a landing page from one project to another.

3- Memory consumption grows rapidly and silently until all 32GB of RAM are exhausted.

4- The Linux Kernel throws a “Memory Shortage Avoided” notification and terminates Cursor.

5- The system subsequently freezes completely, requiring a forced manual reboot.

Expected Behavior

Composer 2 should manage memory efficiently and not leak or exhaust 32GB of RAM during a standard migration task. It definitely should not trigger the Linux OOM killer or cause a hard system crash.

Screenshots / Screen Recordings

cursor-error-2.jpg
cursor-error-2.jpg1600×900 107 KB

Operating System

Linux

Version Information

Version: 3.2.16
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
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: Linux x64 6.19.14-200.fc43.x86_64

Additional Information

I have 32GB of RAM, which makes this memory exhaustion particularly severe for a standard web development task. The crash was so heavy that the entire OS became unresponsive, meaning standard logs might be truncated. The screenshots provided show the exact kernel notification right before the total lockup.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report and the screenshot of the kernel notification. I can see what happened.

This is a known class of OOM bugs in Composer. Memory builds up in the renderer process from things like state, checkpoint blobs, tool payloads, and inline diff arrays. On Windows, Electron hits about 4 GB and crashes earlier. On Linux there is no artificial cap, so the process can eat all RAM until the OOM killer steps in. A full OS freeze after the kill is kernel behavior during swap thrashing. This issue is being tracked, but I can’t share an exact fix date.

While the team is working on it, these steps can help reduce the risk:

  • Chat rotation: don’t keep one Composer session running for too long. Start a new agent for each new task. The more history and the more tool calls, the faster memory grows.
  • Delete old agents, don’t archive them. Archived ones can still take part in hydration.
  • Monitoring: Ctrl+Shift+P then Developer: Open Process Explorer. Watch the renderer process. If you see it growing toward 8 to 10 GB or more, restart Cursor before it hits OOM to avoid a system freeze.
  • For large file migrations, split work into smaller iterations. Do one file at a time and avoid long tool call chains in a single session.

If there are updates on the fix, I’ll post them here. Let me know if these workarounds help and if the situation stays stable without full system hangs.

7

Hey Dean, I really appreciate the technical breakdown. Good to know it’s a tracked issue! I’ll start splitting my tasks into smaller iterations, deleting older agents, and monitoring the memory as you suggested to avoid hitting the OOM killer again. Thanks for the help!