Hey, thanks for the report. This is an issue we’re tracking. On Windows, this kind of crash reason: 'oom' usually means the system kills the renderer when you run out of total committed memory RAM plus pagefile. Each Cursor window starts its own renderer and extension host, so memory usage grows with the number of open windows and long agent sessions. On Windows 10, this is a common trigger.
What you can try right now:
Keep fewer windows and long agent chats open at the same time.
Check that the pagefile is enabled and set to system-managed, not manually disabled: System Properties > Advanced > Performance > Settings > Advanced > Virtual memory.
When it crashes, check Task Manager > Performance > Memory, look at Committed. If it’s hitting the limit, that’s the case here.
If it still reproduces on 3.15.19 after that, please share main.log. It’s in %APPDATA%\Cursor\logs\...\main.log and you should see lines like renderer process gone (reason: oom). Also helpful are your RAM size and roughly how many windows were open when it crashed.
I can’t give an exact ETA yet, but I’ll update the thread if I have news.
This has happened to me a few times with a single window open and only two sessions, just by leaving the window up and doing nothing for a few hours. 64G of RAM
Hey @Roger_Collins, thanks for the details. Your case looks different from the original report in this thread: 64GB RAM, a single window, and a crash while idle does not look like memory pressure from lots of windows, so the pagefile advice above probably does not apply.
To figure out what’s actually happening, we’ll need a bit more info:
Your OS and Cursor version from Help > About.
The exact crash dialog text, it includes reason and code (for example reason: 'oom' or reason: 'crashed', code: 5). These are different crash types.
main.log from %APPDATA%\Cursor\logs\...\main.log on Windows or ~/Library/Application Support/Cursor/logs/... on macOS. You should see lines like renderer process gone (reason: ...).
If you can catch it, open Task Manager > Details, or Process Explorer via Cmd/Ctrl+Shift+P > Developer: Open Process Explorer, and check if the window process memory keeps growing while Cursor is idle.
If it turns out your scenario is consistently different like an idle crash with one window, it’s best to start a separate thread with this info so we can track it separately. Let me know what you find.
Hey, thanks for the update. I can see the Task Manager screenshot. Cursor is using about 1,4 GB across 20 processes, but the whole system is at 90% memory, and you have 16 GB of RAM. This is exactly the case I mentioned earlier. On Windows, the system kills the renderer with reason: 'oom' when total committed memory runs out RAM plus pagefile. With 16 GB and a few windows open, you can hit the limit fast, so the third window crashes right away.
We’re tracking this issue. I can’t give an exact ETA yet, but I’ll post in the thread if there’s an update.
For now, practical steps:
Keep no more than 1 to 2 windows open, and close long agent sessions when you don’t need them.
Check that the pagefile is enabled and set to system-managed, not disabled manually: System Properties > Advanced > Performance > Settings > Advanced > Virtual memory.
About the logs. The path %APPDATA%\Cursor\logs\...\main.log includes a subfolder with the date and time, so you won’t see it directly. Easiest way:
Ctrl+Shift+P > Developer: Open Logs Folder
Find main.log and search for lines like renderer process gone (reason: oom)
Please paste that part here, and also tell me how many windows were open when it crashed.
