Cursor 3.24 on macOS quits several times a day: main-process V8 heap out of memory (`Ineffective mark-compacts near heap limit`) from the startup worktree cleanup

Context

Source(s): https://forum.cursor.com/t/main-process-not-renderer-crashes-with-v8-heap-oom-at-4-gb-on-macos-3-24-9-and-3-24-12-heap-climbs-silently-5-9-mb-s-after-launch/174308 Signal: 94 views; staff answer accepted and confirmed the cause (October 2026). Status: reported working by source, not reproduced by us (workaround only; root fix not confirmed).

Problem

The whole Cursor app exits. The crash report is for the Electron main process (event.process: browser), not a renderer. After a normal start at about 100–450 MB, the main process heap climbs about 5–9 MB per second at 60–90% CPU with no agent running, until it hits the 4 GB limit; 9 of the original poster's last 10 launches began with an out-of-memory report from the previous run.

Error (redacted / normalized)

v8-oom (event.process: browser): Ineffective mark-compacts near heap limit
heap limit 4,096 MB, heap used 3,994 MB (97.5%)

Applies when

Cursor 3.24.9 and 3.24.12 on macOS 26.6.2 (Apple Silicon, 48 GB RAM); one very large monorepo with about 20 git worktrees, some under Cursor's managed worktrees folder.

Confirm it is this problem

1. Check the Cursor logs. → expect: every session logs WorktreeCleanupMainService ... Granted cleanup lease ... reason="startup-catchup-worktree-cleanup" and never logs the lease being released.
2. Sample the main process while memory climbs (the original poster used macOS sample; Activity Monitor > Sample Process gives the same view, our inference). → expect: libuv worker threads busy in stat / open / getdirentries, i.e. a directory walk.

Not this when / boundary

The crash report names a renderer process rather than the main (browser) process, or the worktree cleanup lease line is absent; then it is a different memory problem (our inference).

Root cause

Per Cursor staff: the automatic worktree cleanup measures the size of each Cursor-managed worktree by walking every file in it (everything except .git), and that walk has no upper limit. With very large worktrees it exhausts the main process's memory, and because the run never finishes, it starts again on the next launch (the original poster found the cleanup reruns whenever the last completed run is older than the cleanup interval, 6 hours by default).

Fix

1. Add to your user settings.json: "cursor.worktreesGlobalMaxSizeGb": 0, and "cursor.worktreeCleanupIntervalHours": 500 (0 turns the size cap off, so the size walk is skipped). → expect: the original poster's main process then stayed at about 65 MB (peak 227 MB at startup) with about 0% CPU, 8+ minutes after launch, where 3.24.12 had already passed 500 MB and was climbing.
2. Restart Cursor. Staff said a downgrade is not needed because the cleanup code is the same in 3.23 and 3.24 and the settings are what fixed it. Note: the original poster's result was measured after also downgrading to 3.23.23; they did not report trying 3.24 with only the settings.
3. Clear out old, large worktrees under ~/.cursor/worktrees that you no longer need (staff: with the size limit off, Cursor still keeps at most 25 managed worktrees and measures each one it removes).

How to verify

The main process's memory stays flat after launch and the app no longer quits with a main-process out-of-memory report.

What did not work

Archiving chats did not help (1,277 of about 1,950 already archived); system memory was not the limit (from the original poster).

Risks

Don't set cursor.worktreeCleanupIntervalHours above about 596 hours (the 32-bit timer limit): the schedule then fires immediately and loops; the original poster got about 200 cleanup runs per second with 100000. 500 is safe (original poster; staff flagged the loop to the team). If you also set "update.mode": "none" to stop auto-updates, remove it afterwards so you keep getting updates (staff).

Verified scope

Cursor 3.23 and 3.24 (staff: same cleanup code) with large Cursor-managed worktrees, October 2026; reported on macOS.

Becomes obsolete when

A Cursor release that bounds or moves the worktree size walk out of the main process.