16 renderer crashes in 3 days during composer-2.5 Agent loops on Cursor 3.7.36

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title: Frequent renderer crashes (code 5) on macOS 15.6 — Cursor 3.7.36

Cursor crashes repeatedly with:

CodeWindow: renderer process gone (reason: crashed, code: 5)

16 crashes between Jun 12–14, 2026. The app reloads but interrupts Agent/Composer sessions.

Environment

Cursor 3.7.36, macOS 15.6, Apple M3 Pro, 18 GB RAM
Swift/macOS app project
Repro

Normal use with Agent/Composer over multi-hour sessions
Crash often occurs during agent-loop with no clear user action
Expected: Stable during long Agent sessions
Actual: Renderer dies; window reloads; chat may be lost

Latest crash: 2026-06-14 17:47:18 (local), during composer-2.5 Agent session

Attachment: redacted logs (main.log, renderer.log, agent exec logs)

Request ID: 0a75850b-9998-47ae-974d-595ce15c5880

Steps to Reproduce

Steps to reproduce

Open Cursor 3.7.36 on macOS 15.6 (Apple M3 Pro, 18 GB RAM).
Open a Swift/macOS project workspace.
Use Agent/Composer (composer-2.5) over a multi-hour session — several agent turns with file edits, builds, and terminal commands.
Keep Cursor open with multiple chat/agent sessions across the day (not necessarily all at once).
Continue normal development work while agents run (agent-loop appears in logs before crashes).
Result: After some time (minutes to hours), the window crashes with no clear user action. macOS/Cursor reloads the window; the chat may be interrupted or lost.

Frequency: 16 times between Jun 12–14, 2026 — roughly several per day during active Agent use.

Most recent: Jun 14, 2026 at 17:47:18 local time, during an active Agent session.

Operating System

MacOS

Version Information

Version: 3.7.36
VS Code Extension API: 1.105.1

For AI issues: which model did you use?

Composer 2.5

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi Joe!

Thanks for the thorough report. This is a known issue we’re actively working on. On macOS, a code: 5 renderer crash during long agent sessions is almost always memory pressure, and the biggest single driver is a large source-control change set in your workspace.

Since you’re on a Swift/macOS project, the usual culprit is build output like DerivedData showing up as thousands of untracked files. Cursor tracks all of that, and over a multi-hour session the cumulative state can push the renderer past its memory limit, at which point the OS kills it.

What fixes this in practice:

  1. Trim the change set. In your repo, check how many files Git sees:
git status --porcelain | wc -l
  1. If that number is large, add generated/build folders to your .gitignore (and .cursorignore). For a Swift/iOS project, DerivedData and build/ are the common offenders. DerivedData is a regenerable build cache, so it’s safe to delete, Xcode rebuilds it on the next build.
  2. Start fresh chats periodically rather than keeping one thread open for hours. A very long conversation accumulates a lot of context, which adds to memory use.
  3. Go easy on concurrency. Avoid running many agents at once, or pasting/returning very large blocks of text in a single turn.
  4. Free up RAM during agent work. With 18 GB, Xcode and Cursor agents together can get tight, so closing other heavy apps (or not running big builds during a long agent session) reduces the pressure.

Your request ID checked out clean on our side, the backend completed that turn normally, so the crash is happening locally rather than being a server error.

If it persists after trimming the change set, open Process Explorer (Cmd+Shift+P → “Developer: Open Process Explorer”) and watch the renderer’s memory as you work. If you can catch it climbing right before a crash, share a screenshot and we’ll dig in further. More on capturing diagnostics: Reporting bugs.