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.