macOS: New window renderer crashes with code 6 when Cursor reaches 10,000 open file descriptors

[Tomohiro_Hiratsuka]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Cursor 3.18.9 for macOS, an existing window and its running agents/terminals continue to work, but File > New Window / Cmd+Shift+N immediately crashes the newly launched Cursor Helper (Renderer) with code 6.

Read-only diagnostics taken while preserving the running session show that the main Cursor process is holding exactly 10,000 numeric file descriptors (highest FD 9999). 9,800 are regular files from one workspace; 9,798 point into /backend/nestjs/src. That directory contains 10,004 files, so Cursor is retaining descriptors for nearly the entire source tree.

At each failed new-window launch, macOS logs SeatbeltExec Broken pipe / Bad file descriptor immediately before the renderer exits. Existing windows remain usable.

Steps to Reproduce

1. Open a large workspace (the affected source directory contains 10,004 files).
2. Use Cursor/Agents in a long-lived session until the main Cursor process retains 10,000 numeric FDs.
3. Verify with lsof that most descriptors point to individual source files.
4. Choose File > New Window or press Cmd+Shift+N.
5. The new renderer aborts immediately with code 6; the existing window and running agents remain alive.

Observed twice consecutively at 2026-09-01 16:22:36 and 16:22:40 (+08:00).

Expected Behavior

A new window should open normally. Cursor should not retain a separate open descriptor for nearly every source file, and renderer startup should not fail when the main process reaches its FD ceiling.

Operating System

MacOS

Version Information

Version: 3.18.9 (Universal)
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Date: 2026-08-27T01:42:22.092Z
Build Type: Stable
Electron: 40.10.3
OS: macOS 26.6.2 (Darwin arm64 25G83)

Additional Information

Sanitized evidence:

lsof summary:
numeric_fds=10000
max_fd=9999
workspace_regular_files=9800
/backend/nestjs/src descriptors=9798
actual files in that directory=10004

macOS unified log:
2026-09-01 16:22:36.489 Cursor: SeatbeltExec: buffer length write failed: Broken pipe
2026-09-01 16:22:36.910 ReportCrash: SeatbeltExec: buffer length read failed: Bad file descriptor
2026-09-01 16:22:40.175 Cursor: SeatbeltExec: buffer length write failed: Broken pipe
2026-09-01 16:22:40.763 ReportCrash: SeatbeltExec: buffer length read failed: Bad file descriptor

Cursor main.log:
2026-09-01 16:22:36.921 CodeWindow: renderer process gone (reason: crashed, code: 6)
2026-09-01 16:22:40.772 CodeWindow: renderer process gone (reason: crashed, code: 6)

Two macOS Diagnostic Reports show:
Process: Cursor Helper (Renderer)
Exception: EXC_CRASH
Signal: SIGABRT
Termination namespace: SIGNAL
Termination code: 6
Indicator: Abort trap: 6

The installed Cursor bundle currently passes:
codesign --verify --deep --strict /Applications/Cursor.app
=> valid on disk; satisfies its Designated Requirement.
System memory was not exhausted.

This provides strong evidence for the immediate causal chain:
Cursor retains 10,000 FDs → renderer sandbox pipe fails with EBADF/Broken pipe → new renderer aborts with SIGABRT/code 6.
The deeper reason Cursor retains almost every source file descriptor is not yet determined.

Related reports:

Cursor IDE Crash on new window

Hey, thanks for the detailed report. Sending the version and a screenshot right away really helps. Code 6 on macOS is SIGABRT, and based on the symptoms this looks like a different type of issue than the other crash reports, so I want to dig into your specific case. To figure out what’s actually crashing, I need a couple things: Crash report. Open Console.app → on the left, go to Diagnostic Reports (Crash Reports), find the newest file like Cursor Helper (Renderer)-*.ips with the time of the …

