Cursor crashes repeatedly with out-of-memory (OOM) errors after the latest update, especially during large prompts or long-running plans

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Since the latest update, Cursor crashes frequently and reproducibly with an out-of-memory (OOM) error.
The application terminates unexpectedly during normal usage, making productive work nearly impossible.

The crashes happen especially when:

processing large prompts, or

executing a plan / task that runs for a longer time (extended agent execution).

This behavior started after the recent update. Before that, Cursor was usable on the same system with the same setup.

Steps to Reproduce

Start Cursor IDE.

Open any project or workspace.

Open a chat or agent.

Submit a large prompt or start a long-running plan.

Wait while the agent is processing.

Result:
Cursor crashes with an OOM error and the window closes unexpectedly.

Expected Behavior

Cursor should be able to handle large prompts and longer-running agent tasks without crashing.

Memory usage should remain stable, or at least not lead to an out-of-memory termination.

The application should remain responsive and stable during extended processing.

ā€œWindow terminated unexpectedly (reason: ā€˜oomā€™, code: ā€˜-536870904ā€™)

Operating System

Windows 10/11

Version Information

IDE:

Version: 2.4.27 (user setup)

VSCode Version: 1.105.1

Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690

Date: 2026-01-31T21:24:58.143Z

Build Type: Stable

Release Track: Default

Electron: 39.2.7

Chromium: 142.0.7444.235

Node.js: 22.21.1

V8: 14.2.231.21-electron.0

For AI issues: which model did you use?

gpt-5.2

For AI issues: add Request ID with privacy disabled

f9a7046a-279b-47e5-ab48-6e8dc12daba1

Additional Information

This issue started only after the last two updates.

The same system and configuration worked before.

The crashes appear to be load-related and strongly suggest a memory leak or memory management regression.

Extensions are minimal and unchanged.

The issue is reproducible multiple times per day.

Does this stop you from using Cursor

Yes - Cursor is unusable

2 Likes
Cursor IDE crashes with code 5
Critical OOM Crash Issue on Windows ā€“ Cursor IDE Keeps Closing
Cursor crashes with "reason: 'oom'" when using Composer on Windows 11 RTX system
Constent chashes when using claude as agent
3

Hey, thanks for the report. This is a known issue on Windows. The renderer process in Cursor hits the ~4 GB memory limit (an Electron limit on Windows) and crashes with an OOM error.

On version 2.4.27 there are two possible causes:

  1. Check for an OTEL memory leak:
  • Open the Command Palette Ctrl+Shift+P > Developer: Toggle Developer Tools > Console
  • Look for lines like [otel.error] or OTLPExporterError
  • If you see them, it is a memory leak present in versions 2.3.35+
  1. Workarounds:

If you see OTEL errors:

  • Downgrade to 2.3.34: Download Ā· Cursor
  • After installing: Settings > Application > Update > Mode: ā€œnoneā€ (turn off auto-updates)

If you do NOT see OTEL errors:

  • Rotate chats: start a new chat when the current one gets large (especially with agent workflows)
  • Monitor memory: Ctrl+Shift+P > Developer: Open Process Explorer, watch the renderer process
  • Check extensions: try cursor --disable-extensions from the command line

Related threads:

I know this is frustrating, especially when working in plan mode. Let me know what you see in the console and whether the workarounds help.

4

Hi,

thanks for the detailed explanation. That clarifies the root cause, and it matches what Iā€™m seeing.

However, there is a concrete problem with the proposed workaround.

You suggested downgrading to version 2.3.34, but it is not possible to download this version from the website you referenced. The download page only offers version 2.3.35, not 2.3.34. There is no visible option to select 2.3.34 specifically.

Please provide a direct download link to Cursor 2.3.34 for Windows.

Once I have that version, I will install it, disable auto-updates completely, and stay on that version. At this point, I do not want new features. Every update has repeatedly broken my development workflow. What I need is one stable version, even if it is older.

Right now, every Cursor update feels like a risk. I need a setup that simply works and does not crash under normal, heavy usage. Stability is far more important to me than new functionality.

Please send me the direct link to 2.3.34 so I can proceed.

