Cursor's Explorer Tab Has Serious Performance Issues

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s explorer tab is way more less performant than VSCode is. I’m working with a huge monorepo the file tree is so laggy while scrolling. Like scrolling continues after I release the mouse wheel. But on the VSCode scrolling is so smooth can’t believe my eyes I worked through a laggy thing for whole time. Disabling the Material Icon Theme helps a little but VSCode works like nothing even if that icon theme is activated.

Steps to Reproduce

Just open a fairly crowded folder. It does not have to be huge. Even starter templeates for vite, nextjs and expo has these problem.

Expected Behavior

It must be smooth as VSCode’s.

Operating System

Windows 10/11

Version Information

Version: 3.11.25 (user setup)
VS Code Extension API: 1.125.0
Commit: fc2563ec93d793fc275eef734405a4fdf8b47b20
Date: 2026-07-15T01:27:41.754Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.19045

Additional Information

I checked the resource monitor and extension monitor and nothing unusual.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report with the version and steps. This looks like a known issue with file tree rendering on our side. We’ve seen the same scroll lag before, where scrolling keeps going after you let go of the mouse wheel. There’s no ETA for a fix yet.

To confirm it’s the same issue and to share fresh data with the team, can you record a Performance profile?

  • Help > Toggle Developer Tools > Performance tab
  • Click Record, scroll the explorer for a couple seconds, then stop the recording
  • Save the profile with Save profile and attach it here

Also, a quick diagnostic test: try enabling Disable Hardware Acceleration via Cmd+Shift+P or Ctrl+Shift+P and search for Disable Hardware Acceleration, or enable it in settings, then restart Cursor. I’m curious if scroll smoothness changes. Let me know what you find.

Hi, thanks for answering. I recorded a 10 second performance tab and exported as .json.gz. This forum does not support that format so I’m sending it in a zip.

Trace-20260728T102445.json.gz.zip (5.7 MB)

Also tried disabling the hardware acceleration and it didn’t changed anything after restarting the app.

Thanks, the trace is exactly what we needed. I went through it and it’s pretty clear what’s happening: most of the scroll time is spent recalculating styles on the renderer main thread, not on the GPU. That’s why Disable Hardware Acceleration didn’t change anything, switching compositing isn’t the issue here, the bottleneck isn’t graphics.

In short: when you scroll the tree, each new batch of rows invalidates styles for almost the entire tree, not just the new items. That’s what causes the FPS drop and the “scroll keeps going after I release the wheel” effect. Wheel events pile up while frames are being dropped. Your note about Material Icon Theme fits this too, row decorations add extra render cost per row.

This is a known issue with file tree rendering on our side. I filed an internal report and attached your trace as confirmation. There’s no ETA for a fix yet, and there isn’t a reliable workaround. Disabling the icon theme only helps a bit, like you already saw. I’ll post an update in the thread when I have one.

Thank you, waiting you to fix it. Have a good day.