Cursor git controls

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

got this message in the mac cursor app: “The git repository at “…/xxx” has too many active changes, only a subset of Git features will be enabled.” A long conversation with the ai, and the only explanation I got was, in a nutshell, cursor’s git interface is limited and cannot handle the load. There does not seem to be any solution, other than to stop making changes to my project. From what I gather, cursor tracks file changes constantly, instead of checking the files for changes on a push. When some arbitrary unknown limit is reached, you get this message, and all the git related buttons are disabled. Does anyone have a better explanation or a solution to the problem?

Steps to Reproduce

the nature of the bug does not lend itself to easy reproduction. Although, I guess you could take a large project and make global changes to all the files, and see what happens. Mine said I had a little over 10,000, but when I reduced it to around 5,000, it still said that was too much.

Expected Behavior

lost cursor git controls

Operating System

MacOS

Version Information

Version: 3.10.11
VS Code Extension API: 1.125.0
Commit: 4ef9fe3d055f8c4523179a090f14eb835bc3c940
Date: 2026-07-03T04:44:14.398Z
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: Darwin arm64 24.6.0

For AI issues: which model did you use?

GPT 5.5 medium

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report. Good news: this isn’t a Cursor bug. It’s expected behavior from the built-in Git extension inherited from VS Code. When git status returns more than a certain number of entries default is 10 000, the SCM panel stops loading the full UI to avoid slowing down, and some buttons get disabled. It’s a load safeguard, not a crash.

Why it warns even with about 5 000 changes: the limit counts not only the changes shown in the panel, but also untracked files. If the repo has large untracked folders like node_modules/, build/, dist/, .venv/, or build artifacts, they get added to the counter and can easily push it over 10 000.

What you can do:

  • Best fix: add large generated directories to .gitignore like node_modules/, build/, dist/, .venv/, etc. This is usually the real cause.
  • Raise the limit: Settings → search git.statusLimit → set a higher value, or set it to 0 to disable the limit entirely.
  • Hide the warning: git.ignoreLimitWarning: true this is what the Don’t Show Again button sets.
  • After changing settings or .gitignore, reload the window: Cmd+Shift+P → Reload Window.

Start with item 1. After cleaning up untracked junk, everything usually goes back to normal. Let me know if it doesn’t help.