My agent cannot run terminal

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Cursor 3.17.19 (Universal), commit ae3a2b7231dd56194447fe4570dfdc61640b1e90, date 2026-08-24 Layout: Agent Window and main editor Agent (both fail) Electron 40.10.3, Node 24.15.0, macOS Darwin arm64 25.6.0 Legacy terminal on, run mode auto review IDE terminal works (echo ok) Agent Shell: “no exit status / execution environment may need to be restarted” Other tools: spawn EBADF Reboot, quit/reopen, new chats already …

Also related: forum topic 165059 documents an Agents Window process retaining about 22,000 snapshot file descriptors.

I can provide the two .ips reports and relevant log excerpts privately if needed. Raw reports are not attached publicly because they may contain local paths.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Tomohiro_Hiratsuka]

[Colin]

Hey @Tomohiro_Hiratsuka, thanks for the detailed report!

This matches a known issue we’re tracking: over long sessions, Cursor on macOS can accumulate a very large number of open files, after which new windows fail to open (code 6) while existing ones keep working. I’ve linked your report to it.

Workarounds:

• Fully quit Cursor (Cmd + Q) and reopen. This resets the open-file count.
• Exclude build output from the file watcher: Cmd + Shift + P > Open VS Code Settings, search files.watcherExclude, and add patterns like **/dist/**, **/build/**, **/node_modules/**.

To help us find the root cause, two asks:

1. After a fresh relaunch, track the count periodically:

while true; do printf '%s  ' "$(date +%H:%M:%S)"; lsof -p "$(pgrep -x Cursor | head -1)" | wc -l; sleep 5; done

For reference, our own very large monorepo sits at ~300 file descriptors when opened. Let us know which actions make the count jump sharply (switching git branches, long agent runs, builds writing many files, etc.).

2. Check whether it still reproduces with extensions disabled - Cmd + Shift + P > Reload Window With Extensions Disabled, or cursor --disable-extensions from the terminal. That tells us if an extension is driving the growth.

Thanks again for the help!

[Tomohiro_Hiratsuka]

Hi Colin, thanks. I tested the two items you requested.

1. FD monitoring

After fully quitting and reopening Cursor, I measured the main Cursor process before and after opening a new window.

• Extensions disabled: lsof output increased from 291 to 333 lines (+42).
• Extensions enabled: lsof output increased from 307 to 349 lines (+42).
• After closing the test window: 227 numeric FDs, including 7 workspace-related FDs.

None of these actions caused a sharp increase approaching the approximately 10,000 FDs observed during the failure.

I have not yet completed longer-term monitoring involving long agent runs, builds, or Git branch switches, so I have not identified the specific long-session action that causes the FD count to grow.

2. Test with extensions disabled

I ran Developer: Reload with Extensions Disabled and opened a new window.

• The new window opened successfully.
• Crash code 6 did not occur.

I then re-enabled the extensions and repeated the test. The new window also opened successfully without a crash.

The issue is currently not reproducible with either extensions disabled or enabled. Therefore, this result does not establish whether an extension is responsible for the FD growth.

[Tomohiro_Hiratsuka]

Additional reproduction on Cursor 3.18.25:

At 10:54:33 on September 4, Cursor’s automatic update failed with “Bad file descriptor.” At 11:18:40, the main Cursor process then exited without any user action. The macOS launchd log records:

exited due to SIGTRAP | sent by exc handler
service has crashed

After manually restarting Cursor, the new main process reached the FD ceiling again within a few minutes:

• Numeric FDs: 9,999
• Maximum FD number: 9,999
• Numeric regular-file FDs: 9,915
• Files under the workspace: 9,808
• Files under /backend/nestjs/src: 9,802

This shows that the descriptors are not only accumulating gradually during a long session. Restoring the workspace after a full restart immediately reopened approximately 9,800 source-file descriptors and returned Cursor to the FD ceiling.

No new .ips report or Crashpad dump was generated for this silent crash.

For other affected users: an automatic-update failure containing “Bad file descriptor,” silent Cursor exits, and new-window code 6 crashes may all be symptoms of the same open-file-descriptor exhaustion issue.

[Colin]

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 macOS.

Could you try the following to confirm?

1. In a terminal, from the workspace folder, run this and note the number:

   find backend/nestjs/src -name '*.ts' | wc -l
   

2. Fully quit Cursor (Cmd + Q) and reopen it with the same workspace.
3. Close all editor tabs (Cmd + K, then W) so no TypeScript file is open. Wait about a minute, then note the count from:

   lsof -p "$(pgrep -x Cursor | head -1)" | wc -l
   

4. Open any .ts file under backend/nestjs/src, wait 2–3 minutes for the TypeScript service to finish loading the project, then run the same count again.

If step 4 is where the count jumps by thousands (and the number from step 1 is close to the 9,802 you saw), please add the following to your user settings (Cmd + Shift + P, then Preferences: Open User Settings (JSON)), restart Cursor, and repeat steps 3 and 4:

"js/ts.tsserver.watchOptions": {
  "watchFile": "useFsEventsOnParentDirectory",
  "watchDirectory": "useFsEvents"
}

This makes TypeScript watch folders instead of individual files. If the count stays low with that setting in place, it confirms the cause — and the setting also serves as a workaround.

Two small additional asks:

• Could you paste your backend/nestjs/tsconfig.json (or at least its include, exclude, files and watchOptions sections, if present)?
• Do you already have any typescript.tsserver.* / js/ts.tsserver.* or files.watcherExclude entries in your settings?

Please share the numbers from steps 1, 3 and 4 either way.

[Tomohiro_Hiratsuka]

Thank you. I tested this on Cursor 3.19.7.

1. Number of TypeScript files under backend/nestjs/src:

10,047

2. Relevant tsconfig.json configuration:

"include": ["src/**/*.ts", "test/**/*.ts"]

