Fix the Memory leaks plz

Support Bug Reports
1

Where does the bug appear (feature/product)?​

  • Cursor IDE

Describe the Bug A severe memory leak occurs immediately upon launching Cursor, causing it to consume over 40GB of memory.

Steps to Reproduce

  1. Open Cursor.

Expected Behavior Cursor should launch and operate normally with reasonable memory usage.

Screenshots / Screen Recordings

Operating System

Version Information

Version: 3.9.16

VSCode Version: 1.105.1

Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80

Date: 2026-06-27T06:41:01.941Z

Layout: editor

Build Type: Stable

Release Track: Default

Electron: 40.10.3

Chromium: 144.0.7559.236

Node.js: 24.15.0

V8: 14.4.258.32-electron.0

xterm.js: 6.1.0-beta.256

OS: Darwin arm64 25.1.0

For AI issues: which model did you use?​

  • N/A (This is a performance issue, not an AI model issue)

For AI issues: add Request ID with privacy disabled

  • N/A

Additional Information

  • The issue not only renders Cursor completely unusable but also severely impacts overall system performance, requiring the termination of the Cursor process to restore normal operation.

Does this stop you from using Cursor?​

  • Yes - Cursor is unusable
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

has edited

8

Hi there! Thanks for the clear recording, that Force Quit view showing Cursor climb past 42 GB is exactly what we needed.

This is a known issue we’re actively working on. On macOS it’s usually driven by chat/agent history piling up in Cursor’s internal storage (there’s no automatic cleanup yet), which gets loaded on launch and grows with long agent sessions. Here’s how to get unblocked:

1. Clean up the internal store (biggest lever). In the Command Palette (Cmd+Shift+P), run Developer: Delete Old Chats… (pick an age cutoff), then GC Agent KV Blobs (this compacts the store and reclaims space; on a large store it can lock the window for a minute or two).

2. Check the store’s size, then reset it if needed. In Terminal:

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

If that’s several GB or more, it’s very likely the cause. If step 1 doesn’t shrink it enough, do a full reset: quit Cursor with Cmd+Q first, then:

cd ~/Library/Application\ Support/Cursor/User/globalStorage
mv state.vscdb state.vscdb.bak

Reopen Cursor and it rebuilds a fresh, small file. Heads-up: this clears your chat/agent history (settings, keybindings, extensions, and projects are kept). Keep the .bak until things look stable, then delete it.

3. Going forward: start a new chat (Cmd+N) for new tasks instead of one very long conversation, and quit with Cmd+Q (not just closing the window) so background processes get cleaned up.

If it’s still climbing after the cleanup, two things will pin down the cause for us:

  1. During the spike, open Developer: Open Process Explorer (Cmd+Shift+P), click History (Mem), and send a screenshot so we can see which process is actually growing.
  2. Does it also happen on a brand-new empty folder, or only on this project?

You may also find this thread useful, where we’re tracking the same issue and posting updates: Cursor on macOS consuming massive memory (40GB+)