Product Stability

After updating to anything past 0.48, including the latest 0.50, Cursor stability is completly in the gutter on Windows 11. I will just be typing in a file or clicking around the IDE normally and the entire application will lock up, giving me this:

And occasionally completely crashing, although I don’t have a picture of that handy at the time of this post.

I have more than enough resources, and Cursor is only using ~1GB of RAM, so I am nowhere near maxing out my machine. I have no issues with any other software, it is just Cursor. This is my “About” section:

Version: 0.50.5 (user setup)
VSCode Version: 1.96.2
Commit: 96e5b01ca25f8fbd4c4c10bc69b15f6228c80770
Date: 2025-05-18T04:26:31.444Z
Electron: 34.3.4
Chromium: 132.0.6834.210
Node.js: 20.18.3
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.26100

These are my Windows specifications:

Edition	Windows 11 Pro
Version	24H2
Installed on	‎06-‎Jan-‎25
OS build	26100.4061
Experience	Windows Feature Experience Pack 1000.26100.84.0

If it matters, I only use Cursor with a remote tunnel to my Linux server, so I have no idea if this will perform as poorly with just local files. But again, it worked perfectly through 0.48, there were no performance issues and the remove system has insanely high resources available.

Is anyone else dealing with this?

2 Likes

Back up your rules, ALL of them lol. Your main one as well, anything else that’s custom.

Clear your Cursor folder under your AppData directory.

Report back and let me know if that provided any performance relief.
Please back things up before you do this though, as it will nuke your rules 100% and your chat history. Use the SpecStory extension to back up any important chat history beforehand.

1 Like

I think that worked! Why is that the solution, am I going to have to delete this folder frequently?

1 Like

Quite frankly, I’m not 100% sure but I believe it has to do with caching.

1 Like

Unfortunately that did not end up being the solution, after about 30 minutes the exact same issues started happening again.

Well, thats unfortunate. Apologies I couldnt find a smooth solution for you. Have you tried disabling indexing?

1 Like

I have not, I was under the impression that indexing made things faster so I hadn’t considered that it would be relevant

See if that gives you some resolve, let me know! Fingers crossed

Yes indexing is needed for AI to better understand your codebase and so it can lookup parts, however over remote connection that can lead to slowdown specially after upgrade to a new version as it re-indexes the code.

Sometimes disabling and re-enabling indexing may help. At least it would show if this was directly causing the issue.

Is the project large? or has large files that need to be fetched from remote server?

Additional option:

Cursor released with version 0.50 a new Remote SSH extension, please try replacing the original with this one. See instructions on following page provided by Cursor team.

1 Like

No luck, still getting the same issue :frowning:

Please explain a bit more when and in what cases Cursor crashes. Right after start? after x minutes? When you use a specific feature?

I would be good to narrow down possible causes.

I tried that out but I don’t think it’s applicable to me, I use Tunnels not SSH.

Disabling the indexing did not help, re-enabling it didn’t do anything either.

Project is reasonably large, about 1000 files, but no large files are fetched from the server. Again, this ONLY happens from 0.49 and onwards, I had no issues at all in 0.48 and I’ve reverted back to the old version several times because I keep experiencing these issues.


UPDATE: I tried using the SSH method instead of tunnels, after installing that new extension and removing the Microsoft one, but still have the same issues.

It has no pattern, sometimes it crashes 30 seconds after starting, sometimes it just completely hangs when I’m not even using the application and I’m on another monitor. Sometimes like earlier it works great for 30 minutes then goes right back to awful performance.

If there is any kind of logging I can enable to pinpoint the cause, I’d be happy to do so.

Yes understandable, lets see if @ravirahman is has perhaps some options.