Interestingly, this is a clean install of Windows 11. In my Windows 10 environment I wasn’t experiencing this at all.
Since having this issue, I have uninstalled and reinstalled cursor and the afflicting extension. The issue reoccurs.
I may have temporarily fixed the issue though by uninstalling vscode and reinstalling the extension in cursor.
mine comes back after a few seconds. But its annoying as ■■■■ lol.
I’m only seeing this on a python project. I have another project using react-native, and one using vite and i can even run the window at the same time for the other project. The Python project suffers, but the others do not.
Could be a red herring, but I’m thinking it could be in the python interpreter element of Cursor perhaps?
The chat, composer and agent is all effected.
This is SUCH a cool tech I really want to help you guys get to the bottom of this, as I’m using the app almost all day in some format or another.
If you can monitor the memory usage and spot it when its high before the crash, you should be able to check the process explorer to see what is using your RAM within Cursor.
Most of the time, we find extensions to cause this issue, not Cursor itself.
That’s the thing, in process explorer there is nothing visible. In Windows task manager the memory is high, but also not that high for Cursor itself. There must be some hidden process or some conflict. Maybe the antivirus. I don’t know, where it could be visible the exact thing increasing the memory, but certain thing is, I open Cursor, no problem. If I ask in chat the AI to do things, from that moment, there is a timer and in around half hour to an hour the memory will be filled 100%. If I catch it at 99% and close Cursor, in a few minutes I get back slowly to 60%, then if I wait even more it will slowly go down to normal.
What background services do this, no idea, but in the process explorer it is not visible.
What version of Cursor are you on?
Version: 0.45.5
VSCode Version: 1.96.2
Commit: e599ee6d2218c8b6fef45980f8cc964bacc0caa0
Date: 2025-01-28T22:23:41.566Z
Electron: 32.2.6
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19045
Yes, same here.
My cursor is starting a lot of node process recursively until it freezes my laptop. As soon as I close it everything goes back to normal.
MacOS, m3, 36gb ram.
it used to be ok until a few days ago!
I developed Android Studio and VScode applications, maybe even 24 hours, the emulator was running, and while these were happening, I was dealing with chrome 30 tabs open watching videos or researching, but I did not experience even 1 freeze pc lockup.I have been using Cursor for 3 days, I bought the pro version, but within 1 hour the pc locks up and I restart it with the power key of the case. All authorized people in the forum are looking for the problem extensions but it is not relevant, I have 2 plugins, these are 1.Dart 2.Flutter, the problem is not here, the developer team needs to release an optimized performance version instead of looking for the problem elsewhere, I switched to win 10 by formatting win 11 zero due to these freezing problems, I installed from scratch and again the same problem
I managed to find out the problem. Thanks dan for the hint.
It looks like one of the playwright extensions (called Playwright Test for VSCode) i had caused to have infinitely node processed started.
I keep seeing discussions about extensions being the cause, but the exact same extensions cause no issues in VS Code. The ones I use are official, providing syntax highlighting and core functionality for development.
I can’t go back to using VS Code with Copilot because I’m too used to how Cursor works - it’s fantastic. Now, I even have a Rainmeter widget showing my RAM usage. Once it goes over 90%, I close Cursor, take a break, and then come back to continue. It’s almost like having an automatic break timer, which is fine… but not exactly what I signed up for. 
Since Cursor is a fork of VS Code, and these same extensions don’t cause memory issues in VS Code, constantly pointing to them as the culprit doesn’t seem logical. It shifts attention away from the real issue - some kind of runaway process within Cursor’s AI engine that isn’t present in VS Code.
There’s no blame here, but dismissing the problem with “it must be the extensions” isn’t helpful. These are widely used, official extensions that work fine elsewhere.
That said, I’ve gotten used to the forced breaks - after all, working without them isn’t healthy. But the fact remains: there’s a problem, and at some point, it should be addressed for the stability and health of the project.
I also wonder if there’s another factor at play. It’s strange that only some users experience this while many don’t. Could it be an issue with certain antivirus software? Specific hardware configurations? Something else?
after some (finger in the air) exploration (ie unscientific) I have observed the slow down is related to the length of chat potentially. It is definitely related to the length of time the project has been running (maybe code index growth?)
I copied the workspace from one location to root of my drive to see what would happen. All chat history vanishes and the code needs to be reindexed so bare that in mind.
It stopped the memory draw / stuttering.
No idea what the root cause is however, but it maybe enough to get you up and running again (if you have no extensions enabled and still see stuttering/freezing)
Thank you so much for this comment. This is exactly what happened with mine and it appears my chat history was little too long 
. Changing the location where these files were held worked perfectly and get everything up and running for me
I am happy to announce that since a few days I don’t get the memory increase problem anymore. Some of the recent updates fixed this problem.
I never had this issue before but when the new update dropped today I’m not getting it with every request…
Your Cursor processes are consuming a high amount of memory (5GB+) and significant CPU resources (20%+ usage), which is likely causing the freezes and OOM errors. The fact that Cursor is spawning multiple processes (13 instances) suggests a memory leak or inefficient resource management in the app.
Have you tried running Cursor on Mac or Linux to see if the issue is Windows-specific?
