Cursor IDE is experiencing severe memory leaks in the chat/composer system that cause the extension host to crash and restart repeatedly. The listener count grows exponentially (180 → 459+ listeners) within minutes, leading to complete IDE instability.
Environment
OS: macOS (darwin 25.0.0)
Workspace: Large PHP codebase (~30,000+ files)
Extensions: Various (but issue persists even with minimal extensions)
Steps to Reproduce
Open Cursor IDE with a large codebase
Use the chat/composer feature for code analysis or file operations
Perform multiple tool calls (file writes, code analysis, etc.)
Monitor the system for 10-30 minutes
IDE will crash and restart
Expected Behavior
Chat/composer should work without memory leaks
Extension host should remain stable
IDE should not crash during normal usage
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
For AI issues: add Request ID with privacy disabled
Request ID: 208bfa27-b034-478f-a2cf-1b2c19b60341
Additional Information
Timeline of Memory Leak
12:18:10.244 - 180 listeners
12:18:10.249 - 268 listeners (+88 in 5ms)
12:18:10.795 - 274 listeners (+6 in 546ms)
12:20:51.778 - 364 listeners (+90 in 2 minutes)
12:20:53.395 - 459 listeners (+95 in 1.6 seconds)
12:24:54.710 - Extension host terminated unexpectedly
Root Cause Analysis
The issue is in Cursor’s internal chat/composer system, specifically:
Bubble creation system (Pcr.createBubbleFromToolCall)
Tool call processing (w7.submitChatMaybeAbortCurrent)
Code block processing (Tte.processCodeBlocks)
Impact
Critical: IDE becomes unusable due to frequent crashes
Productivity: Work is lost during crashes
Stability: Cannot rely on IDE for development work
I’m running cursor on Ubuntu (22) VM with a large code-base. I was using 1.4x and then upgraded to 1.7.53 and I started noticing that cursor UI freezes suddenly and locks-up the VM. The VM needs to be rebooted by force. Something has gone terribly wrong underneath. What I also observe that when cursor is closed, the RAM consumed does not get freed-up. I updated to 1.7.54, then same problems occur though with a bit less frequency.
Time to lockup after launch is unpredictable. Sometimes it happens in 10 seconds, sometimes in the middle of chat session after couple of minutes.