# Cursor Agent - JavaScript Heap Out of Memory Error

**URL:** <https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396>\
**Category:** Bug Reports\
**Tags:** cli\
**Created:** [November 6, 2025, 2:05pm UTC](https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396 "2025-11-06T14:05:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![vejeta](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/vejeta/32/86217_2.png) [@vejeta](https://forum.cursor.com/u/vejeta)\
**Post date:** [November 6, 2025, 2:05pm UTC](https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396/1 "2025-11-06T14:05:42Z")

</div>

### 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

```auto
<--- 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:

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

```

Or allow passing Node flags:

```bash
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

---

<div class="post-metadata">

**Author:** ![Muhammad\_bin\_Yusrat](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/muhammad_bin_yusrat/32/86354_2.png) [@Muhammad\_bin\_Yusrat](https://forum.cursor.com/u/Muhammad_bin_Yusrat)\
**Post date:** [November 7, 2025, 10:27am UTC](https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396/2 "2025-11-07T10:27:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sanjeed5](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/sanjeed5/32/9610_2.png) [@sanjeed5](https://forum.cursor.com/u/sanjeed5)\
**Post date:** [November 7, 2025, 11:27am UTC](https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396/4 "2025-11-07T11:27:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\
**Post date:** [November 29, 2025, 11:27am UTC](https://forum.cursor.com/t/cursor-agent-javascript-heap-out-of-memory-error/141396/5 "2025-11-29T11:27:56Z")

</div>

Closed on November 29, 2025, 11:27am UTC

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