Thanks.

1 Like
6

Hi,

at the moment it is absolutely impossible to work. Cursor is crashing repeatedly, and nothing is functioning reliably.

Please send me the direct download link to the older, stable version immediately. I need the working version now, not as a suggestion or workaround.

I am not able to continue testing, rotating chats, or debugging while the application is unusable. The only viable path forward right now is to downgrade to a stable version and disable updates entirely.

Once again, please provide the direct download link to the older working version (2.3.34) as soon as possible.

This is blocking all productive work.

Thanks.

7

You can download this version here.

Version 2.3.34 is the last stable release before the OTEL memory leak (which started in 2.3.35+), so it should run without crashes.

Let me know if the issue is still there after you install it. Based on other users with the same error code, this version is stable.

9

Thanks for providing the link.

I will install version 2.3.34 now and test it.

If this version runs without connection dropouts and without crashes, I will stay on this version permanently and keep auto-updates disabled. I cannot afford the risk of updates breaking my development environment when Iā€™m working on client projects.

Frequent updates that introduce instability are not something I can work with. What I need is a reliable and predictable setup, even if it means staying on an older version.

Iā€™ll let you know how it behaves after testing.

Thanks again.

1 Like
10

Hi Dean,

thanks for your help and the suggestion to downgrade.

I want to give you an update:
Even with version 2.3.34, I experienced another crash today. It happened after a longer runtime, specifically while executing a plan / longer agent workflow. So it did last longer than with newer versions, but the issue still occurred eventually.

This confirms that while 2.3.34 is more stable, it is unfortunately not fully reliable for longer development sessions.

I would really appreciate it if you could let me know:

  • whether this issue is actively being worked on,

  • and when a proper fix is expected.

It would also help a lot if users could be notified once a thoroughly tested version is available, so we can update without the fear of crashes or connection issues. At the moment, every update feels risky, and thatā€™s not something I can afford when working on client projects.

Iā€™m not looking for new features. Iā€™m looking for one version that is stable under load and long-running workflows.

Thanks for your support, and Iā€™d appreciate any guidance on how to proceed safely.

Best regards
Daniel

11

I see that 2.3.34 lasted longer, but it still crashed. Thatā€™s expected. 2.3.34 doesnā€™t have the OTEL memory leak, but the core issue with Electronā€™s 4 GB limit on Windows is still there.

For long agent sessions, the best workaround right now is:

  • Split big plans into smaller parts. Instead of one long task, do a few shorter ones.
  • Rotate chats from time to time. Close the current chat and start a new one, especially before big tasks.
  • Watch memory via Ctrl+Shift+P > Developer: Open Process Explorer. If the renderer is getting close to 3.5 GB, itā€™s time to start a new chat.

Iā€™ll update the thread when thereā€™s progress. If you notice a pattern for when the crash happens, like chat size or how many steps are in the plan, please share it. It would help a lot.

12

Thanks for the explanation. I understand the workaround, but Iā€™d like to explain my concern and assumption more clearly.

Normally, I prefer to work within one single chat, because I rely heavily on the chat history and prior context. My assumption was that when I start a new chat session, the model has to re-analyze and re-understand a lot more context to get back ā€œinto the projectā€, which feels less efficient and more error-prone.

From a workflow perspective, staying in one chat feels more natural, because:

decisions, assumptions, and constraints are already present

I donā€™t have to restate everything again

the model can reference earlier reasoning

Thatā€™s why rotating chats is counter-intuitive for me, even though I understand it helps with memory usage.

So my question is:

How does Cursor currently handle context across chats for the same project?

Does a new chat actually start completely from scratch, or is there any internal mechanism that helps the model retain project understanding beyond the current chat?

I think it would be a very good option if Cursor could actively help the AI remember prior project context, for example via summaries or a project-level memory. Right now, it feels like I have to choose between:

stability (short chats), or

productivity and continuity (long chats, but crashes)

Any clarification on how this is currently handled in Cursor would be very helpful.

Thanks for the insight.

13

One more question related to this.

In other development environments, itā€™s sometimes possible to explicitly allocate more memory to the application so it doesnā€™t crash under heavy workloads.

