Cursor agent consuming extremely high CPU

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Launch cursor, run a single request. On idle CPU is extremely high

Steps to Reproduce

Launch cursor run completion

Expected Behavior

CPU is normal

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

cursor-agent --version
2025.11.06-8fe8a63

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

2

Additional info:

image
image2552×1241 489 KB

image
image2097×1324 233 KB

This means that the GC is being triggered aggressively.

See Link: https://meta.discourse.org/discourse-ai/ai-bot/shared-ai-conversations/q9-3kQLrzS4yDWDnfsKyqQ

Particularly it could be issued by hand either by low memory notifications or if the bundled v8 in cursor agent exposes gc calls to js.

Everything seems to be happening in MainThread fwiw

(also, links are de-styled here, makes it very hard to tell if stuff is a link or not)

FWIW this is Gemini 3s theory on the issue, though I doubt it is correct.

The high CPU usage on idle, specifically dominated by V8 Garbage Collection, was caused by a memory leak in the ForkableIterable class used within a createCachedStreamExecutor
function.
Here is the diagnosis and the fix applied:

  1. The Leak: ForkableIterable (defined around line 234780 in index.js) was buffering every element from its source stream into an unbounded array this.pastElements. This is intended
    to allow new forks to replay the stream history. However, it had no mechanism to stop consuming the source or clear this buffer.
  2. The Usage: createCachedStreamExecutor (around line 156071) wrapped streams in ForkableIterable and stored them in an LRUCache. When items were evicted from the cache (due to the
    limit of 10 items), the ForkableIterable instances were not disposed. They continued to consume their source streams (if active) and grow their pastElements arrays indefinitely.
  3. The Symptom: As these “zombie” iterables grew, they consumed more memory, forcing the V8 Garbage Collector to work overtime (thrashing) to find free space, leading to high CPU
    usage even when the application appeared idle.
3

Thank you for the detailed post and for linking it from the other thread about the same issue.

1 Like