Windows-only renderer OOM: Cursor’s renderer memory steadily grows toward ~3.8–4.0 GB during/after AI workflows and then Cursor crashes with
renderer process gone (reason: oom, code: -536870904) / “window terminated unexpectedly (reason: oom…)”.
This happens across Agent / Plan+Build / Ask / Debug and persists in Safe Mode (–disable-extensions). The crash can occur 2–3 minutes after the prompt finishes while Cursor is idle (background processing).
In some cases the crash corrupts local storage (e.g., state.vscdb moved to state.vscdb.corrupted.*), and chats disappear or get stuck on “Loading chat…”.
Steps to Reproduce
On Windows (repro on Windows Server 2022), work in a long-running project chat for an extended period so the chat accumulates substantial context/history.
• Reproduced in:
• Scenario A: very large chat (~25k+ lines)
• Scenario B: medium chat (~7.5k lines)
Once the chat is “context-heavy”, trigger any new request (not necessarily a large analysis), e.g. organizing debug logs, continuing a debug workflow, small follow-ups, or “planning next moves”.
Observe in Developer → Open Process Explorer that the active window/renderer memory rises steadily (~0.5GB → 1GB → 2GB → 3GB+).
Near ~3.8–4.0GB, Cursor crashes with the OOM renderer error. Sometimes this happens 2–3 minutes after the prompt completed.
After some crashes, Cursor may reopen in a “fresh” state and chat history becomes unavailable (“Loading chat…”) due to state.vscdb corruption/rename to state.vscdb.corrupted.*.
Expected Behavior
Cursor should not crash as renderer memory approaches ~4GB. Memory should remain bounded or be released (or Cursor should degrade gracefully via streaming/chunking).
Chat history should remain readable after a crash (no state.vscdb corruption leading to “Loading chat…” / missing chats).
Screenshots / Screen Recordings
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
For AI issues: add Request ID with privacy disabled
N/A
Additional Information
• System: Windows Server 2022 Standard 21H2 (Build 20348.4648), Ryzen 7 PRO 8700GE, 64GB RAM.
• Safe Mode: cursor --disable-extensions still crashes.
• Indexing mitigations: .cursorignore / .gitignore applied to exclude large artifacts (runs, exports, jsonl/gz/csv, shards, backups, logs). Codebase index ~3906 files.
• Workaround: Starting a new chat temporarily avoids the issue, but resets project context; crash is unpredictable and can force mid-task restarts (time/token overhead).
• Log evidence: main log contains CodeWindow: renderer process gone (reason: oom, code: -536870904).
• Storage corruption evidence: observed state.vscdb / state.vscdb.backup (~16MB) and state.vscdb.corrupted.* (~14.8GB) in %APPDATA%\Cursor\User\globalStorage.
Hey thanks for the report. The error “renderer process gone (reason: oom, code: -536870904)” means the Cursor renderer process exceeded ~4GB of memory and was terminated by Windows - this is a problem with large chat histories on Windows.
Start a new chat instead of continuing the current one (~25k lines is a lot of context)
Export your profile
Delete the corrupted state.vscdb: go to %APPDATA%\Cursor\User\globalStorage, find the folder with state.vscdb.corrupted.* (~14.8GB!) and delete all state.vscdb* files in that folder
If you’re on version 2.3.35-2.3.41, check your logs for OTEL errors (OpenTelemetry memory leak). If you find them, downgrade to 2.3.34 and turn off auto-updates in Settings > Application > Update > “none”
Use Ctrl+Shift+P > Developer: Open Process Explorer to monitor the renderer process memory usage in real time
Technical reason: Electron on Windows has a ~4GB limit for renderer processes (32-bit pointer compression), and large chat histories plus AI workflows accumulate memory without releasing it. state.vscdb corruption happens when a crash occurs during a write operation.
Thanks Dean! I appreciate the clear explanation.
I confirmed there are no OTEL/OTLP errors in my logs.
I’ll use chat rotation + Process Explorer monitoring as a workaround for now and will avoid letting long sessions build up to the ~4GB renderer limit.
Please keep me posted if there’s a patch or recommended mitigation beyond starting new chats. Thanks again.
The OTLPExporterError (OpenTelemetry) is caused by a bug introduced in Cursor v2.3.35 where the editor attempts to send trace spans that the server rejects (usually with a 400 “Bad Request”). Instead of failing silently, these errors flood the internal logs, causing a memory leak in the renderer process.
On Windows, Electron processes have a hard limit of ~4GB. Once the leak hits this threshold, it triggers the OOM (Out of Memory) crash with code -536870904.
Here are the specific steps to disable these services and stop the crashes:
1. Immediate Settings Mitigation
Open your settings.json (Ctrl+Shift+P → Preferences: Open User Settings (JSON)) and add or update these keys:
telemetryLevel: Reduces the data sent, though it may not fully kill the OTEL exporter bug.
disableHttp2: This has been a reported workaround for “socket disconnected” errors that often precede the OOM crash.
2. Enable Privacy Mode
Go to Settings (Ctrl+,) > General > Privacy Mode and toggle it On. While this is intended for data security, it often forces the app to bypass certain telemetry-heavy pipelines.
3. The “Guaranteed” Fix: Rollback to v2.3.34
Since the OTEL regression started in v2.3.35, the most stable solution for Windows users currently is to roll back to the previous version and lock updates.
Uninstall your current version of Cursor.
Download v2.3.34 from the official Cursor download archive (or look for the 2.3.34 Windows installer link in the community forums).
Disable Auto-Updates immediately after installing:
Go to Settings > Application > Update.
Set Update Mode to none.
4. Advanced: System-Wide OTEL Kill Switch
You can try to force the OpenTelemetry SDK to disable itself by setting an environment variable on your Windows machine: