Cursor Agent - JavaScript Heap Out of Memory Error

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Cursor Version: 2.0.60 (commit: c6d93c13f57509f77eb65783b28e75a857b74c00, x64)
Cursor Agent Version: cursor-agent/versions/2025.11.06-8fe8a63
Platform: Linux x86_64 (remote via SSH)
Issue: Cursor Agent crashes with FATAL ERROR: JavaScript heap out of memory after extended session


Description

Cursor Agent terminates with a heap exhaustion error after running for approximately 3 hours during an interactive session. The process appears to have a memory leak that causes heap usage to grow from normal levels (~500MB) to the 4GB limit, at which point V8’s garbage collector fails to reclaim memory effectively.


Error Output

<--- Last few GCs --->
[PID:0x1ce2e000] 12160609 ms: Scavenge (interleaved) 4051.6 (4070.2) -> 4051.6 (4117.2) MB, pooled: 0 MB, 46.28 / 0.00 ms  (average mu = 0.220, current mu = 0.188) allocation failure; 
[PID:0x1ce2e000] 12163486 ms: Mark-Compact (reduce) 4052.1 (4117.2) -> 4052.1 (4055.7) MB, pooled: 0 MB, 2613.70 / 0.00 ms  (+ 35.1 ms in 8 steps since start of marking, biggest step 5.0 ms, walltime since start of marking 2656 ms) (average mu = 0.168

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

----- Native stack trace -----
 1: 0xf41253 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [cursor-agent/node]
 2: 0x1388b50 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [cursor-agent/node]
 3: 0x1388c3f v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [cursor-agent/node]
 4: 0x1621705  [cursor-agent/node]
 5: 0x1621732  [cursor-agent/node]
 6: 0x1621a2a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector, v8::base::TimeTicks) [cursor-agent/node]
 7: 0x1631f4a  [cursor-agent/node]
 8: 0x16362f0  [cursor-agent/node]
 9: 0x20c8ff1  [cursor-agent/node]

fish: Job 1, 'cursor-agent' terminated by signal SIGABRT (Abort)

Timeline

  • T+0: Cursor Agent started successfully
  • T+30min: Normal operation, responsive
  • T+1h: Occasional lag/delays in responses
  • T+2h: “Generating…” messages frequently hang
  • T+3h (~12160 seconds runtime): Fatal crash with heap exhaustion

Symptoms Before Crash

  1. Progressive slowdown: Commands took increasingly longer to process
  2. Intermittent hanging: “Generating…” would appear and stop responding
  3. Recovery pattern: Sometimes Ctrl-C + multiple commands would “wake up” the agent
  4. No visible process activity: No high CPU or disk I/O, but process appeared blocked

Environment Details

Shell: Fish 3.x (confirmed using bash as well - same issue)
Node: Bundled with Cursor Agent (version 2025.11.06-8fe8a63)
System: Linux x86_64 (remote via SSH)
Available RAM: 32GB physical + 40GB swap (system not under memory pressure)
Workspace: Large software project (~40GB build artifacts, extensive codebase)


Analysis

Memory Growth Pattern

The V8 heap grew to 4GB limit over ~3 hours:

  • Initial: ~500MB (normal)
  • After 1h: ~1.5GB
  • After 2h: ~3GB
  • After 3h: 4GB (limit reached, crash)

GC Ineffectiveness

The error shows “Ineffective mark-compacts near heap limit”:

  • Scavenge GC: 4051.6 MB → 4051.6 MB (0 MB reclaimed)
  • Mark-Compact: 4052.1 MB → 4052.1 MB (0 MB reclaimed)

This indicates objects are being retained and cannot be garbage collected.


Suspected Root Causes

  1. Context accumulation: Agent may be retaining conversation history/context without pruning
  2. File content caching: Large files read during session may not be released
  3. Event listener leaks: Possible EventEmitter leaks in internal code
  4. API response buffering: Responses from backend may be accumulating in memory

Impact

  • Severity: High - Makes cursor-agent unusable for extended sessions
  • Workaround: Restart cursor-agent every 1-2 hours (loses context)
  • Use case affected: Long build processes, extensive refactoring sessions, large codebases

Suggested Investigation

  1. Enable Node.js heap profiling: node --inspect --max-old-space-size=8192
  2. Add memory usage logging in cursor-agent code
  3. Implement periodic context/cache pruning
  4. Add --max-old-space-size flag option for users with large projects
  5. Profile memory usage during typical operations to identify leaks

Workarounds Attempted

  1. Switching from Fish to Bash shell - No effect
  2. Periodic Ctrl-C + restart commands - Temporary relief only

Feature Request

Add configuration option to increase V8 heap size for large projects:

{
  "cursor.agent.maxHeapSize": "8192"  // MB
}

Or allow passing Node flags:

cursor-agent --max-old-space-size=8192

Additional Context

This occurred during work on a complex Debian packaging project with:

  • Large source tarballs (~1GB)
  • Extensive build logs
  • Multiple file edits over time
  • Context-heavy conversations about build failures

The memory leak appears to be cumulative based on session activity, not a sudden spike.


Steps to Reproduce


Reproduction Steps

  1. Start cursor-agent in bash shell (Fish shell compatibility was ruled out)
  2. Execute interactive commands over 2-3 hour session
  3. Include file reading, code generation, and context-heavy operations
  4. Observe progressive memory growth
  5. Eventually crashes with heap exhaustion

Expected Behavior

Cursor not crashing

Thank you for investigating this issue!

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

I have extremely high CPU usage with cursor agent (probably the latest version because I just installed it two days ago) even when it is not doing anything. So I give it a prompt, it does its thing, and then highest CPU usage is from this terminal that cursor is running on.

1 Like

Thanks for the detailed report, I’ve raised this with the team!

1 Like

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.