Eslint slow in cursor but fine in vscode

Support Bug Reports
1

Describe the Bug

As of recent updates, eslint takes an unreasonable time to run or sometimes doesn’t run at all, via the eslint vscode plugin. It works fine in vscode, and nobody on our team can figure out why. Any idea where we can look to figure out why this is happening? It seems to be a new issue

Steps to Reproduce

eslint 9 + latest vscode eslint plugin

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.4.5 (Universal)
VSCode Version: 1.99.3
Commit: af58d92614edb1f72bdd756615d131bf8dfa5290
Date: 2025-08-13T02:08:56.371Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Yes - Cursor is unusable

2

As this spreads across the team, this is going to push more and more folks away from cursor, which will make paying for licenses an issue.

3

Hey, thanks for the report. Can you confirm that your entire team is experiencing issues with this extension? Could you let me know how long this has been happening and in which version of Cursor this problem didn’t exist?

4

We’ve gotten reports about this in the last 10 days. It looks like it’s impacted the whole team in some way or another (not consistent), since even for those not being loud about it in our internal Slack, I’m seeing more PRs fail with lint errors, which wasn’t an issue before (e.g. lint issues getting caught in CI and not cursor).

Even if you all can’t pin down the issue with the limited info we have, I’d love more info on how we can debug it or get more logging.

5

We’re not tracking Cursor versions closely, unfortunately. I can’t say specifically which version introduced it.

6

image
image1584×328 54.7 KB

Took a poll for you. Other responses I got:

eslint works fine, it’s not slow or hanging. But my frustration is that I have to hit “keep changes” after every change for the auto-formatter to run so cursor doesn’t try to manually fix all of the lint issues.

eslint starts out working fine for me, but eventually gives up and I have to restart to get it working again. Probably once or twice per day

eslint crashes every few days for me, and I don’t notice it until a push a log with a missing space.

FWIW, it’s been months since we upgraded eslint, so I don’t think that’s the issue.

7

Hi Ben!
I need your help to fix this one.
Whenever everything is super slow, could you press Cmd + Shift + P , type Developer: Show Running Extensions there, press enter.
Press a little white dot on the right side of the bar next to the green play button - “Start Extension Host Profiler”. Do some slow edits, force eslint to work hard for a minute or two. Go back to Running Extensions tab, press “Stop Extension Host Profiler“ (will be at place of the white dot). Press “Save Extensions Host Profile” - on the left side of the green play button and share the result here.

Thank you!

image

9

Will share this with the team and get back to you. Thanks!

1 Like
10

For anyone affected, can you share the output of this command in the repo you have open:

git show-ref | wc -l

11

Does this popup appear when the issue is occurring? Or does it manifest differently?

Screenshot 2025-08-16 at 10.09.06 PM
Screenshot 2025-08-16 at 10.09.06 PM726×252 21.1 KB

12

yeah like that, but only eslint, not the other stuff

13

For git show-ref | wc -l, folks have reported 3579 and 3210, so far

14

Interesting.

Is this happening for ppl using the remote-ssh feature?

If I provide a test build with a possible fix would someone who hits this frequently be willing to try?

15

Nobody on our team would be using remote-ssh. Will ask the team about test build!

16

macOS:
• Intel DMG
• Apple Silicon DMG
• Universal DMG

17

A profile from any existing Cursor version where this is happening would also help.

The simplest way to capture that is by cmd-P > >Developer: Start CPU Profiler

Run that when things are hanging, hit save a few times, then click Stop Profiler button and email the .txt file that appears to [email protected]

18

Hi, I work at the same company as @benasher44 and I’m one of the people who had this issue. Some more data points that might help:

  • I’m on Linux; most other engineers here are on macOS and Ben probably forgot I was one of the weird ones
  • git show-ref |wc -l showed 5344 refs for me when it was happening
  • I switched to VSCode, where I found I had the same problem
  • I mass-deleted most of my old branches, and now have only 164 refs
  • now I do not have the issue in either editor

This does suggest (1) it may be an upstream VSCode issue that doesn’t always appear for whatever reason, and (2) whatever hunch you had involving thousands of refs making it slow is likely true.

I did not try the test build (because Linux) but at least one coworker did, and it seemed to have helped for him.

19

Which version of VSCode did you try with?

20

1.103.0, from the Arch package, which has since been bumped to .1:

Version: 1.103.0
Commit: e3550cfac4b63ca4eafca7b601f0d2885817fd1f
Date: 2025-08-10T08:54:35.068Z
Electron: 37.2.6
ElectronBuildId: undefined
Chromium: 138.0.7204.185
Node.js: 22.17.1
V8: 13.8.258.30-electron.0
OS: Linux x64 6.14.7-arch2-1
21

Engineer who tried the test build found it was still a problem (eslint hang and then crash)