Renderer OOM crash (code -536870904) every ~3 minutes on Windows — 128GB RAM, reproducible

[Silly_Spicee]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment

• Cursor version: 2.5.20 (stable, commit 511523af)
• OS: Windows 11 Pro Build 26200
• CPU: AMD Ryzen Threadripper 3970X (32-core)
• GPU: NVIDIA GeForce RTX 5080
• RAM: 128 GB (76+ GB free at time of crash)
• Page file: 32 GB (increased from 8 GB, did not help)

Problem

Cursor renderer process crashes with OOM every ~3 minutes consistently.
Error: The window terminated unexpectedly (reason: 'oom', code: '-536870904')

The same workflow on Ubuntu (same machine, dual-boot) does NOT produce this error.

Reproduction

1. Open Cursor on any project (even a small 36-file Android/Gradle project)
2. Open Agent chat and send a few messages
3. Wait ~3 minutes
4. Crash: CodeWindow: renderer process gone (reason: oom, code: -536870904)

Happens 100% of the time. Crash loop — reopening leads to another crash in ~3 min.

Diagnostic data

Renderer memory growth (observed live via Get-Process)

The renderer process responsible for the Agent chat window grows rapidly:

• T+0 min: ~600 MB
• T+2 min: ~3000 MB (3 GB)
• T+4 min: ~5100 MB (5.1 GB)
• T+5 min: CRASH (OOM)

Other renderer processes stay stable at 200-600 MB.

main.log (consistent pattern across sessions)

2026-02-21 18:59:40.988 [error] CodeWindow: renderer process gone (reason: oom, code: -536870904)
2026-02-21 19:06:02.421 [error] CodeWindow: renderer process gone (reason: oom, code: -536870904)

Renderer command line (js-flags NOT passed to renderer)

--max-old-space-size=65536 set in argv.json does NOT appear in renderer process
command line. The flag only affects the main process, not the renderer.

Process snapshot at time of investigation

ProcessId WorkingSet_MB Type
71536 5146 renderer ← this one crashes
62916 625 renderer
60664 445 gpu-process
71176 260 main

What I already tried (none helped)

1. ✗ argv.json: "js-flags": "--max-old-space-size=65536" — does not affect renderer
2. ✗ argv.json: "disable-hardware-acceleration": true — crash still happens
3. ✗ --disable-extensions — crash still happens (Agent is built-in)
4. ✗ Cleared CachedData, GPUCache, Cache directories
5. ✗ settings.json: "window.restoreWindows": "none"
6. ✗ Created .cursorignore excluding build dirs (project only has 36 files)
7. ✗ Increased page file from 8 GB to 32 GB
8. ✗ Extended files.watcherExclude

Key observations

• Crash is Windows-specific — same machine on Ubuntu works fine
• Crash happens in renderer process, not main or extension host
• js-flags from argv.json do NOT propagate to renderer processes
• Indexing completes in 3 seconds (36 files) — not the cause
• 128 GB RAM with 76+ GB free — not a system memory issue
• The leaking renderer is always the one running Agent chat
• Multiple windows (3-4) accelerate the issue but single window also crashes

Expected behavior

Renderer process should not grow unbounded. Either implement memory limits for
renderer processes or fix the memory leak in the Agent chat rendering pipeline.

Steps to Reproduce

1. Fresh install Cursor 2.5.20 on Windows 11 (128 GB RAM, RTX 5080)
2. Open any project (even small — 36 files Android/Gradle project)
3. Open Agent chat (Ctrl+L or Cmd+L)
4. Send 3-5 messages in Agent mode
5. Wait ~3 minutes
6. Renderer process grows from 600 MB → 3 GB → 5 GB → crash
7. Dialog appears: “The window terminated unexpectedly (reason: ‘oom’, code: ‘-536870904’)”
8. Click “Reopen” — crash repeats in ~3 minutes again (crash loop)

Note: Does NOT reproduce on Ubuntu (same hardware, dual-boot). Windows-only.

Operating System

Windows 10/11

Version Information

