Cursor crashes and shows me that error code. It’ll open and let me prompt/move around. But seconds after sending in a prompt it freezes and shows me that.
Hey, this is a known macOS issue with the renderer process (code 5). It most often shows up after long Composer or Agent sessions, when the tab builds up a lot of memory. We’re tracking it, but I can’t share an ETA for a fix yet.
For now, you can try:
Start a new chat instead of continuing a long Composer thread. In long sessions the tab uses more memory, and at some point Chromium kills it.
Close extra Agent or Composer tabs and restart Cursor.
Check the size of ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb. If it’s huge (like 1 GB or tens of GB), that’s a separate case, let me know the size.
A few questions so I can link this to our tracker more accurately:
Does it crash in any window, or only when a large Composer thread is open?
After restarting Cursor, does it crash right away when you try to send a request, or does it work fine for a while?
If you have a Request ID from a try that crashed, please send it (top-right chat menu > Copy Request ID).
If I get an update on the fix, I’ll reply in this thread.
usually crashes after i use plan mode in a new thread using 2.5 now, then when trying to build that plan in either opus GPT or composer in that same thread it crashes.
My work around has been copying the plan starting new thread and it works.
It does not crash right after opening but if i ever try to build in that same thread the error occurs again
Hey, thanks for the details, this is a helpful repro. The fact that it consistently crashes on build in the same thread after plan mode, but copying the plan into a new chat works, matches a known pattern. After a long time in one thread, the renderer builds up state like detached DOM nodes, transcript payload, and so on, and at some point Chromium kills it. The build phase with a large plan context is exactly when the load spikes.
Your workaround of copying the plan into a new thread is the best option right now, so I’d keep doing that until a fix ships. We’re tracking the bug, but there’s no ETA yet.
One quick question just in case. Can you check the size of ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb? If it’s very large, like a few GB or more, that’s a separate case and it may be worth cleaning it up. If it’s within a few hundred MB, then it’s likely the same renderer memory issue we’re tracking.
