In recent versions of Cursor, I’m finding that while the agent is producing tokens, the rest of the UI becomes extremely sluggish or non-responsive, including and especially the terminal. I don’t recall this being an issue in earlier versions.
Related: Even when the agen’t isn’t producing tokens, I’m finding recent versions to be much more sluggish UI. When I click a menu item it takes a good 0.2s for the menu to show up, compared to ~imperceptible delay in earlier versions.
Is this known or is there a workaround?
Steps to Reproduce
Start a long running agent job, then try to do something in the terminal
Expected Behavior
Terminal and editor tabs fully responsive while agent is working
Hey, thanks for the report. A few things to check so we can narrow this down:
Open Process Explorer (Ctrl + Shift + P > Developer: Open Process Explorer) and see which process spikes during agent token generation. Please pay special attention to extensionHost and ptyHost CPU and memory usage.
Try running Cursor with extensions disabled to rule them out:
cursor --disable-extensions
What Linux distro and desktop environment are you using? Some compositors, especially Wayland, can interact poorly with Electron apps.
You can also try toggling GPU acceleration. Add this to your argv.json (Help > Open Command Line Arguments):
"disable-hardware-acceleration": true
Or do the opposite if it is already disabled.
The general UI sluggishness (like a 0,2 s menu delay) outside of agent work is worth separating from the agent specific lag since they may have different causes. Process Explorer output in both cases would help a lot.
I see the screenshots, thanks. They’re really helpful.
The main thing that stands out is that the window [2] process (the main renderer) is using 3 GB of memory, and the history shows spikes up to 30 GB. That’s not normal and it looks like a known memory leak in the renderer.
One more thing: cursorpyright under extensionHost is using 1.1 GB. That’s also a lot, but the main issue is most likely the renderer.
A couple things that’ll help us confirm what’s causing it:
Open Help > Toggle Developer Tools > Console and check if you see warnings like ListenerLeak or MaxListenersExceededWarning. That would directly show whether you’re hitting this leak.
Close all chat tabs and start a new chat. Long chats with lots of code blocks can trigger this leak. If the window process memory drops a lot after that, it’s a strong signal.
You skipped step 2 from my last reply. Try running cursor --disable-extensions to rule out extensions. cursorpyright at 1.1 GB is also suspicious.
The team is aware of this renderer memory leak. Your report with the Process Explorer screenshots is really helpful for prioritizing it.
Over the past several months, I have repeatedly noticed that Cursor’s performance is extremely poor in two areas, and the IDE freezes.
The first issue is that as soon as files are being written, the entire IDE effectively “freezes.” It is still technically usable, but if, for example, I am in the middle of an autofix or performing other operations, those become blocking operations and are not carried out until the tool has finished writing. There are several scenarios where this happens. This likely traces back to poor architecture in how the tool is implemented, because it appears to block system processes inside the VS Code IDE in some way. Since I am using a 7,000-euro machine, this is definitely not due to my hardware. So something is very clearly blocking the IDE heavily whenever files are being modified.
In addition, I have noticed that when working within a single context window over multiple iterations, the DOM simply becomes overloaded and the application stops functioning properly. From what I can tell, the context window seems to be designed with an endless scroll mechanism, where elements at the top of the DOM should theoretically be removed. That is how this is typically handled on websites: if you have an endless scroll page, you remove content at the top so the DOM does not become flooded with HTML nodes and performance remains stable. I strongly assume Cursor is trying to do the same thing, because when scrolling back up, content does get reloaded. However, it does not seem to be working properly, because the longer the context window becomes, and the more iteratively I work within a single context window, the more unresponsive the entire IDE becomes. It starts lagging more and more and feels increasingly frozen.
These two issues are extremely disruptive and should please be addressed and fixed somehow, as this is definitely not related to my hardware.
I have 1 minute freezes on Debian 13 with KDE Wayland. It’s maybe a problem with your fork of VSCODE / Electron and how throttling affects background tasks and UI rendering..
If i run an intensive cpu task in Cursor, then open chrome to do something else , then when the task finished, Cursor will freeze for 1 minute, every time.. I did extensive tests and log monitoring but couldnt fix it.
and these settings are not available in Cursor fork:
“disable-hardware-acceleration”: false,
“disable-background-timer-throttling”: true,
“disable-renderer-backgrounding”: true,
“disable-backgrounding-occluded-windows”: true
I tested all possible flags.. (also tested nvidia fixes but that’s not the issue)
I’m also suspecting it may be something with “sytem notifications” setting, because the freeze always happens at the end of the Cursor task
the bug never happen if the window stay active and on front.
@User4: What you’re describing, DOM overload with long context windows and freezes when writing files, matches what we’re seeing for the OP. This is a known renderer memory leak. As a workaround, close long chats and start new ones, and don’t stay in a single context window for too long. It’s not perfect, but it greatly reduces DOM and memory pressure.
If you want to help with debugging, open Process Explorer Ctrl+Shift+P > Developer: Open Process Explorer and share a screenshot when the lag starts. I’m especially interested in the memory for the window process.
@prodfab: Your issue looks separate from the memory leak. A 1-minute freeze when Cursor regains focus after running in the background sounds like background throttling in Electron/Chromium on Linux with Wayland.
A few things to check:
Try starting Cursor with --ozone-platform=x11 to rule out a Wayland-specific issue.
Try adding this to argv.json Help > Open Command Line Arguments:
"disable-gpu-compositing": true
What Cursor version are you on? Also, can you share the Process Explorer output during the freeze, right after focus returns?
You’re right that flags like disable-background-timer-throttling aren’t available via argv.json in Cursor, but some can be tried via the command line, for example cursor --disable-background-timer-throttling. I can’t guarantee it’ll work, but it’s worth testing.
My problem was 100% solved after I deactivated “System notifications” in Cursor settings. (I tried so many different things in console, logs, cpu, nividia, drivers, etc.. And finally I found someone on Cursor Forum who has this “known issue with Windows”.. But actually it worked also for Debian 13 with KDE Plasma!)
