macOS OOM: Cursor paused at 14GB / took down 16GB Mac during concurrent /ship agent fleets + file_service disk writes

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Jul 25, 2026 ~09:12–09:17 EDT, Cursor exhausted system memory and macOS showed Force Quit Applications: “Your system has run out of application memory.” Cursor was listed as “Cursor (paused): 14.06 GB” on a 16 GB MacBook Air (Mac15,12). The machine became unusable until Cursor was force-quit. Tweeted at 09:17; Cursor restarted at 09:18 (new log session 20260725T091805).

Root-cause investigation (local logs + macOS diagnostics, data sharing on):

  1. Long-lived Cursor process: log session 20260724T111934 ran ~22h (Jul 24 11:19 → Jul 25 ~09:12).
  2. Immediate trigger: concurrent agent-loop wakelocks peaked at activeCount=5 at 09:12:15 while multiple Max Mode Grok-4.5 agents//ship review fleets were running (29 subagent transcripts created 08:00–09:20). Composer IDs near crash include 5837c86f-…, 7493a457-…, c04badad-…, 46d64fd5-….
  3. Cascading failure under memory pressure: FSEvents file-watcher drops, Extension host unresponsive, WorkspaceResolutionTimeoutError, and spawn /bin/zsh ENOENT + spawn /usr/bin/git ENOENT in renderer logs.
  4. Strong contributing factor — Cursor Helper (Plugin) / file_service.darwin-universal.node disk-write diagnostics:
    • Overnight: ~2.15 GB dirty writes
    • Morning spike 05:42–06:09: ~8.59 GB dirty writes in ~1574s (~5.5 MB/s)
      Incident IDs: 8402CCB5-3791-4895-B9AA-F8DAC5717BCE, 52D00DE4-3823-408D-ACB7-EB0102526B72
  5. Environment amplifiers: ~19 workbench windows in one session, ~22 git worktrees, Podman Desktop also ~4.5 GB at Force Quit time.

This looks like unbounded memory growth / insufficient backpressure when many parallel agents + filesync run on a 16GB machine — not a clean Electron crash (no Cursor .ips crash report; process was paused by macOS memory pressure).

Steps to Reproduce

Hard to force in one click, but the failure mode reproduced under this workload:

  1. Leave Cursor IDE running for a long session (here ~22 hours) with many agent chats/worktrees open.
  2. Run heavy parallel agent work — e.g. /ship which fans out many review subagents — while other agent loops are also active (wakelock activeCount climbing to 4–5).
  3. Have Filesync/file_service active across multiple worktrees (here ~22).
  4. On a 16 GB Mac, watch memory climb until macOS shows “Your system has run out of application memory” with Cursor paused at ~14 GB.

I can share sanitized log excerpts + session IDs (data sharing is on).

Expected Behavior

Cursor should either (a) bound memory / agent concurrency / filesync write pressure so it cannot consume nearly all system RAM, or (b) degrade gracefully (pause agents, shed caches) before macOS jetsams/pauses the whole app and freezes the machine. A single IDE session should not take down a 16 GB Mac.

Operating System

MacOS

Version Information

IDE: Cursor
Version: 3.13.10
VSCode Version: 1.128.0
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Quality: stable
OS: macOS 26.5.2 (Build 25F84)
Hardware: Mac15,12 (MacBook Air), arm64, 16 GB RAM, 8 CPU
machineId: 1717933a7e024a7329d8fdd6540e170a89da4156bb906ed0c00e51d4ecae60cc
macMachineId: cdb4e8c1422e4f7acccf3f0c6fc35184ae8bfba69b763225eb0f4237fbae12db
devDeviceId: f0c6dc43-5a54-47cf-a002-007e8e495379
Log session (crash): 20260724T111934
Log session (restart): 20260725T091805

For AI issues: which model did you use?

Grok 4.5 (Max Mode) — multiple concurrent agent loops / subagents at crash time

For AI issues: add Request ID with privacy disabled

Session / composer IDs near crash (data sharing ON — please pull these):

  • 5837c86f-6f39-4360-97c0-a94b30c8e169 (/ship UI changes + many parallel subagents)
  • 7493a457-7824-4610-b24d-3078da318e38 (janitor skill / worktree)
  • c04badad-928a-4652-9fd7-92feb1740ede (~09:11)
  • 46d64fd5-fe62-4ee9-a48c-2618a52cf011 (wakelock at 09:12:15 when activeCount hit 5)
  • 6f9fc9b5-ec82-45d9-8430-23e4f95281b1
  • d94c837a-2ce1-4cc4-b5d2-1b9878fdd6ca
  • b976c57e-3f4d-4aee-b9ac-f3a1e55f3a19

Plugin disk-write incidents:

  • 8402CCB5-3791-4895-B9AA-F8DAC5717BCE
  • 52D00DE4-3823-408D-ACB7-EB0102526B72

Additional Information

Reproducible trigger skill: the concurrent agent fan-out came from my public /ship skill (step 6: Review with parallel agents — light ~5-7 Tasks / full ~11-12). Source: agent-skills/skills/ship at main · jsolly/agent-skills · GitHub (see also references/agent-fleet.md). User-authored workload that stresses multi-agent concurrency; Cursor still should not OOM the machine.
Public X report (Cursor employee Tibor @tibor_tee asked for email to [email protected]): John Solly on X: "Ruh-roh! @cursor_ai crashed my computer. The stability/quality of Cursor has gone down considerably. Will add this to my bug reports. Looks like a memory leak. https://t.co/h4SqyARWti" / X

Sanitized logs (attached)

cursor-oom-report-20260725.zip (9.7 KB)

Sanitized log excerpts (paths redacted to ~):

