Renderer process crashes (code 5) after every agent-loop completion

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every renderer crash is directly preceded by an agent-loop wakelock in the logs. The crash happens 1–5 minutes after the agent-loop ends. This happens consistently and reproducibly across multiple sessions.

Log pattern (from main.log):
This pattern repeats without exception — every crash in today’s session followed an agent-loop.

What I’ve tried:
• disable-hardware-acceleration in argv.json — no effect
• --max-old-space-size=8192 js-flag — no effect
• Reducing open windows — delays but doesn’t prevent crashes

Expected behavior: Renderer should not crash after agent-loop completes.

Hypothesis: Agent-loop leaves behind memory or state in the renderer that is not cleaned up, eventually causing the renderer to be killed by the OS (SIGKILL, exit code 5).

Steps to Reproduce

System Info:
• macOS 26.3.1 (Build 25D2128), arm64
• 128 GB RAM
• Cursor 2.6.14

Installed Extensions:
• anysphere.cursorpyright
• charliermarsh.ruff
• github.vscode-github-actions
• golang.go
• mechatroner.rainbow-csv
• ms-azuretools.vscode-containers, vscode-docker
• ms-python.python, debugpy
• ms-toolsai.jupyter (+ renderers, cell-tags, slideshow)
• solomonkinard.git-blame

Key observation — crashes correlate with activeCount growing:
The crash rate gets worse as more windows are opened. The activeCount went from 1 → 6 over the session, and crashes became more frequent and faster:

activeCount Time between agent-loop end → crash
2 ~2 minutes
3 immediate (2 seconds)
4–5 seconds to 1 minute
6 4–43 seconds
Reproducibility:
• Open 4–6 Cursor windows in different workspaces
• Run agent loops in each
• Crash occurs within seconds–minutes of any agent-loop completing
• 100% reproducible — zero crashes occurred without preceding agent-loop activity in today’s full session log

Operating System

MacOS

Version Information

Version: 2.6.14
VSCode Version: 1.105.1
Commit: eb1c4e0702d201d1226d2a7afb25c501c2e56080
Date: 2026-03-08T15:36:54.709Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Sonnet 4.6

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, thanks for the detailed report. The agent-loop wakelock to crash correlation and the activeCount table are really useful data points.

This is a known issue with renderer crashes (code 5) on macOS that’s been affecting multiple users since around version 2.5.26. A few threads have been tracking it:

The team is aware and tracking this. Your note about crash frequency increasing with activeCount is a new signal that should help the investigation.

One thing that might help for now is keeping fewer Cursor windows open at the same time. Based on your data, crash timing goes from about 2 minutes with 2 windows to seconds with 6 windows. Not a real fix, but it might make things more usable until this is resolved.

Could you also share the full main.log from Help > Open Logs Folder? The raw log with timestamps around the crashes would be useful for the team, especially wakelock acquire and release entries paired with crash events.

5

main.log.txt (27.7 KB)

See attached.

7

Thanks for the logs. A couple of observations:

  1. activeCount in wakelocks only goes up and never goes down, so wakelocks from crashed windows aren’t being released. This likely makes the issue worse after each crash (cycle: crash → new window → activeCount++ → next crash happens sooner).

  2. Closer to the end of the session, errors like SQLITE_ERROR: cannot start a transaction within a transaction show up in AgentAnalyticsOperationsMainService. This might be related to increasing resource pressure over time.

I shared this log and these notes with the team. The agent-loop → crash correlation and the activeCount leak are useful signals for the investigation.

For now, the only practical workaround is to minimize the number of Cursor windows open at the same time, and fully restart the app (not just the window) after every 2 to 3 crashes to reset activeCount. I know this isn’t a real fix, but it should help reduce how often it happens.

Let me know if anything changes.

9

Hey @danpe!

Can you let us know if you’re still facing this issue on v2.6.22?

10

Fixed !

1 Like