Severe memory leak in Cursor Agent/codebase search on Windows 11 since versions after 3.18

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Severe memory leak / high RAM usage in Cursor on Windows 11

Since the Cursor 3.18 release and subsequent versions, I have been experiencing a severe memory usage issue on Windows 11.

The problem mainly occurs when the Agent is searching/exploring the codebase. Cursor’s memory usage continuously increases during the Agent’s search process. I am also experiencing the same issue when asking Cursor to generate a Git commit message.

As shown in the attached screenshot, Cursor is using an extremely large amount of RAM, with multiple Cursor processes running simultaneously. In my case, memory usage keeps increasing until the system becomes extremely slow or the Cursor IDE eventually hangs/crashes.

This issue has been happening consistently for about the past week, specifically with Cursor versions after 3.18. Because of this, I am currently unable to use the Agent reliably for normal development work.

Steps where I can reproduce the issue:

  1. Open a project in Cursor on Windows 11.
  2. Start the Agent and ask it to search/explore multiple files in the codebase.
  3. Keep using the Agent for a while.
  4. Cursor’s RAM usage continuously increases.
  5. The same behavior can occur when asking Cursor to generate a Git commit message.
  6. Eventually, Cursor becomes unresponsive, hangs, or the system runs out of available memory.

Please investigate this as a possible memory leak or excessive process/memory consumption issue in the Agent/codebase search functionality.

This is currently a major blocker for me because I cannot use Cursor Agent normally without worrying about the IDE consuming all available RAM.

Steps to Reproduce

install this version and use it try to git commit generate via sidebar it will eat ram and then agent starting eating ram.

Operating System

Windows 10/11

Version Information

Version: 3.20.10 (user setup)
VS Code Extension API: 1.128.0
Commit: d6f462cdd0a6a6d1cff570daf980e671d0a63de0
Date: 2026-09-10T21:04:54.045Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

composer 2.5

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the detailed report, and I’m sorry this is getting in the way. I can see the screenshot with lots of Cursor processes in Task Manager.

One important thing is that Windows Task Manager groups all helper processes under Cursor, including ones started by third-party extensions and language servers. So the RAM growth you’re seeing might be coming from an extension or a language server, not the Agent itself. Let’s confirm that with a couple quick steps.

Next time memory starts growing:

  1. Command Palette Ctrl+Shift+P → Developer: Open Process Explorer, click the Memory column to sort, then take a screenshot of the Cursor process tree.
  2. Then Developer: Show Running Extensions, take a screenshot of the list.
  3. Then run Capture and Send Debugging Data, keep the default checkboxes, press Enter. If Privacy Mode is on, the zip will be saved locally instead of uploaded. Please attach it here, or send it privately if that’s easier.

Also, a quick isolation test from a clean start:

  1. Fully close Cursor. Check Task Manager to make sure no Cursor processes are left, then end them if needed.
  2. Open Cursor, Extensions view Ctrl+Shift+X, top ... menu → Disable All Installed Extensions, then restart when prompted.
  3. Use the Agent for code search and research for a while, and generate a commit message from the Source Control sidebar like you normally do.
  4. Does memory still grow with extensions disabled? Let me know either way, and please share the two screenshots above.

One more thing. The email on your forum account doesn’t look like the one you’re signed into Cursor with. If you can, share the signed-in email, or a Request ID from a slow Agent turn. You can get it from the ... menu at the bottom of the response → Copy Request ID. That’ll help us look at the right data.

Let me know how it goes.