Version: 2.5.20 (user 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.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

[Colin]

Hey there! Thanks for reporting. I private messaged you some instructions for grabbing a performance trace.

[patrickd12345]

same here! Bug report:

Use this report as-is (copy/paste to Cursor forum or support email).

Bug Report Draft

Title

Windows renderer OOM crash loop (reason: ‘oom’, code: ‘-536870904’) during normal agent/terminal workflow

Product / Area

Cursor IDE (Windows desktop)

Summary

Cursor repeatedly crashes with popup:

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

This occurs during normal coding sessions with agent + terminal + browser/debug workflows.

Environment

• OS: Windows_NT x64 10.0.26200

• Repro in recent stable builds (exact build from About Cursor can be pasted here)

• Workspace: medium/large monorepo (web + tests + terminal usage)

• Hardware: (fill in RAM/CPU/GPU)

Crash Signature

• Popup text: window terminated unexpectedly (reason: ‘oom’, code: ‘-536870904’)

• Frequency: multiple times in a session; can recur after reopen

• Sometimes appears after heavy tool output or long-running agent sessions

Repro Steps (high confidence)

1. Open Cursor on a medium/large repo.

2. Run agent tasks that involve:

• terminal commands (type-check/test/dev server),

• browser automation/snapshots/network logs,

• iterative debugging with multiple tool outputs.

1. Continue for ~10–30+ minutes.

2. Cursor crashes with OOM popup.

Expected

No renderer crash; stable long-running sessions.

Actual

Renderer exits with OOM; active workflow interrupted. Reopen may restore state and crash again later.

Observed Correlations

• More likely with high-volume outputs (terminal + browser snapshots/network logs + long chats).

• Reopen with restored editors/session seems to increase recurrence.

Mitigations that help but do not solve

• Reopen with “Don’t restore editors”.

• Smaller sessions/new chat threads.

• Fewer parallel heavy operations.

• Limiting output volume.

Impact

• Blocks ongoing debugging and implementation work.

• Causes repeated context loss and restart overhead.

[Yair_Katznelson]

same here

[Michael_Ferioli]

Same here! I completely rebuilt my entire machine and everything worked fine for about 24 hours and now the problem is back. I am on a Windows 11 machine with 64GB of RAM using WSL with Ubuntu. I’ve been using this configuration for nearly a year with no problems. THIS IS A CURSOR BUG!!! Please resolve it asap!!

[Yair_Katznelson]

happens again and again, many times and I lose requests!

[Rob_devauen]

same issue here.. had no problems the first days. Now its happening all the time, no matter what i try to do.

[Siro_Buehlmann (Siro Bühlmann)]

Same problem here! Since 4 days is my cursor not usable anymore. I have to reopen all 2-3 minutes, even though I have enough RAM available. Always the same error message. Even after a re-install: 24h later, I got exactly the same issue. Please resolv it as soon as possible.

[lolmaxz]

Same problem here for the past 2-3 days..
it’s really annoying because very often it lsoes what just got edited, making rollback complicated, knowing which files got edited or not and AI endeding up with an imcompleted task..
sometime it even crashes AFTER a prompt and editing was completed.. and yet when restarting, the last message and recap from the prompt is gone anyway.. sometime it even crashes while I’m literally halfway reading the AI’s recap I hope this gets fixed soon.

[Colin]

Hi all!

Can you please provide the exact version of Cursor that you’re using, alongside system details (Help > About or Cursor > About Cursor depending on your system).

[Landon_Brown]

same here bro

[hime]

Hi @Colin this is likely happening due to agent transcript writes (.jsonl), when serializing the json transcript Cursor goes above 4gb in usage and crashes as a result. Tool calls such as subagents also make the OOM happen faster.

This means I often have to start a new chat instead and abandon an old one, once a specific chat causes this. This is also the reason why it keeps repeating for some users, because they’re using an old chat that causes the issue.

[Peter_Jaeger]

Same here during every more complex prompt since yesterday:

Super annoying !

[Paul_Gibby]

The crash occurs for me when the agent has been running for 3+ minutes, the IDE and chats with agents seem fine until big jobs happen.

I’m using Cursor 2.5.26 system.

[Daniel_Havrlant]

I have the same problem.
189ac81f-1b99-422a-a0ef-6c58e023587f - reguest ID

I don’t think it’s a lack of memory.

[Colin]

Hey all!

We have fixed quite a few memory issues in 2.6, so please try upgrading (you can pull from https://cursor.com/downloads if your cilent hasn’t auto-updated)!

[Zangetsu_1450 (Barney S.)]

Yep, same issue here.

After updating to 2.6.11, I noticed right away that the program was running awfully slow, after a couple of prompts and basic operations RAM usage skyrocketed to 5GB+ (and climbing lol) with CPU usage hovering around 20-30% which points to some sort of memory leak.

Killing the process via task manager and a fresh restart to the welcome window “fixes the issue”, HOWEVER reopening the workspace (that has git history and a couple of active chats with agents) starts leaking memory again, the leak is so severe I can barely get to the built in process explorer without cursor crashing.

Version: 2.6.11 (user setup)
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z
Build Type: Stable
Release Track: Default
Electron: 39.6.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

[Yair_Katznelson]

Not just annoying, in-progress requests doesn’t get returned.

[Nick_Irons]

I now have the out of memory issue. I didn’t have an issue until cursor updated to 26.11 yesterday. My main project I can no longer work on because cursor closes within a couple of minutes. My backup dev machine has updated itself to the same version and is doing exactly the same thing.

Cursor is very unresponsive now on my other projects when I look at an existing agent chat.

Both pcs, 64gb memory, running nothing else.

I’d like to install the previous build, but the last previous I can see is 2.5

[kay_becking]

Same issue!