Scratch what I said about 2 windows, I had that wrong. My colleague got 4 before it broke. And it’s not really about the number of windows at all, it’s time. After Cmd+Q I can open a window fine, then a few minutes later nothing opens, even with zero windows open. So something is filling up while the app runs.
I think it’s file descriptors. Checked the main process after about 5 hours of uptime:
```
unique numeric fds : 10000
lowest : 0
highest : 9999
gaps in 0..9999 : 0
fds >= 10000 : 0
```
0 through 9999, contiguous, nothing above. That’s a full table. No free fd for a new renderer’s sandbox socket.
Which lines up with where it dies. Here’s the relevant part of the crash, this is the 11:11 one but all four from this morning are the same:
```
procName = Cursor Helper (Renderer)
parentProc = Cursor
osVersion = macOS 26.6 (25G72)
cpuType = ARM-64
procLaunch = 2026-08-05 11:11:52.5483 +0300
captureTime = 2026-08-05 11:11:53.1741 +0300
exception = {“type”:“EXC_CRASH”,“signal”:“SIGABRT”,“codes”:“0x0, 0x0”}
termination = {“namespace”:“SIGNAL”,“code”:6,“indicator”:“Abort trap: 6”,
"byProc":"Cursor Helper (Renderer)"}
faulting thread 0:
0 __pthread_kill libsystem_kernel.dylib
1 pthread_kill libsystem_pthread.dylib
2 abort libsystem_c.dylib
3 abort_report_np libsystem_c.dylib
4 <helper stub +40300>
5 <helper stub +40196>
6 start dyld
threads = 1
images = 11
Electron Framework 40.10.3
```
Dead 0.6s after launch. 1 thread, 11 loaded images. A working renderer on this machine has 126 threads, so this is gone well before Chromium loads. Your log agrees:
```
2026-08-05 11:11:53.174 [error] CodeWindow: renderer process gone (reason: crashed, code: 6)
```
The renderer helper is a small stub, 221KB, that sets up the seatbelt sandbox and hands off to ElectronMain. Only abort paths I can find in it are sandbox related:
```
Failed to create seatbelt sandbox server.
Failed to initialize sandbox.
SandboxSerializer: Failed to apply compiled policy: %s
SeatbeltExec: %s %s failed
```
Sandbox setup needs an fd, there isn’t one, so it aborts before doing anything else. That’s my read anyway, frames 4 and 5 are in the stub so I can’t symbolize them exactly.
Where the fds went: 13,000+ pointing into my project dir, across ~10,000 distinct paths. Ordinary source subdirectories, not files I have open. Log is also full of these in bursts:
```
[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
[warning] [File Watcher (node.js)] Watcher shutdown because watched path got deleted
```
Guessing watchers get torn down and recreated as our build writes into the tree, and descriptors don’t get closed on the way out. Would explain why my colleague and I hit it at different window counts (depends on project size and churn), why quitting fixes it, and why it comes back a few minutes later.
Not memory. 64GB, 52% free when it crashed. Not a broken install either, codesign passes clean on the app and the helper.
I have 43 extensions so --disable-extensions is a reasonable thing to ask, but I didn’t test it properly. A short test passes no matter what since the leak takes minutes to build. Can run it longer if you want.
```
Cursor 3.14.7
Electron 40.10.3
macOS 26.6 (25G72), arm64, 64GB
Project large monorepo, ~47k files, one worktree
Extensions 43, 1 MCP server
Crashes 33 renderer crashes since Aug 2, 25 of those on Aug 3
```
Worth flagging: managed work laptop with EDR running a network monitoring system extension plus a couple of other agents. EDR keeps descriptors on files it scans so I probably hit the ceiling faster than most people. Don’t think it’s the cause though, the fds are on normal source files and the abort is in your sandbox path.
If you want to check this on another machine, run it while Cursor is broken but before quitting:
```bash
MAIN=$(pgrep -f “Cursor.app/Contents/MacOS/Cursor” | head -1)
lsof -p $MAIN | awk ‘NR>1 && $4 ~ /^[0-9]+[rwu]/{n=$4; gsub(/[^0-9]/,“”,n); print n}’ \
| sort -un | awk ‘NR==1{min=$1} {max=$1; n++} END{print “fds:”,n,“min:”,min,“max:”,max}’
```
Count sitting at the ceiling with no gaps means same thing.
Two things. Any way to raise the fd limit or put the file watcher on polling in the meantime? Restarting every few minutes is painful. And would a verbose main log while the leak builds be useful for finding which watcher isn’t closing? I can grab fd counts over time if that helps.
Happy to send the full crash files if you need them, just say where.
