# Window terminated unexpectedly / Crashed code: 6 **URL:** \ **Category:** Bug Reports\ **Tags:** crashes\ **Created:** [September 4, 2026, 8:52am UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562 "2026-09-04T08:52:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Gabriel\_Dehan](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@Gabriel\_Dehan](https://forum.cursor.com/u/Gabriel_Dehan)\ **Post date:** [September 4, 2026, 8:52am UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/1 "2026-09-04T08:52:44Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug When multiple instances (2+) of Cursor are already running, trying to open a new one will end up with the new one crashing and displaying an error box. The only way to go around it is to close all other instances of Cursor. ### Steps to Reproduce - Open 2 separate instances of Cursor - Try to open a third ### Expected Behavior It doesn’t crash ### Screenshots / Screen Recordings ![Screenshot 2026-09-04 at 09.33.18.png](https://us1.discourse-cdn.com/cursor1/original/3X/3/f/3f30b9f3cf24a6300ed92a001a10b38930feb41b.png) ### Operating System MacOS ### Version Information Version: 3.18.9 VS Code Extension API: 1.128.0 Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130 Date: 2026-08-27T01:42:22.092Z Layout: IDE Build Type: Stable Release Track: Default Electron: 40.10.3 Chromium: 144.0.7559.236 Node.js: 24.15.0 V8: 14.4.258.32-electron.0 xterm.js: 6.1.0-beta.291 OS: Darwin arm64 25.6.0 ### Additional Information This issue has been happening to me and multiple colleagues in our company. ### Does this stop you from using Cursor Sometimes - I can sometimes use Cursor ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 7, 2026, 1:31pm UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/10 "2026-09-07T13:31:26Z")
Hey @Gabriel_Dehan! Would be really interested to know if this thread applies to you (does the crash happen while working in large Typescript/Javscript repos?) > [@macOS: New window renderer crashes with code 6 when Cursor reaches 10,000 open file descriptors](https://forum.cursor.com/t/macos-new-window-renderer-crashes-with-code-6-when-cursor-reaches-10-000-open-file-descriptors/170190/17): > > Hi @Tomohiro_Hiratsuka, thanks for the follow-up — the restart numbers are very helpful. The fact that the count returns to roughly 9,800 files under backend/nestjs/src immediately after a restart suggests something that watches every TypeScript file in the project, rather than something that accumulates over a long session. Our leading suspect is the TypeScript language service’s file watching, which currently runs through Cursor’s main process and holds one open handle per watched file on mac… ---
**Author:** ![Gabriel\_Dehan](https://avatars.discourse-cdn.com/v4/letter/g/bb73d2/32.png) [@Gabriel\_Dehan](https://forum.cursor.com/u/Gabriel_Dehan)\ **Post date:** [September 16, 2026, 9:05am UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/13 "2026-09-16T09:05:26Z")
@Colin indeed, we are working on a monorepository that contains our rails monolith + our react-front-end as well as many sub-applications and libraries. We have around ~10M+ lines of code, so definitely qualifies as large! ---
**Author:** ![Rafael\_Ramalho](https://avatars.discourse-cdn.com/v4/letter/r/54ee81/32.png) [@Rafael\_Ramalho](https://forum.cursor.com/u/Rafael_Ramalho)\ **Post date:** [September 22, 2026, 1:52pm UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/14 "2026-09-22T13:52:17Z")
I can confirm it’s also happening to me with a big project (which typically gets the typescript has reached maximum meory warning often) ---
**Author:** ![Steven\_Berlan](https://avatars.discourse-cdn.com/v4/letter/s/9dc877/32.png) [@Steven\_Berlan](https://forum.cursor.com/u/Steven_Berlan)\ **Post date:** [October 1, 2026, 3:37pm UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/15 "2026-10-01T15:37:28Z")
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`: ```auto 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. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [October 1, 2026, 6:50pm UTC](https://forum.cursor.com/t/window-terminated-unexpectedly-crashed-code-6/170562/19 "2026-10-01T18:50:31Z")
Steven\_Berlan, the macOS maxfiles limit isn’t the one that matters here, since Cursor reaches its own ceiling long before that. Before you apply the setting, could you run this in Terminal the next time a new window crashes, and tell us the number it prints? ```auto lsof -p "$(pgrep -x Cursor | head -1)" | wc -l ``` Please also tell us whether any of your open windows is a large TypeScript or JavaScript project. A number around 10,000 or higher would confirm it’s the same cause. If the setting doesn’t stop the crashes, let us know and we’ll dig in further.