Title: Cursor reaches ~98GB memory with 6 parallel background agents — macOS memory pressure, system freeze (16GB Mac)

[xazratbek (Xazratbek Turdaliyev)]

Describe the Bug

Title: Cursor reaches ~98GB memory with 6 parallel background agents — macOS memory pressure, system freeze (16GB Mac)

Cursor version: 3.15.6
OS: macOS 26.6.1 (darwin 25.6.0, arm64)
Physical RAM: 16 GB
Layout: Agents Window (Glass)

Summary
After launching 6 parallel background agents via the Task tool in a single Composer session, Cursor memory usage grew until macOS showed an “Application Memory max” warning. Activity Monitor reported Cursor at ~98 GB (rolled-up parent + child processes). The entire Mac became sluggish and nearly unusable. I had to force-quit Cursor.

Steps to reproduce
Open Cursor 3.15.6 on macOS with 16 GB RAM
Open project: ~/programming/coding-agent (Python monorepo, 348+ tests)
Start a Composer/Agent session with a large multi-phase implementation plan
Launch 6 parallel background agents via Task tool (run_in_background: true) — e.g. P0/P1/P2/P3 integration agents working simultaneously
Agents run pytest, grep, file edits, git operations concurrently
Continue for ~30–60 minutes
Observe memory growth → macOS memory pressure warning → system freeze
Expected behavior
Memory should stay bounded; completed agent state/tool results should be released; macOS should not hit application memory limits.

Actual behavior
Cursor memory grew to ~98 GB (Activity Monitor rollup)
macOS “Application Memory max” warning
Extension hosts became unresponsive
System-wide sluggishness
Log evidence
From ~/Library/Application Support/Cursor/logs/20260812T021451/main.log:

[PowerMainService] Started wakelock id=0..4 owner=window:1 reason=“agent-loop” activeCount=1..5
(all within ~100ms at 02:14:56)
From window1_wb1/renderer.log:

Extension host (LocalProcess pid: 1092) is unresponsive. (02:26:22)
Earlier session 20260812T012415 had 13 workbench windows (wb0–wb12), indicating heavy parallel agent load.

Composer IDs from parallel sessions:

7e029830-4aeb-4ffa-a9df-11d062b64e20
7832f7e0-d475-4d52-a843-1e667ab35bcf
Models used: composer-2.5, composer-2.5-fast

Related forum threads
This appears related to known renderer/composer memory leak issues with parallel agents:

Cursor Runaway memory usage

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug The last couple of days I’ve had cases where the Cursor IDE has just runaway with massive amounts of memory usage (twice today I killed it at 100GB and 89GB, yesterday it ran up to 94GB) - needless to say my system became sluggish and unusable. This only seemed to recently start happening recently. Steps to Reproduce Using Cursor IDE (primarily Agent window) for ~4-5 hours, switching between multiple local agents working…

Renderer crashes silently when opening 4th concurrent agent session

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Opening a 4th concurrent agent session causes the Cursor renderer process to crash instantly and silently. No warning is shown, no macOS crash report is generated, and Activity Monitor shows normal memory usage at the time of the crash — ruling out system-level memory pressure. Steps to Reproduce Open 3 agent sessions (any tasks) Open a 4th agent session Renderer crashes immediately Expected behavior: The 4th session o…

Steps to Reproduce

1. Open Cursor 3.15.6 on macOS (arm64, 16 GB RAM).
2. Open a medium/large project (Python repo with tests, git, multiple source files).
3. Open Agents Window (Glass layout).
4. Start one Composer/Agent session with a large multi-phase task.
5. Launch 5–6 parallel background agents at once via the Task tool (run_in_background: true).
6. Let all agents run concurrently for 30–60 minutes (pytest, grep, file edits, git diff, etc.).
7. Watch Activity Monitor: Cursor memory keeps growing.
8. Eventually macOS shows “Application Memory max” warning; system becomes sluggish.
9. Extension hosts become unresponsive; Cursor may show “JavaScript error in main process: write EPIPE”.
10. Force-quit Cursor when memory reaches ~90–98 GB (Activity Monitor rollup).

Operating System

MacOS

Version Information

Version: 3.15.6
VSCode Version: 1.128.0
Commit: d5c0e77a0214208f36b56d42e8e787de88d02ea4
Layout: glass (Agents Window)
Build Type: Stable
Release Track: Default
Electron: 40.10.3
OS: Darwin arm64 26.6.1 (Build 25G76)
Physical RAM: 16 GB

