This also happens for me (macOS 3.22.12), seems to correlate with an update being made available. Afterwards, spawning new windows with keyboard or opening additional repos via code terminal command will attempt to open a new tab (language doesn’t seem to matter), the new window immediately crashes. Doubt max files is the issue for me (< 10k files open, maxfiles for a process should be > 100k for me). No logs pertaining to too many files open logged. Memory usage looks fine afaik.
According to llm: Cursor Helper (Renderer) (pid 66051) lived for about a third of a second, then called abort(). The crash report is SIGABRT (signal 6), and the helper’s own startup path is the one that prints “Failed to initialize sandbox.” Cursor’s main log matches that at 10:58:12: CodeWindow: renderer process gone (reason: crashed, code: 6).
…
“exception” : {“codes”:“0x0000000000000000, 0x0000000000000000”,“rawCodes”:[0,0],“type”:“EXC_CRASH”,“signal”:“SIGABRT”},
“termination” : {“flags”:0,“code”:6,“namespace”:“SIGNAL”,“indicator”:“Abort trap: 6”,“byProc”:“Cursor Helper (Renderer)”,“byPid”:66051},
…
“frames”:[…,{“imageOffset”:5672,“imageIndex”:0},{“imageOffset”:5488,“imageIndex”:0},{“imageOffset”:204416,“symbol”:“start”,“symbolLocation”:6688,“imageIndex”:9}]}],
…
Offset 5488 (0x1570) is the return address after this call, and the address loaded just above it is the C string at 0x100024f8a:
Failed to initialize sandbox.
The neighboring strings in that same binary are _NSGetExecutablePath: get path failed. and Failed to create seatbelt sandbox server. The 10:58:13 report took the sandbox-init path.
Further investigation via llm:
The sandbox profile never reached the renderer. The file descriptor it was supposed to arrive on was already invalid, so initialization aborted.
Cursor’s main process sends each new renderer a macOS seatbelt profile through a pipe. The renderer reads the profile length from the file descriptor named by --seatbelt-client, then applies it. At 10:58:12 that read failed immediately:
- Renderer:
SeatbeltExec: buffer length read failed: Bad file descriptor
- Main process:
SeatbeltExec: buffer length write failed: Broken pipe
Bad file descriptor means the descriptor number the renderer was given was not open in that process. It aborted with “Failed to initialize sandbox.” The main process then wrote the profile length into a pipe whose read end was already gone, which is the broken pipe. The same pair of errors is in the system log for every renderer crash from 10:51 through 10:58.
This is not a sandbox policy rejection, and it is not the open-file limit. sandbox_apply was never called. The profile handoff failed before that.