Is there any way to assign more memory to Cursor (for example by increasing the memory limit for the renderer or Electron process), so that it can handle larger prompts and longer agent sessions without hitting the OOM limit?

If this is not possible, could you clarify whether this is a hard Electron/Windows limitation, or something Cursor might be able to address in the future?

14

What is the long-term plan for fixing this so that Cursor can use more than 4GB of memory? Itā€™s a severe limitation right now, and memory usage will only increase. Should I hold out hope, or move to a different dev env now?

15

First time iā€™m experiencing these problems too. Frustrating. I want to utilize my 128GB of RAM please, lol.

16

Hey @Danielsan,

Replying to your questions:

Context across chats:

When you start a new chat, the AI doesnā€™t have direct access to your previous chat history. It only works with what you add to the context, like open files, @mentions, .cursorrules, and so on.

A workaround is to use .cursorrules so the AI can keep key project decisions and constraints. You can also manually copy important takeaways from an old chat into a new one, or reference them via @Chat.

Yeah, itā€™s less convenient than keeping everything in one chat, but for now itā€™s the only way around the Windows OOM limit.

Increasing the memory limit:

No, you canā€™t. Itā€™s a hard Electron limit on Windows. The renderer process canā€™t use more than about 4 GB. This isnā€™t a Cursor setting, itā€™s a limitation of the Electron and Chromium architecture with a 32-bit sandboxed process on Windows.

So even if you have 128 GB of RAM (like @Visionary), Cursor will still hit the ~4 GB limit for the renderer process.

Long-term plan:

The team is aware of the issue (itā€™s logged), but I canā€™t promise when or if itā€™ll be fixed. Itā€™s not a simple change. It would require architecture changes, like offloading some work from the renderer into separate processes.

For now, the only option is the workarounds above. Rotate chats, especially before big agent workflows.

17

One follow-up question to set expectations:

Is there any realistic outlook that the current or upcoming versions will at least be as stable as 2.3.35, or is that essentially not expected given the current Electron/Windows limitations?

Iā€™m trying to understand whether it makes sense to wait for a fix, or whether staying on an older version (or moving away entirely) is the only realistic option for stable, long-running work.

An honest assessment would really help with planning next steps.

19

Hmm.. Iā€™ve been a long time user but never had to deal with this issue. It has happened 7 times today and even lost a file in the process. Luckily the checkpoint worked, but it had to do the work again, losing many credits in the process. (I mostly work with Opus 4.5) Perhaps introduce a setting which simplifies things, lowering ram usage, since this never happened before but nothing changed in the way I use Cursor. It has become overkill compared to older versions.

1 Like
20

This has made Cursor unusable.

I have been working for days on the same chat with Opus 4.5 with frequent summarizations. Opening new chats all the time kills the experience.

1 Like
21

I have the similar problem on MacOS Cursor 2.4.28
It crashes consistently, and it makes work imposible!

22

Thatā€™s really discouraging to hear.

I was honestly hoping that moving to macOS might be a viable way to work more reliably, but if the same crashes are now happening there as well, that hope is pretty much gone.

If the issue affects both Windows and macOS, it strongly suggests a broader architectural problem rather than a platform-specific one. That makes it even harder to justify relying on Cursor for serious development work right now.

Thanks for sharing your experience.

23

I am similarly Suffering through this bug now, which really truly does render cursor almost unā€“usable in most cases because itā€™s an unrealistic request of users to say that suddenly after using the tool so well for months that we have to start breaking up our workflow into multiple chats, but at the same time you remove the ability for us to actually use previous chats as context without exporting them. I have to believe this should be priority number one for the team because it literally does disrupt most every use of the product compared to other comparable desktop applications.

Please understand Iā€™m a huge fan and proponent of cursor to my audience and for my own use, but this just seems like it should be an imperative to fix immediately.

Perhaps solution is an auto recover window option which understands when the window terminated unexpectedly OOM error comes up and just automatically recovers from it.

1 Like
24

This is now a constant blocker. The downgrade didnā€™t work for me either.

1 Like