There are no exclude, files, or watchOptions entries.

Before the test, my user settings also contained no typescript.tsserver.*, js/ts.tsserver.*, or files.watcherExclude settings.

With no TypeScript file selected, the Cursor main process had:

lsof rows: 317
Files under backend/nestjs/src: 0

After opening backend/nestjs/src/main.ts, the counts increased within 20 seconds to:

lsof rows: 15,033
Files under backend/nestjs/src: 10,046
Maximum FD number: 9,999

The counts remained unchanged after three minutes. The TypeScript syntax and semantic server processes themselves each used only around 20 FDs. The approximately 10,000 source files were held by Cursor’s main process.

I then added the suggested user setting:

"js/ts.tsserver.watchOptions": {
  "watchFile": "useFsEventsOnParentDirectory",
  "watchDirectory": "useFsEvents"
}

After fully quitting Cursor, reopening the same workspace, and leaving the restored main.ts open for three minutes, the results were:

lsof rows: 272-274
Files under backend/nestjs/src: 0
Maximum FD number: 191-193

I also successfully opened a new Cursor window in this state, and no code 6 crash occurred.

For step 3, I did not close every editor tab because I wanted to preserve the existing workspace state. Instead, I measured with a non-TypeScript file selected and confirmed that there were no open FDs under backend/nestjs/src at that point.

These results appear to confirm that the TypeScript language service’s per-file watching was exhausting the Cursor main process’s file descriptors, and that the suggested setting is an effective workaround.

[Colin]

Hi @Tomohiro_Hiratsuka, thank you for running the test and posting the numbers.

That confirms it. Opening a TypeScript file makes the TypeScript language service watch every file in the project, and on macOS each of those watches currently costs the main Cursor process one open file handle. With about 10,000 files under backend/nestjs/src that hits the process limit, which is why new windows failed while existing ones kept working.

Please keep the js/ts.tsserver.watchOptions setting in place for now. It makes TypeScript watch folders instead of individual files, and there is no functional downside you should notice.

I’ve passed your measurements to the team! Thanks again for sticking with this.

[Tomohiro_Hiratsuka]

Thank you for confirming the cause and sharing the measurements with the team. I’ll keep the suggested watchOptions setting in place and watch for future updates.