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

发生场景

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

问题

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.

报错原文（已脱敏/规范化）

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

适用环境

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.

如何确认是这个问题

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.

不是这个问题时 / 边界

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

根因

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

修复步骤

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

如何验证

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

试过没用的办法

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

风险提示

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

验证范围

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

何时失效

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