Hey, thanks for the report. Code 133 (128+5, SIGTRAP) is a hard process crash, and based on your description it sounds like a known class of issues where lots of parallel agents put too much load on the renderer’s memory or CPU. Your Electron version is correct (39.8.1), so this isn’t an Electron mismatch issue on Arch.
To narrow down what’s happening, could you share a couple details?
Where exactly do you see code 133, in the terminal as an exit code, in a crash dialog inside Cursor, or does the whole window or the extension host crash?
How much RAM does your system have?
If you run fewer agents (1 to 2), do the crashes stop?
For now, a workaround:
Run fewer agents at the same time
Disable unused extensions and MCP servers, they also increase memory usage
Watch memory usage in your system monitor when you run many agents
We’ve got an issue in this area on our radar, but I can’t share an ETA for a fix yet. Let me know the answers to the questions above, they’ll help narrow down the cause.
Hi there, I see in the crash dialog inside Cursor. My system has 32 GB RAM and 32 GB swap and by the time of exiting the swap is not occupied any.
I can run 1 to 2 agents but that is NOT the point! Cursor should be doing better it should supports multiple active agent with heavy workflow. Otherwise what advantage do you have if we keep crashing? Did you managed locality and efficiency well in Cursor backend?
Thanks for the details, they help. And you’re basically right: Cursor should handle heavy multi-agent setups better, that’s fair feedback.
A couple important points about your case. The fact that swap isn’t used and you have 32 GB free is actually expected. A crash with code 133 is a hard crash of a single process like the renderer or extension host. It’s not hitting overall system memory, it’s hitting that process’s own limit. So free RAM won’t save it here. Running 5+ agents at once creates a CPU and memory spike inside that process.
Performance with lots of parallel agents is a known area we’re tracking on our side. I can’t share an ETA for a fix yet, but it’s not working as intended and it’s something we’re actively working on.
For now, to make things more stable:
Keep it to 3 to 4 agents instead of 5+ at the same time. Since 1 to 2 is stable for you, try to find the threshold.
Disable unused extensions and MCP servers. Each one adds to the process memory.
If you have heavy extensions, check what’s using resources right before the crash via Process Explorer: Cmd+Shift+P > Developer: Open Process Explorer.
One quick question to narrow it down: what does the crash dialog say exactly? Is it the renderer crashing meaning the whole window, or the extension host? If you can paste the dialog text or a crash log, it’ll help confirm what the process is running into.
at R._deliver (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:2937)
at R.fire (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:3257)
at ql.value (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:30:5574)
at R._deliver (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:2937)
at R._deliverQueue (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:3028)
at R.fire (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:3364)
at y6.deregisterLogger (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:37:20979)
at y6.deregisterLogger (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:75:34611)
at y6.deregisterLoggers (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:75:35374)
at wf.dispose (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:82:519)
at ql.value (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:78:167230)
at R._deliver (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:2937)
at R.fire (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:32:3257)
at BrowserWindow.Q (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:30:8061)
at BrowserWindow.emit (node:events:531:35)
at wf.destroyWindow (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:78:182492)
at async wf.onWindowError (file:///tmp/.mount_cursor4lglli/usr/share/cursor/resources/app/out/main.js:78:181801)
Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed
Please trace it! Looks like it is your poor rendering issue.
Thanks for the log, it’s helpful. Good news: it confirms what we suspected and doesn’t point to a separate new issue.
The stack you sent starts in the main process main.js and ends at onWindowError -> destroyWindow. That means the renderer already crashed, and at that moment the main process is trying to clean up after it, like deinitializing loggers. The line Render frame was disposed before WebFrameMain could be accessed is a result of cleanup after the crash, not the cause. So this is a renderer crash under load, exactly the kind we discussed: 5+ agents running at the same time create a CPU and memory spike inside the renderer process, and it hard crashes with code 133 / SIGTRAP.
This isn’t works as intended. Performance with a large number of parallel agents is something we’re tracking on our side. I can’t give an ETA for a fix yet.
To make it more stable right now:
Keep 3 to 4 agents instead of 5+ at once. Since 1 to 2 are stable for you, try to find the threshold
Disable unused extensions and MCP servers, each one adds memory overhead to the process
Before it crashes, check Process Explorer via Cmd+Shift+P > Developer: Open Process Explorer to see what’s using resources
If you catch more logs or notice a specific trigger, like it only crashes after a certain action, send it here and I’ll add it to what we’re already tracking.