OOM problems persist in Cursor 2.3 despite available memory

OOM problems again!

I don/t understand this. My system has 64GB. Cursor typically uses 4GB. why doesnt it use what’s available? current environment:

Version: 2.3.29 (system setup)
VSCode Version: 1.105.1
Commit: 4ca9b38c6c97d4243bf0c61e51426667cb964bd0
Date: 2026-01-08T00:34:49.798Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200

I estimate around 60%-70% of my token use is rework due to cursor crashing. Cursor needs to make this right by not charging for extra work. If not, you actually have a disincentive to fix the problem.

1 Like

Looking into this. Apologies

We are sorry about this @Work_Dre. Is there any chance you can get us an export of the cursor process history? you can access that by opening the command palette via ctrl-shift-P and running > Developer: Open Process Explorer. there will be a memory history tab, where you can click a save button in the top bar.

This is what i have:

1 Like

If you have privacy mode turned off, another thing to try: from the same command palette, run Developer: Capture and Send Debugging Data.

Developer: Capture and Send Debugging Data command was run. Althought i dont know where the infromation was sent? What else do i need to do?

Still broken. how can you run out of memory with 40G of computer memory unused?

Version: 2.3.34 (system setup)
VSCode Version: 1.105.1
Commit: 643ba67cd252e2888e296dd0cf34a0c5d7625b90
Date: 2026-01-10T21:17:10.428Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200

Developer: Capture and Send Debugging Data command was run. Although I don’t know where the information was sent? What else do I need to do? this needs to stop.

**

What can i do to help you solve this? Now using V 2.3.35

**

1 Like

I will try Windsurf and see how it goes if it’s not fixed asap

1 Like

Very sorry about this. We are continuing to investigate. Does Cursor hard crash as soon as you open it? We suspect there is something that Cursor tries to load that causes the OOM crash. If you are able to open Cursor, can you see how many chats you have in the agent pane, and if they are long? Perhaps you have agent-generated diffs in many files? Are there consistent patterns that cause the crash?

In any case, there is a more aggressive mitigation we can attempt: to clear your Cursor user data directory. This would start you in a fresh state which will likely help. Unfortunately, though, this would prevent you from accessing all your previous chats and settings, and you’d need to re-authenticate into your Cursor account.

If you’d like to give this a shot, I can provide instructions for clearing your Cursor user data directory after backing it up so you don’t lose any of your chat data.

Does Cursor hard crash as soon as you open it? No

If you are able to open Cursor, can you see how many chats you have in the agent pane, and if they are long? I only have one chat open. it is almost always in agent mode

Are there consistent patterns that cause the crash? It only crashes when the agent is taking action. maybe starting a server, editing code, etc.

Clear your Cursor user data directory. If you’d like to give this a shot, I can provide instructions for clearing your Cursor user data directory after backing it up so you don’t lose any of your chat data. As long as i don’t lose the agent chat history and “context”, i’m happy to try this.

This just happened again. The timestamp is GMT-6.

No. I have this same constant problem. And tokens are actually spent on reworking the same thing several times.

The crash occurs after loading, the request for action to the agent has already been like this for 7 iterations!

As there is a newer version of the thread kindly switch to following thread.

Please also update your Cursor to latest version as several causes were fixed already.