Cursor Performance after long tasks or writing files

[Benutzer4 (Info)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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.

Got this on windows and linux

Steps to Reproduce

see desc

Operating System

Linux

Version Information

Version: 2.6.19
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Early Access
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.8.0-90-generic

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, both issues are known bugs. Quick summary:

1. UI freezes when the agent writes files: we’re seeing this for a few users. It’s related to how the renderer handles file operations.

2. Slowdown in long sessions: you’re right about the root cause. There’s a memory leak in the renderer, so long chats with code blocks keep accumulating memory. Users are seeing the renderer process at 3+ GB, with spikes up to 30 GB.

Related thread with diagnostics: Cursor UI freezes up when agent is working

For now, the workaround is to periodically close long chats and start new ones. That should reset the renderer’s accumulated memory.

You can also check a couple things for diagnostics:

1. Ctrl + Shift + P > Developer: Open Process Explorer: check the memory usage of the “window” process during freezes.
2. Help > Toggle Developer Tools > Console: see if there are warnings like ListenerLeak or MaxListenersExceededWarning.

The team is aware of both issues, and your report helps with prioritization. Let me know if closing chats helps.