Additional Information

Launched 5–6 parallel background agents via Task tool in one Composer session. Activity Monitor showed Cursor at ~98 GB. macOS “Application Memory max” warning, system freeze.
Relevant logs (main.log + renderer.log, redacted — no paths/emails):

2026-08-12 02:14:53.799 [info] [LocalAgentStorage] Scanned 4 recent databases (skipped 0 old), found 79 agent headers, deduped to 79
2026-08-12 02:14:56.176 [info] [PowerMainService] Started wakelock id=0 owner=window:1 reason="agent-loop" activeCount=1
2026-08-12 02:14:56.210 [info] [PowerMainService] Started wakelock id=1 owner=window:1 reason="agent-loop" activeCount=2
2026-08-12 02:14:56.237 [info] [PowerMainService] Started wakelock id=2 owner=window:1 reason="agent-loop" activeCount=3
2026-08-12 02:14:56.262 [info] [PowerMainService] Started wakelock id=3 owner=window:1 reason="agent-loop" activeCount=4
2026-08-12 02:14:56.285 [info] [PowerMainService] Started wakelock id=4 owner=window:1 reason="agent-loop" activeCount=5
2026-08-12 02:15:06.098 [info] [CursorProclistService] Config enabled feature (subsample every 10s; memoryPressureMonitorEnabled=true)
2026-08-12 02:14:56.187 [info] [ComposerWakelockManager] Acquired wakelock id=0 reason="agent-loop" composerId=8be71ec7-7490-42ec-8d1a-58ca41775402
2026-08-12 02:14:56.214 [info] [ComposerWakelockManager] Acquired wakelock id=1 reason="agent-loop" composerId=e9e639c5-305d-4e4e-ad9a-a654aebee861
2026-08-12 02:14:56.240 [info] [ComposerWakelockManager] Acquired wakelock id=2 reason="agent-loop" composerId=91effc56-b127-41bd-9119-40b3f1f44959
2026-08-12 02:14:56.265 [info] [ComposerWakelockManager] Acquired wakelock id=3 reason="agent-loop" composerId=1260f4a2-c341-4afa-87e1-ffd7ec6f2fa4
2026-08-12 02:14:56.287 [info] [ComposerWakelockManager] Acquired wakelock id=4 reason="agent-loop" composerId=552bd20a-1ce7-4830-8b4f-e31d83d1001f
2026-08-12 02:14:59.742 [info] [buildRequestedModel] catalogModelId=composer-2.5 composerModelName=composer-2.5 maxMode=false
2026-08-12 02:14:59.755 [info] [buildRequestedModel] catalogModelId=composer-2.5 composerModelName=composer-2.5-fast maxMode=false
2026-08-12 02:15:58.658 [info] [PowerMainService] Stopping wakelock id=3 owner=window:1 reason="agent-loop" heldForMs=62396
2026-08-12 02:16:42.442 [info] [PowerMainService] Stopping wakelock id=1 owner=window:1 reason="agent-loop" heldForMs=106231
2026-08-12 02:21:28.278 [info] [PowerMainService] Stopping wakelock id=0 owner=window:1 reason="agent-loop" heldForMs=392102
2026-08-12 02:26:22.209 [info] Extension host (LocalProcess pid: 1092) is unresponsive.
2026-08-12 02:26:26.909 [info] Extension host (LocalProcess pid: 1091) is unresponsive.

### Does this stop you from using Cursor
Yes - Cursor is unusable

[mohitjain (Mohit)]

Hey there!
This is something we’ve seen before and an issue we’re tracking - running several long background agents at once in the Agents Window makes memory climb without a firm ceiling, and on a 16GB Mac that tips into memory pressure fast. It’s not anything wrong with your setup.

Quick note: Activity Monitor rolls all child processes into the single “Cursor” entry, so ~98GB is the combined total, not one runaway process.

To keep it under control:

1. Cap concurrent background agents to 2-3 - six on 16GB is a lot, and each spawns its own child processes.
2. Reload the window during long sessions: Cmd+Shift+P → Developer: Reload Window.
3. Fully quit with Cmd+Q between heavy batches.
4. Close/archive finished agent conversations rather than leaving them all open.

If it still climbs after capping concurrency, a Process Explorer screenshot at the spike (Cmd+Shift+P → Developer: Open Process Explorer) showing the largest process type would help.

[Mariano_Sorgente]

I’m curious what that memory is storing if the context is only 1M tokens?