Cursor crashes with OOM error on Windows even with 32GB RAM

Support Bug Reports
, ,
1

Hi Cursor team,

I’m experiencing repeated crashes with the following error:

“The window terminated unexpectedly (reason: ‘oom’, code: -536870904)”

System details:
• Device: HP Pavilion 15-eg3020na
• OS: Windows 11
• RAM: Recently upgraded from 8GB to 32GB (DDR4 3200, dual channel)
• Storage: NVMe SSD

Behavior:
• Before upgrading RAM, Cursor crashed immediately after prompts.
• After upgrading to 32GB, builds sometimes complete but Cursor still crashes intermittently with the same OOM error.
• Sometimes the build completes and then Cursor crashes afterward.

Things I have already tried:
• Increased virtual memory (paging file ~19GB)
• Restarted system
• Running latest Cursor version
• Project hosted on GitHub

Question:
Is this a known memory issue with Cursor/Electron on Windows, or is there a recommended configuration to prevent OOM crashes for larger codebases?

Any guidance would be appreciated. I can provide logs if needed.

Thanks.

4

Hi there,

Thanks for the detailed report. We’re tracking this issue, and the engineering team is actively working on it.

What’s happening: this OOM isn’t about total system RAM. Cursor runs on Electron/Chromium, which has a per-process memory cap (~4GB), so even with 32GB RAM the renderer process can still hit that ceiling.

A common trigger (especially with heavy Composer/Agent usage) is accumulated inline diffs. If changes aren’t explicitly accepted or rejected, they can pile up across sessions. On restart, restoring them all at once can push the process over the limit.

Workarounds that usually help:

  • Accept/reject pending inline diffs before quitting (most impactful).

  • Disable non-essential extensions to reduce overhead (re-enable one by one if needed).

  • If it’s crashing on startup, clear workspace storage (this removes stored diffs/pending changes):

    1. Quit Cursor

    2. Delete %APPDATA%\Cursor\User\workspaceStorage

    3. Relaunch

  • Avoid extremely long Composer sessions without periodically accepting/rejecting changes.

We’re rolling out improvements to the inline diff system to address this at the root. There’s also a longer thread with more discussion and workarounds here.

Best,
Mohit

7

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.

10

Hey @pleerityenterprise and @javiermarcon!

The OOM crash issue has been fixed in a recent Cursor update. Updating to the latest version should resolve this. If you’re still experiencing this on the latest version of Cursor, please raise a new thread and we’ll take a look.