Severe Performance Issues on Windows – Slow Launch, Repository Loading Delays, and UI Freezing

[Mohd_Afzal]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’ve been experiencing major performance issues with Cursor on my Windows machine for the past two weeks.

The application takes a very long time to launch, repositories load extremely slowly, and in some cases repositories never finish loading at all. Overall UI responsiveness has also become very poor compared to earlier builds.

The issue appears to be specific to Cursor because other AI editors are working normally on the same machine without any performance problems.

The slowdown seems heavily related to repository indexing/loading. Sometimes Cursor itself opens slowly even before any project is loaded.

I mainly work with large Next.js repositories, and folders such as .next, node_modules, and other generated files may be contributing to the issue.

Steps to Reproduce

1. Open Cursor on Windows 10/11
2. Open a large Next.js repository
3. Wait for repository indexing/loading
4. Observe very slow startup and repository loading behavior
5. In some cases repositories never fully load and the UI becomes unresponsive

Additional notes:

• Issue started around two weeks ago
• Other AI editors work fine on the same machine
• Reinstalling Cursor and clearing cache did not fully resolve the issue

Expected Behavior

Cursor should launch quickly and repositories should load normally without long delays or UI freezing.

Repository indexing should not cause the entire application to become slow or unresponsive, especially on systems where other editors perform normally.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

latest version

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report. This looks like a known class of Windows issues with startup and indexing that we’re currently investigating. No ETA for a fix yet.

To narrow it down, could you share:

• the exact Cursor version: Help → About (not just latest)
• a screenshot from Process Explorer during the freeze: Cmd/Ctrl+Shift+P → Developer: Open Process Explorer (we want to see what’s using CPU/RAM, like extensionHost, ptyHost, or the file watcher)

Meanwhile, a couple things that often help a lot on large Next.js repos:

1. Exclude heavy folders from watcher and search. Open settings.json via Cmd/Ctrl+Shift+P → Preferences: Open User Settings (JSON) and add:

   "files.watcherExclude": {
     "**/node_modules/**": true,
     "**/.next/**": true,
     "**/dist/**": true,
     "**/.git/objects/**": true
   },
   "search.exclude": {
     "**/node_modules": true,
     "**/.next": true,
     "**/dist": true
   }
   

2. Add .next, node_modules, dist to .cursorignore at the repo root. This reduces load on the indexer.
3. Check extensions. Run cursor --disable-extensions in a terminal and open the repo. If it’s fine, an extension is likely causing it. You can find which one via Developer: Open Extension Monitor and enable it in Settings → Application → Experimental → Extension Monitor Enabled.

Let me know what Process Explorer shows and whether the excludes helped. With the exact version, it’ll be clearer what to dig into next.

[Mohd_Afzal]

cursor version: 3.3.30

[deanrie]

Thanks, the version and Process Explorer helped. A couple notes:

This snapshot was taken while idle (0% CPU everywhere), so it doesn’t show what’s spiking during the freeze. If you can, open Process Explorer and take a screenshot right when Cursor freezes or takes a long time to load the repo. Sort by CPU so the culprit is at the top.

A few things I can already see:

1. You have 3 windows open at the same time (.env, insights.tsx, and Process Explorer). Each window starts its own extensionHost and set of language servers. In the screenshot there are 7+ extensionHost processes and 5 node.exe with --max-old-space-size=16261 (that’s the TypeScript language server). Try keeping only one window with the project and see if it feels better.

2. Start Cursor with extensions disabled to rule them out:

   cursor --disable-extensions
   

   Open the same Next.js repo. If startup and indexing are noticeably faster, it’s an extension. Then we can find the exact one via Developer: Open Extension Monitor.

3. Did you add the excludes from my last message? Adding .next and node_modules to files.watcherExclude plus a .cursorignore is especially important for Next.js. Otherwise the watcher and indexer keep rereading thousands of files.

Waiting for the freeze moment screenshot and the result with --disable-extensions.

[Mohd_Afzal]

The image upload option is not available in the Composer 2 model. Also, some image formats are not working in Cursor IDE, even though they work in Antigravity IDE. I’ll also attach the image that I used for reference.

Properties of the image which I used,which is in png format:

[Mohd_Afzal]

Already completed the steps, so the delay has reduced slightly.

[deanrie]

Hey, good to hear the delay went down a bit. To move forward, we still need:

1. A Process Explorer screenshot during the freeze or long load time, sorted by CPU. The last one was taken while idle, so it doesn’t show what’s actually using resources.
2. Try launching with extensions disabled:

   cursor --disable-extensions
   

   Open the same Next.js repo. If it’s noticeably faster, an extension is likely the cause. We can find it via Developer: Open Extension Monitor.

About Composer 2: yep, that’s expected. Composer 2 is our agent coding model and it doesn’t support image input. If you need to send an image, switch to a vision model like Claude Sonnet 4.6 or Opus 4.7, GPT-5.5, or Gemini 3.1 Pro.