Renderer crashes silently when opening 4th concurrent agent session

[manototh]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Opening a 4th concurrent agent session causes the Cursor renderer process to crash instantly and silently. No warning is shown, no macOS crash report is generated, and Activity Monitor shows normal memory usage at the time of the crash — ruling out system-level memory pressure.

Steps to Reproduce

Open 3 agent sessions (any tasks)
Open a 4th agent session
Renderer crashes immediately
Expected behavior: The 4th session opens successfully, or Cursor shows a warning and refuses to open it gracefully.

Actual behavior: The renderer process exits silently the instant the 4th session starts. No dialog, no warning. Cursor restarts and all open sessions are lost.

Evidence from logs: The final two entries in renderer.log before every crash are always:

[ComposerWakelockManager] Acquired wakelock id=N reason=“agent-loop” composerId=…
[buildRequestedModel] composerId=… catalogModelId=claude-sonnet-4-6 …
Nothing follows. The renderer dies between wakelock acquisition and the first model call. The crash is fully deterministic — it happens at the same code point every time.

What this suggests: The consistency of the crash point (always the same two log lines, always on the 4th session) points to a code bug in the renderer — such as a null reference, unhandled promise rejection, or V8 heap limit — rather than general memory pressure. This should be reproducible.

Operating System

MacOS

Version Information

3.1.15 (darwin-arm64)

For AI issues: which model did you use?

Sonnet 4

Additional Information

Workspace: large monorepo root (~/GitHub) with multiple sub-repos
Sessions involve documentation tasks with heavy file I/O (reading/writing large MDX files)
Earlier in the same session, 3 concurrent agents caused a slower “unresponsive window” failure (CodeWindow: recovered from unresponsive ×2 in main.log) before graduating to the instant crash pattern when a 4th was added
No entry in ~/Library/Logs/DiagnosticReports/ for any of the crashes

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[deanrie]

Hey, thanks for the detailed report. The determinism on the 4th session and the clear cutoff point in the logs (Acquired wakelock → buildRequestedModel → silence) are really helpful.

This matches a known class of renderer OOM crashes when you have multiple parallel agent sessions in a large monorepo. The composer state store accumulates in the renderer’s V8 heap, and once it hits a certain threshold (for you it’s the 4th session), the process dies without a DiagnosticReport because it’s specifically hitting the V8 heap limit, not system memory. That’s why Activity Monitor still looks normal. The “recovered from unresponsive ×2” symptom with 3 sessions is the same process, just not at the limit yet.

Related thread with the same pattern: Renderer OOM when agent turn loads many file contexts + large writes. I flagged your case to the team. The deterministic 4th session adds a useful signal for narrowing down the threshold. No ETA yet, but it’s on the radar.

Workarounds for now:

• Keep it to max 2 to 3 parallel sessions on big monorepos.
• If possible, split up work involving large MDX and generally heavy I/O. Either fewer files in @context per turn, or fewer big writes in the same turn.
• Restarting Cursor between batches of sessions clears the accumulated composer state.

If you can share the full renderer.log and main.log around the crash moment (Help → Show Logs → open folder), I can attach them to the internal ticket. It’ll help with repro.