Renderer crash (code: 5) every ~90s on macOS Tahoe 26.3 with large workspace

[asahagun (Alexis)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s renderer process crashes with code: 5 approximately every 90-100 seconds after opening a large workspace (~4.8GB monorepo with multiple node_modules
directories). No user interaction is needed — simply opening the workspace triggers the crash consistently.

The crash is caused by a Chromium/Electron incompatibility with macOS 26.3 Tahoe. Crashpad logs show mach_vm_read(0x16b2b8000, 0x8000): (os/kern) invalid address
(1) from process_memory_mac.cc, indicating invalid kernel memory access during file indexing.

Tested all of the following — none fixed it: clean cache, reinstall Cursor, --disable-gpu, --no-sandbox, disable-hardware-acceleration, disable-crash-reporter,
CRASHPAD_DISABLE=1, --max-old-space-size=8192, disabling all MCP servers, clearing all composer/agent session data.

What does NOT crash: opening Cursor with no workspace (stable 3+ min), or opening only a subfolder (~1GB) instead of the full monorepo (stable 3+ min).

Separate issue: cursor-socket extension ships broken in v2.6.12 — missing out/ directory entirely (Error: Cannot find module ‘…/cursor-socket/out/main’).

Steps to Reproduce

1. Use macOS 26.3 Tahoe (arm64)
2. Open a ~4.8GB workspace containing multiple node_modules directories (~2.4GB total)
3. Wait ~90 seconds without doing anything
4. Renderer crashes: CodeWindow: renderer process gone (reason: crashed, code: 5)
5. Click “Reopen” → crashes again at ~90s. 100% reproducible.

macOS 26.3 Tahoe (Build 25D125), Apple Silicon arm64, 18GB RAM

Expected Behavior

Cursor should open and remain stable with large workspaces, as VS Code handles 10GB+ monorepos without issues on the same machine and OS.

Operating System

MacOS

Version Information

Cursor v2.6.12 (Chromium 142.0.7444.265)

For AI issues: which model did you use?

Crashes 90s after starting without any action from the user.

Additional Information

Workaround: Open subfolders instead of the monorepo root. This avoids the
crash entirely.

The crash appears tied to the file indexing phase — it happens at a consistent
~90s mark regardless of GPU, sandbox, or crash reporter settings. Only
reducing workspace size prevents it.

Does this stop you from using Cursor

Yes - Cursor is unusable

[Jacob_Bijani]

same behavior here. started happening for me on latest update

[deanrie]

Hey, thanks for the detailed report.

This is a known issue. Renderer crash (code 5) has been reported by multiple users on macOS ARM64 since the 2.6.x updates. You can see a related thread here: Cursor keeps crashing - 2.6.11. The team is aware and tracking it, but there’s no ETA yet. Your report helps with prioritization, especially since the Crashpad log pointing to mach_vm_read and process_memory_mac.cc narrows this down to a Chromium or Electron level issue on macOS.

I can see you’ve already tried pretty much every troubleshooting step. A couple of things that helped other users in similar cases:

1. Clear local databases. One user in the related thread said this fixed the crash:

   # Quit Cursor completely first
   rm -rf ~/Library/Application\ Support/Cursor/IndexedDB
   rm -rf ~/Library/Application\ Support/Cursor/Local\ Storage
   rm -rf ~/Library/Application\ Support/Cursor/Session\ Storage
   rm -rf ~/Library/Application\ Support/Cursor/GPUCache
   rm -rf ~/Library/Application\ Support/Cursor/User/index
   

2. Downgrade to 2.5.26 as a temporary workaround. Several users confirmed the crashes don’t happen on that version.

3. Your subfolder workaround is also valid and might be the least disruptive option for now.

About the cursor-socket missing out/ directory, we’re seeing this on other 2.6.x builds too. It’s a bundling issue on our side.

If you can share the main.log file (Help > Open Logs Folder) from around the time of a crash, that’d be helpful to pass to engineering.

Let me know how it goes.