It has become an impediment to my work. I have tried a thousand options, but in the end, starting a new chat is inevitable. It is the only solution I have found.
1 Like
Iāve been having the same issue. I found that running all processes (any Node processes, etc.) outside of Cursorās terminal and using command prompt or powershell directly helps reduce the frequency of crashes significantly.
Itās worth noting that every single OOM failure results in an expensive loss of progress, especially when using a costly agent. Multi-agent work is completely out of the question.
1 Like
I want to ask this very explicitly again, because itās important for planning:
Is it realistically possible that newer versions of Cursor will reach at least the same level of stability as version 2.3.34, or should we assume that this level of stability is no longer achievable with the current architecture?
I already asked a similar question earlier, but Iād really appreciate a direct and honest answer this time.
This is not about new features. Itās purely about baseline stability for longer sessions and real development work.
Knowing whether ā2.3.34-level stabilityā is a realistic goal for future releases would help a lot in deciding whether to wait, downgrade permanently, or move away entirely.
Thanks for the clarification.
1 Like
I am on a Macbook Pro running os 15.7 with 24gb mem and the last two Cursor updates have left me with many crashes! It is very difficult to work. Please advise best course of action to resolve this asap
1 Like
This is happening on MacOS as well!
Iāve even shut down Cursor and it leaves a slew of zombie processes running eating up hundreds of MBs of memory!
What are yāall doing?
Hi @deanrie!
Iād like to ask again, very explicitly, about the plan and current progress, because my current observations donāt match the suggested workaround.
On version 2.3.34, Iām seeing the following behavior:
-
Even after starting a new agent / new chat, the renderer memory is already well above 3 GB.
-
Over time, memory keeps increasing to 4.5ā5.5 GB.
-
At that point, Cursor often does not crash, but it becomes effectively non-functional:
-
When I try to create a plan or start a longer agent workflow, nothing happens.
-
The agent does not proceed, so rotating chats does not actually solve the problem in practice.
-
This means that starting a new chat or agent does not reliably reset memory pressure, and the recommended workaround stops being effective.
So Iād like to ask very concretely:
-
Is there any actual progress in newer versions regarding this behavior?
-
Do newer versions handle memory differently or more reliably under long-running workflows?
-
Is the team actively working on reducing renderer memory growth across chats and agents, or is this currently considered unavoidable?
-
Is there any realistic expectation that this situation will improve in the near term, or should users assume this limitation will persist?
Right now, even on 2.3.34, the tool becomes unusable after some time, even when following the recommended workflow. That makes it very hard to plan real development work.
Any concrete update on the current state of implementation, not just the long-term idea, would be greatly appreciated.
Thanks for the clarification.
2 Likes
2ms, activate resolved: 10429ms)
2026-02-16 13:23:39.983 [info] [Extension Host] Eager extensions activated
2026-02-16 13:23:43.678 [error] [Window] [Extension Host] [otel.error] {āstackā:āOTLPExporterError: Bad Request\n\tat IncomingMessage. (c:\Users\jonog\AppData\Local\Programs\cursor\resources\app\node_modules\@opentelemetry\otlp-exporter-base\build\src\transport\http-transport-utils.js:52:31)\n\tat IncomingMessage.emit (node:events:531:35)\n\tat endReadableNT (node:internal/streams/readable:1698:12)\n\tat process.processTicksAndRejections (node:internal/process/task_queues:90:21)ā,āmessageā:āBad Requestā,ācodeā:ā400ā,ānameā:āOTLPExporterErrorā,ādataā:ā{āerrorā:āTrace spans collection is disabled for NO_STORAGE privacy modeā}ā}
This seems to be the log where is crashes
Over the past week, I feel like Iāve spent more time working around these crashes than I have actually getting anything done in Cursor. It is nearly unusable for me at this point. Small project, one chat (starting new ones), no extensions, and it still crashes many times per hour.
1 Like
This is what I get too.
I find it interesting the error message suggests some data collection is attempted even when we have privacy legacy turned on, what is this?
1 Like
I also want to know what is being done to fix this, as its currently a really bad experience.
I have ended up losing hours of work due to this, it has caused rollbacks of random files forcing me to go back to earlier commits.
It is a serious issue.
2 Likes
Now that Iāve fully uninstalled and then installed 2.3.34, I havenāt had a crash yet. Idle memory usage is much lower, and the maximum it uses during build is roughly half the idle usage of more recent versions. So the post-2.3.34 regression just seems massive. FYI @deanrie
1 Like
I was getting these crashes too - I have found a really good way that has worked very well - i ask it to provide a handoff file as well as a system prompt that I can provide to a new chat instance. what I have also found is I have just said āplease find our cursor chat history and take what context from it that you needā - it has struggled a few times but it has found the chat logs and my previous plans and was able to get back up and running almost instantly. just start it in plan mode so that it can do a deep dive on your files, and youāre good to keep going.
Please. If possible, this issue should be treated as a priority. It involves a substantial degradation in the usability of Cursorā¦ and it is really frustrating.
3 Likes
Is the cursor CLI also affected by this error? I donāt mind using cli for agentic development. Maybe it will be more efficient at editing the files.
Latest version seems to have fixed this for me, so Iām no longer bound to using 2.3.34 as a workaround
Hey, this will be great, are you sure it is fixed? How long did you tested this? It feels like version 2.3.34 is much better the last time, it takes max. between 1500 - 2500 MB RAM.
Can you officially confirm the bug fix? Have you already conducted any tests?
Version: 2.5.20 (system setup)
VSCode Version: 1.105.1
Commit: 511523af765daeb1fa69500ab0df5b6524424610
Date: 2026-02-19T20:41:31.942Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045
Having this issue when simply opening a 2nd repo with cursor (2 cursor instances). It will rack up memory till it dies with an OOM error and crash.There is ~24 GB of memory headroom left on the system when this occurs.
1 Like