Recurring renderer memory leak during long-running agent workflows in Editor layout

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor repeatedly becomes severely laggy or unresponsive during long-running agent workflows.

These workflows typically run for 60–90 minutes and follow a multi-stage pipeline defined in a command and using pre-defined agents at each step:

  • Brainstorm
  • Implement
  • Review
  • Finalize

Each stage may use several subagents. The agents also create multiple Git branches, commit changes, and switch between branches while working.

The affected process is consistently the workspace’s renderer—not an extension host, terminal, test process, or language server. Renderer memory grows without being reclaimed, macOS begins swapping heavily, and CPU usage rises to several hundred percent.

This has recurred across separate Cursor launches, so it is not one renderer process remaining from an earlier incident.

Steps to Reproduce

The issue is not instantaneous, but this usage pattern has triggered it repeatedly:

  1. Open a repository in the classic Editor layout.
  2. Start an agent workflow expected to run for 60–90 minutes.
  3. Have the workflow use multiple subagents across Brainstorm, Implement, Review, and Finalize stages.
  4. Allow agents to create, commit, and switch between multiple Git branches.
  5. Continue using the same conversation while the workflow performs many file reads, edits, diffs, tool calls, and Git operations.
  6. Eventually, the workspace becomes increasingly laggy and then effectively unresponsive.

Expected Behavior

Long-running agent and subagent workflows should have bounded renderer memory usage.

Completed tool calls, file context, diff state, subagent results, and previous workflow stages should be released or persisted without remaining indefinitely in the renderer heap. Git branch creation and switching should not cause renderer state to accumulate without bounds.

If memory pressure becomes excessive, Cursor should degrade gracefully or reload the affected surface rather than consuming more than 17 GB and causing system-wide swap pressure.

Operating System

MacOS

Version Information

Version: 3.12.17
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 24.6.0

Additional Information

Two observed incidents:

Incident 1

  • Renderer CPU: approximately 700%
  • Renderer physical footprint: 17.6–17.8 GB
  • Swapped memory: approximately 15.3 GB
  • Extension hosts remained comparatively healthy
  • Stopping the active chat reduced CPU to near zero, but the renderer retained approximately 17.7 GB

Incident 2
This happened again after Cursor had been fully restarted:

  • Renderer CPU: sustained 610–640%
  • Renderer physical footprint: 17.6 GB
  • Swapped memory: approximately 14.9 GB
  • Cursor’s RendererPing reported the window blocked continuously for more than 345 seconds
  • Available system memory reached 0.2%
  • File-watcher events began being dropped under the resulting resource pressure
  • Another workspace’s renderer remained healthy at approximately 480 MB, isolating the problem to the workspace running the long agent workflow

The logs showed an agent loop being resumed without a corresponding completion/release event before the renderer became blocked.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. The metrics, narrowing it down to a specific workspace, and the steps really help.

This is a known class of bugs. During long agent sessions, the renderer keeps completed tool call state in memory, like file contents before and after, diffs, and it doesn’t release it. Streaming updates during large edits also hits CPU. That’s why you see the growing footprint, swap, and an unresponsive window. We’re tracking the issues on our side, but I can’t share an ETA for a fix yet.

What helps right now:

  • Split a long pipeline into a few shorter chats. Use a separate conversation per stage like Brainstorm, Implement, Review, Finalize instead of one 60 to 90 minute thread. The main driver is how much tool state builds up in a single conversation.
  • If the renderer has already ballooned, the only way to get memory back today is to reload the window: Cmd+Shift+P then Developer: Reload Window. You don’t need a full restart for this.

If memory still climbs to the same 17+ GB even after splitting into shorter chats, reply here and I’ll take another look.

7

Is there a way to automate that? Being able to define a spec and run a command to handle this workflow while I get lunch or go to the gym is pretty smooth; if I need to manually copy-paste the results of each stage into the next one, then I’m really losing a lot of the benefit of the system.

8

I encountered the issue again today, but this instance didn’t occur during a long 60–90 minute agent run.

The triggering conversation was relatively short. The model was analyzing two SQLite database files and executed some heavy reads that may have returned a large volume of data. There were not many individually rendered tool calls, so this suggests that total tool-result payload size—not only conversation length or tool-call count—may trigger the problem.

It didn’t trigger immediately after those tool calls, but it seems possible those increased the overall background memory usage.

A couple important notes:

  1. The Developer > Reload Window path does not work. I can open the Command Palette and select the command, but the application never executes it. Cursor also cannot be closed normally at that point. The only recovery available is to force-quit Cursor and reopen the application.
  2. Canvas Artifacts could be implicated. This time it froze up when I was scrolling through a canvas artifact produced by the conversation. The canvas artifact was relatively simple compared to many I’ve seen it produce in the last month, but the hanging occurred shortly after I had begun scrolling through it and a couple minutes after the last agent message had went through, so the timing seems noteworthy. I did have that canvas open while the agent was making updates to it previously, and it did make 3-5 updates to that canvas over the course of the conversation, so it seems possible that something about having open canvas’ while the agent makes edits to them could be connected to the underlying issue.

Overall, it seems like this is happening more often then in just the long conversation case.

Updated diagnostics for this incident:

  • Cursor version: 3.12.30
  • Layout: classic Editor, not Agents Window
  • Affected process: workspace renderer
  • Physical footprint: 18.4 GB
  • Swapped memory: 16.9 GB
  • CPU: sustained approximately 435–574%
  • Cursor reported the renderer blocked continuously for at least 275 seconds
  • Another workspace renderer remained healthy at approximately 424 MB
  • The final agent generation ended around 14:15
  • Renderer blocking began around 14:17, meaning the runaway continued after agent execution completed
9

Thanks for the updates. Both posts were helpful, and the note about payload size was especially useful.

About automating the split-up work post 7. You don’t need manual copy-paste between stages, but there are a couple options that reduce accumulation without losing the run it and walk away flow:

  • Subagents. Each subagent runs in its own context window, and its noisy intermediate output like big reads, search, DOM, logs stays inside the subagent. Only a final summary comes back to the main chat. If you delegate heavy operations like those SQLite reads to a subagent Explore/Bash or a custom one, the large payloads won’t pile up in the main chat state. More details: Subagents | Cursor Docs
  • Cloud or Background Agents. If the goal is to define the spec and run the pipeline while you’re at lunch or at the gym, it’s worth running it as a Cloud Agent. It runs on a remote machine, so the local renderer doesn’t become the bottleneck. This is probably the closest match to your scenario: Cloud Agents | Cursor Docs

About post 8. Your conclusion that it’s the total tool-result payload size that triggers it, not just the conversation length, is correct. That matches what we’re tracking. Heavy reads like SQLite can increase the footprint even in a short chat.

Two clarifications:

  1. Reload Window not working is unfortunately expected when the renderer is already fully stuck and the system is actively swapping. The palette opens, but the blocked main thread can’t process the command. In that state, force-quit really is the only way to recover. The key is to reload the window before the footprint hits the ceiling, not after.
  2. Canvas is an interesting signal, thanks. Can you check if the freeze reliably reproduces when you scroll a canvas that the agent edited during the session? For example, open that canvas and scroll a couple minutes after the agent’s last message. If the correlation is consistent, that’s a separate lead, and with clear steps I can dig deeper.

We’re tracking issues for the main class of this on our side. I can’t share an ETA for a fix yet. Once you have more canvas data, reply here.