Cursor crashes with OOM during PPT self-check stage when using Anthropic official PPT skill

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am consistently running into a crash when using Cursor to generate a PowerPoint presentation with Anthropic’s official PPT skill.

The presentation generation itself can start normally, but during the self-check / QA stage, Cursor repeatedly crashes and shows the following error:

Window terminated unexpectedly (reason: “oom”, code: “-536870904”)

This seems to happen specifically during the verification step after the PPT is generated, rather than during the initial content generation step.

Environment:

OS: Windows 10
App: Cursor
Workflow: PPT generation using Anthropic official PPT skill
Notes:
This issue happens repeatedly, not just once.
It appears to be tied to the self-check phase specifically.

Steps to Reproduce

Use Cursor to generate a PPT with Anthropic’s official PPT skill.
Let the workflow continue into the self-check / QA phase.
Cursor crashes and shows the OOM error dialog.

Expected Behavior

Expected behavior: Cursor should complete the PPT self-check process normally without crashing.

Operating System

Windows 10/11

Version Information

Version: 2.6.20 (user setup)
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Early Access
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

GPT-5.4

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, this is a known Windows issue. The Electron renderer process in Cursor hits a roughly 4 GB memory limit (V8 heap cap) and crashes with that exact oom or -536870904 error code. The PPT skill self-check phase is likely extra memory heavy since it processes a lot of generated content at once, so it hits that limit faster.

A few workarounds that should help:

  1. Rotate chats: start a new chat before the self-check phase, or anytime a session gets large. Long chat history is one of the biggest memory users.
  2. Monitor memory: Ctrl+Shift+P > Developer: Open Process Explorer. Watch the renderer process. If it gets close to roughly 3,5 to 4 GB, it’s about to crash.
  3. Check extensions: try running cursor --disable-extensions from the command line to rule out extensions adding memory pressure.

The team is aware of this type of OOM crash on Windows and is tracking it.

Related threads with more context:

Let me know if any of the workarounds help.

5

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