As shown in the figure, even with a single agent performing the task, it gets stuck.
Hey, thanks for the report. From the screenshot, I can see the Cursor window is frozen, the process is using about 4.8 GB, and memory usage is at 72%. Memory growth and freezes during long or heavy agent sessions are a known performance issue. I can’t share an ETA for a fix yet.
To help with diagnosis, I need a couple things:
- Your Cursor version and OS version: Help > About
- If you see the High Memory Usage prompt again, please accept it. It will send us a heap snapshot. Or do it manually: Command Palette
Ctrl+Shift+P>Developer: Capture and Upload Renderer Heap Snapshot, then send me the reference.
Things that can help right now:
- Fully restart Cursor from time to time
- For long agent tasks, start a fresh chat. The growing history can increase memory usage
- Close unused or large editor tabs
- Disable unnecessary extensions and extra MCP servers
- Avoid commands that print huge output in the terminal
Let me know your Cursor version and OS. If you can grab a snapshot too, that’d be great.
I used version 3.7.12 and upgraded to 3.8.11 after this bug.
However, it doesn’t seem to be caused by the version. Instead, it’s a specific conversation. Because after I created a new conversation and started chatting, the previous situation didn’t occur again.
Regarding this particular conversation, I merely had it use the plan function to analyze a small project and provide suggestions. During the plan process and subsequently when switching to this conversation, the memory usage would continue to increase.
Here is the current version information of mine. I hope it can be helpful to you.
Version: 3.8.11 (user setup)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: glass
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: Windows_NT x64 10.0.26100
Hey, thanks for the update and for the detail about the specific conversation, that’s helpful. Since the memory growth is tied to one chat Plan mode in that project and a new chat is clean, it looks like retention in that conversation’s state, not a general slowdown.
What would help most right now is a heap snapshot taken when that problematic chat is open and memory is already high:
- Open the problematic conversation and let memory climb
- Command Palette
Ctrl+Shift+P> Developer: Capture and Upload Renderer Heap Snapshot - Send us the reference you get back
If the High Memory Usage prompt shows up again, just accept it, it will also send us a snapshot.
For now, the workaround you found makes sense. For long tasks, start a fresh chat. The history grows over time and pushes memory up. I can’t share a fix timeline yet, but the snapshot will really help us diagnose this.