2026-07-25 09:11:33.630 [info] [PowerMainService] Started wakelock ... activeCount=4
2026-07-25 09:12:15.590 [info] [PowerMainService] Started wakelock ... activeCount=5
2026-07-25 09:12:15.648 [info] [ComposerWakelockManager] Acquired wakelock ... composerId=46d64fd5-fe62-4ee9-a48c-2618a52cf011
2026-07-25 09:14:18.987 [info] Extension host (LocalProcess pid: 65220) is unresponsive.

Also: WorkspaceResolutionTimeoutError, FSEvents Events were dropped, spawn /usr/bin/git ENOENT and spawn /bin/zsh ENOENT under pressure.

file_service.darwin-universal.node disk-write diags (macOS):

  • 2.15 GB overnight writes
  • 8.59 GB in ~26 min (05:42-06:09)
  • Continued through 08:22 (incident 9C73F671-4E21-4602-995E-BB2AFB7201A2)

Full sanitized zip also emailed to [email protected]. Account: [email protected] (Ultra). Data sharing on.

Related forum posts

Same class of failure (agent concurrency / long sessions / macOS memory pressure). Keeping this as a separate report because of the specific fingerprint: system-level OOM with Cursor paused at ~14 GB on 16 GB RAM, wakelock activeCount=5, and large file_service dirty-write diagnostics.

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hey @jsolly,

This is a known class we’re actively working on, and you’re right: a single session shouldn’t be able to push a 16 GB Mac into system-wide memory pressure. There’s currently no cap on concurrent local agent loops and no graceful shedding as memory climbs - that’s the direction we’re fixing, no ETA yet.

Biggest levers on 16 GB while that lands:

  • Run fewer agents at once - the /ship fan-out (~5–12 parallel) on top of other active loops is a lot of concurrent state for 16 GB; the lighter review tier, not overlapped with other runs, helps most.
  • Reload/restart on long sessions - 22 h uptime + 19 windows accumulates state. Cmd+Shift+P → Developer: Reload Window on heavy windows before it balloons (once it’s swapping, only force-quit works).
  • Trim worktrees - ~22 active worktrees drives a lot of background indexing/filesync; close the ones you’re done with.
  • Offload the heavy fan-out to Cloud Agents (runs off your machine) or subagents (isolated context).

The Cursor Helper (Plugin) disk-write numbers you captured are the piece I most want to pin down. Two things would help a lot next time it climbs:

  1. A whole-process-tree spindump while it’s happening: sudo spindump -o /tmp/cursor-spindump.txt (single file, best artifact).
  2. A rough before/after - do those disk-write numbers drop noticeably when you’re running fewer worktrees? That tells us whether the write volume scales with worktree count.

Feel free to email either to [email protected] like before. If capping concurrency + restarting between runs doesn’t cut the frequency, reply here and I’ll dig back in.

8

@mohitjain Follow-up from a live snapshot (2026-07-30 ~05:20 EDT) — different fingerprint than the Jul 25 OOM.

This time it’s the renderer, not Plugin/file_service.

Snapshot

  • Cursor Helper (Renderer) PID 35952 — ~4.3–4.5 GB phys footprint (main window, renderer-client-id=4, ~9.5h uptime)

  • Cursor main — ~1.0 GB

  • ~6 extension hosts still alive — ~2.2 GB combined App Memory

  • All Cursor processes ≈ 9.1 GB App Memory (~30 processes)

  • Co-resident krunkit (Podman) ~4 GB — not Cursor, but eats headroom on this 16 GB MBA

  • System at capture: ~86 MB free, heavy compressor / swap pressure (full memory_pressure + vm_stat + top in attachment)

Agent concurrency was low

  • PowerMainService wakelock activeCount = 1–2 this morning (not the Jul 25 peak of 5)

  • No /ship fan-out during this snapshot

  • So this climb is not explained by concurrent agent fan-out alone

Ambient state still heavy

  • Log session 20260729T195210 (Cursor 3.13.25, commit 31e8d61…)

  • 42 window1_wb* folders under that session’s logs

  • Extension hosts still up for multiple workspaces incl. two Agents Window hosts

  • Still ~22 git worktrees under ~/code/.worktrees

  • Renderer log at 04:57: [MemoryMonitor] Triggering emergency heap profile: 2197MB (53.7% of limit) — then same renderer continued to ~4.5 GB

  • state.vscdb on disk is 11 GB (+ ~4.4G backup + ~4.7G archive)

Your Plugin disk-write / spindump asks

This climb was renderer-dominated, so I do not have fresh file_service dirty-write GB numbers for this morning. The Jul 25 Plugin numbers from the OP still stand (~2.15 GB overnight, ~8.59 GB spike 05:42–06:09, incident IDs in OP / attachment).

Status on the two artifacts you asked for:

  1. Spindump (sudo spindump -o /tmp/cursor-spindump.txt) — not captured during this climb (needs sudo while it’s climbing). I’ll grab a whole-process-tree spindump on the next climb.

  2. Worktree before/after on Plugin disk-writes — not run yet. Still ~22 worktrees at this snapshot. I’ll prune finished ones and compare whether Plugin dirty-write volume drops on the next climb.

Attachment

cursor-renderer-oom-followup-20260730.zip (paths redacted):

  • 00-summary.txt

  • 01-memory-monitor-and-wakelocks.txt

  • 02-renderer-footprint.txt

  • 03-process-list.txt

  • 04-hosts-and-watchers.txt

  • 05-worktrees.txt

  • 06-system-resources.txt (hardware, memory_pressure, vm_stat, top)

  • 07-plugin-diskwrite-status.txt (explicit status on your two asks)
    cursor-renderer-oom-followup-20260730.zip (13.0 KB)