Interface lag makes Cursor borderline unusable

:lady_beetle: Provide a clear description of the bug

Cursor UI locks up for 3-5 seconds with each interaction.

No matter what I do, even simple copy-paste from markdown files opened in Cursor cause the entire OS to slow down, and Cursor itself becomes so locked up that the OS offers to force quit it.

Obviously that becomes a substantial hinderance to work if one needs to wait 10 seconds for each simple interaction with the UI.

This applies to each and every interaction with the Cursor UI, even simply selecting text in open markdown files.

:counterclockwise_arrows_button: Explain how to reproduce the bug (if known)

Just use the application.

:camera: Attach screenshots or recordings (e.g., .jpg, .png, .mp4).


(Don’t let that version number fool you - due to how Linux is running Cursor, it shows the first version that’s installed here, but I run the latest version (0.50.7).

:laptop: Tell us your operating system and your Cursor version (e.g., Windows, 0.x.x).

Linux Mint 22.1 with Linux Kernel 6.8.0.60.

Cursor version 0.50.7

Hardware: Intel 12th Gen IntelCore i7-12700K, so I don’t think it’s a hardware issue

:prohibited: Tell us if the issue stops you from using Cursor.

100%. It’s more than doubling the time I should need to simply use the program.

2 Likes

P.S.: Force quitting Cursor halved the total used memory (went from about 15 gigs to 7.7 on a 32 gig rig). So might a memory leak.

Yeah this is excessive, im running it for days without closing and its at 2GB now.

You can check things out with the Process Explorer (Help menu) to get better info what is causing this.

Please try Troubleshooting guide and Common Issues for how to provide more details what is happening. Likely causes are outdated Cursor version and 3rd party extensions. In some older versions, clearing the chat history and similar options helped reduce hanging Cursor.

I get the same on Linux XXXXXX 6.11.0-25-generic #25~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 17:20:50 UTC 2 x86_64 x86_64 x86_64 GNU/Linux w/ 0.50.7

I thought it was just me, thanks for posting :slight_smile:

1 Like

Thanks for the post. Are you also on Linux by any chance?

As I wrote above, I’m on the latest version and have no 3rd-party extensions. The only thing I added to Cursor are two MCPs (Playwright and Supabase).

But as the issue comes with time and only appears on Linux, it seems to be an OS-specific problem. I’m thinking memory leak, but hard to pinpoint without devoting some time to it.

1 Like

Thanks for chiming in! That really helps actually.

I used Cursor yesterday on my Windows laptop and didn’t get any comparable problems there, even after using Cursor (with the same chat open + same MCPs) for some hours.

So I’m heavily leaning into the idea that it’s a Linux-issue with a potential memory leak, as indicated by the RAM use.

@m6T could you under Cursor > Help > Process Explorer check which of the Cursor sub-processes consumes so much, perhaps post here the screenshot if possible. (Im hopping today between devices so not able to check my Linux machine)

@danperks perhaps this will help narrow the issue down, as several users confirmed it on Linux.

Checking the process explorer can be super helpful here, but I’ll pass this to the team to make sure we look into it!

1 Like

Here’s my process explorer - its using 1GB for a medium-sized source file it appears?

Nothing out of the ordinary there, so not sure why it’s not responding like this!
How long does it take to get to this point?

+1 can confirm. I spend more time on waiting than on working with cursor (no joke).

It get’s increasingly interesting if it does that while you are typing your next prompt
→ window freezes (even though there is no other user-caused load than typing)
→ ā€œCursor is not Respondingā€ opens while you type
→ you accidently force quit cursor

lot’s of fun.

Memory and cpu are not remotely close to getting properly used while cursor freezes.

I tried closing and re-opening cursor, or closing all opened files. No difference.

Last time i did not have this issue was when I was still on version 45 or 46.x but this might be a coincidence.

I am on Ubuntu 24.10, currently using the 50.5 AppImage.

I’m now on 1.0 and still seeing this issue. I can get about 5-10 minutes of agent activity until it starts to stop responding

Edit: I notice that both reports here mention VS Code 1.96.2. This version has a memory leak (at least for Windows): Hardware acceleration creates memory Leak on 1.96.2; eventually caps RAM and freezes computer Ā· Issue #237292 Ā· microsoft/vscode Ā· GitHub I’ve turned off GPU Acceleration to see if this might help. I’ll report back if any change with moderate usage.

I’ve noticed the app crashes less without hardware acceleration off. Perhaps its a partial resolution for this issue.

Windows 10 here
Lags a lot

Version: 1.0.0 (user setup)
VSCode Version: 1.96.2
Commit: 53b99ce608cba35127ae3a050c1738a959750860
Date: 2025-06-04T19:44:25.253Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.19045

Try my solution, may help you. I personally noticed that when cursor was freezing it was deadlocking everything on my PC and that was corresponding with state.vscdb being updated, I made a simple script that moves it to RAM memory in /tmp and problem disappeared completely for me. I do wonder if it is because of a COW btrfs filesystem where that state file is located ?

https://forum.cursor.com/t/cursor-is-not-responding-constantly-on-linux/97562/14?u=johnricksanchez