Renderer crash (code 5) with 4–5 simultaneous git worktrees and /loop agent sessions

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor crashes completely — the entire application dies, not just a single chat or editor tab.

The crash dialog shows:

“The window terminated unexpectedly (reason: ‘crashed’, code: ‘5’)”

This only happens in Cursor. Other software on the same machine is stable.

The crashes are most common when I run a heavy workflow:

  • 4–5 simultaneous git worktrees open in Cursor (via /worktree or Agents Window)
  • Multiple agent sessions running in parallel across those worktrees
  • Using /loop for recurring agent tasks (background loops that wake the agent on an interval)

When it crashes, the whole Cursor process goes down. I am not seeing an isolated chat failure — the entire app terminates and I have to reopen Cursor (sometimes losing in-progress agent context even when files on disk were already written).

I’m working in a large Yarn monorepo. Each worktree may also run its own dev stack, but the failure is specifically Cursor’s renderer/main process crashing with code 5.

I have attached screenshots of the crash dialog.

Steps to Reproduce

  1. macOS 26.5.1 (25F80), Apple M5 Max, 64 GB RAM
  2. Cursor 3.9.16 (Stable), Layout: glass, Electron 40.10.3, Chromium 144.0.7559.236
  3. Open a large monorepo workspace in Cursor
  4. Create 4–5 git worktrees (Cursor /worktree or Agents Window)
  5. Run multiple agent sessions in parallel across those worktrees
  6. Use /loop in at least one session (e.g. /loop 5m ) so agents keep waking on an interval
  7. Continue working until agents are doing multi-file edits / long streaming turns
  8. The entire Cursor application crashes with: reason ‘crashed’, code ‘5’

Frequency: recurring under this workload; much less common (or absent) with fewer worktrees / no loops.

Expected Behavior

Cursor should stay stable with multiple worktrees, parallel agents, and /loop sessions. A crash should not take down the whole application.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Cursor:

  • Version: 3.9.16
  • VS Code Extension API: 1.105.1
  • Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
  • Date: 2026-06-27T06:41:01.941Z
  • Layout: glass
  • Build Type: Stable
  • Release Track: Default
  • Electron: 40.10.3
  • Chromium: 144.0.7559.236
  • Node.js: 24.15.0
  • V8: 14.4.258.32-electron.0
  • OS (from About Cursor): Darwin arm64 25.5.0

Machine:

  • MacBook Pro 16-inch, M5 Max
  • 64 GB RAM
  • macOS 26.5.1 (25F80)

Workload:

  • Large Yarn 4 monorepo
  • 4–5 simultaneous git worktrees
  • Parallel agent sessions + /loop
  • Whole-app crash (not chat-only)

For AI issues: which model did you use?

Composer 2.5

Additional Information

Everything is running smoothly in my machine, the problem is just Cursor, it gets slow and crashes

some logs from main.log :
“2026-06-30 15:01:27.076 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:01:32.691 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=3
2026-06-30 15:01:35.148 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=3
2026-06-30 15:02:19.979 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:02:25.874 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=4
2026-06-30 15:02:29.227 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=4
2026-06-30 15:02:36.412 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:04:04.336 [info] [Tray] getMacOSIconPath: hasNotifications: true
2026-06-30 15:04:04.366 [info] [PowerMainService] Stopping wakelock id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:04:04.379 [info] [PowerMainService] Stopped background throttling disable id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:05:05.498 [info] [PowerMainService] Stopping wakelock id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:05:05.501 [info] [PowerMainService] Stopped background throttling disable id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:08:29.238 [info] [PowerMainService] Stopping wakelock id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:08:29.248 [info] [PowerMainService] Stopped background throttling disable id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:09:58.493 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:09:58.523 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:12:23.541 [info] [Tray] getMacOSIconPath: hasNotifications: true
2026-06-30 15:12:23.563 [info] [PowerMainService] Stopping wakelock id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:12:23.572 [info] [PowerMainService] Stopped background throttling disable id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:12:48.913 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:12:48.945 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:13:22.529 [info] [Tray] getMacOSIconPath: hasNotifications: true
2026-06-30 15:13:22.549 [info] [PowerMainService] Stopping wakelock id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:13:22.554 [info] [PowerMainService] Stopped background throttling disable id= owner=window: reason=“agent-loop” heldForMs=
2026-06-30 15:13:41.113 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:13:41.131 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=2
2026-06-30 15:15:43.608 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=3
2026-06-30 15:15:43.638 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=3
2026-06-30 15:18:30.623 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:19:00.977 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:19:20.099 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:19:48.077 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:20:39.519 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=4
2026-06-30 15:20:39.563 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=4
2026-06-30 15:20:45.447 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:21:04.874 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:21:48.392 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:22:36.325 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:22:59.534 [warning] No ptyHost heartbeat after 6 seconds
2026-06-30 15:23:24.673 [warning] [RendererPing] window blocked for ~17869ms
2026-06-30 15:25:16.389 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)
2026-06-30 15:25:16.681 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:25:16.683 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:25:16.684 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:25:16.685 [info] Extension host with pid exited with code: 0, signal: unknown
2026-06-30 15:29:04.083 [info] [LocalAgentStorage] Scanned recent databases, found agent headers, deduped agent headers
2026-06-30 15:29:15.237 [info] [CursorProclistService] Config enabled feature
2026-06-30 15:29:30.003 [info] [PowerMainService] Started wakelock id= owner=window: reason=“agent-loop” activeCount=5
2026-06-30 15:29:30.018 [info] [PowerMainService] Disabled background throttling id= owner=window: reason=“agent-loop” activeCount=5”

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

This is a known one we’re actively working on. On macOS a code: 5 crash is the whole renderer process being killed under memory pressure, so the entire window goes down rather than a single chat. Your main.log lines up exactly with that: the renderer gets blocked (RendererPing … blocked for ~17869ms) right before renderer process gone (reason: crashed, code: 5).

The key thing for your setup: each Cursor window runs a single renderer process with one shared memory budget, and everything in that window (all your worktrees, agent sessions, and /loop runs) shares it. So even with 64 GB on the machine, stacking 4–5 worktrees + parallel agents + loops into one window concentrates all of it into one process until it gets killed. A large change set makes it much worse, because every uncommitted/untracked file gets streamed into that same renderer.

What helps in practice:

  1. Spread the work across separate windows. If you’re running everything inside one Agents/Glass window, move heavy worktrees/agents into their own windows. Each window gets its own renderer and memory budget, so no single process has to carry everything.
  2. Lower the concurrency per window. Fewer simultaneous agents and /loop sessions in a given window. /loop keeps agents resident and waking on an interval, which adds steady pressure.
  3. Keep the Git change set small — this is the biggest single lever. In a Yarn monorepo, generated/build output (dist/, build/, .next/, coverage/, .turbo/, etc.) showing up as thousands of untracked files is the usual culprit. Add those to your .gitignore and commit or stash work in progress. You can check the current count with:

git status --porcelain | wc -l

  1. Collapse the Source Control / Changes panel while agents are running. Rendering a very large diff list is a known amplifier.
  2. Stay on the latest Stable. We’ve been shipping improvements in this area, so keeping updated helps.

If it still crashes 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, grab a screenshot and we’ll dig in further. More on capturing diagnostics: Reporting bugs.