Cursor Git tab hangs due to invasive ripgrep scanning on network/FUSE mounts (Linux)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hello Cursor team,

I’m encountering a serious usability issue on Linux related to the Git integration and background scanning when opening folders.

Description of the problem

Whenever I open any folder in Cursor, the Git tab shows:

“Scanning folder for Git repositories…”

and remains in that state for a very long time (sometimes effectively forever). During this time:

  • The Git tab becomes unusable.
  • Cursor spawns multiple background rg (ripgrep) processes.
  • These processes scan very aggressively across the entire filesystem.

The exact command being launched repeatedly is:

/usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg \ 
    --files --hidden --no-ignore --no-config --color=never \ 
    -g **/*.code-workspace -g .cursorignore -g **/.git/config

This is a serious issue. My system (and many Linux setups) contains several network shares (CIFS/NFS) and 2 FUSE-mounted filesystems. Because Cursor’s scanning does not respect mount boundaries ripgrep enters slow or blocked I/O on these mounts.

Steps to Reproduce

  1. On Linux, have at least one slow or remote mount (NAS, FUSE, CIFS, etc.) somewhere under / or accessible from the opened folder tree.
  2. Open any folder in Cursor.
  3. Open the Git tab.
  4. Observe:
    • “Scanning folder for Git repositories…” stays for a very long time.
    • Multiple rg processes are spawned.
    • Cursor becomes sluggish and Git UI is blocked.

Expected Behavior

Git scanning should check the current working directory for the presence of .git folder, then if it’s not found, it should check it’s parent, etc., up to the root folder. It should not aggressively scan the entire file system and multiple remote systems and mounts.

Operating System

Linux

Version Information

Version: 2.4.21
Commit: dc8361355d709f306d5159635a677a571b277bc0
Date: 2026-01-22T16:57:59.675Z
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Cursor/2.4.21 Chrome/142.0.7444.235 Electron/39.2.7 Safari/537.36

Does this stop you from using Cursor

Yes - Cursor is unusable

Scanning folder for git repositories is taking forever
3

Hey, thanks for the detailed report. This is a known issue with ripgrep scanning on Linux.

The team is aware of this bug. There are two issues:

  • The Git tab getting stuck on “Scanning folder for Git repositories”
  • A broader issue with ripgrep scanning on NFS or FUSE mounts

Your report adds useful details about the Git tab specifically, and about CIFS and FUSE mounts. I’ll pass this along to the team for context.

Unfortunately, there isn’t a good workaround yet. A similar case was described here for Remote SSH with NFS.

I get that this is critical for your work, you mentioned Cursor is unusable. You can try:

  • Temporarily unmount network shares while using Cursor
  • Use projects inside local directories, and don’t open a folder too high up in the filesystem tree

Let me know if you find any workaround on your side, it could help other users in the same situation.

4

It is just extremely concerning that your development team is shipping new features and at the same time is failing to address a pretty serious issue (although not affecting most of the people) which has been known for more than a month now.

You don’t find that a decision to set Cursor to scan my entire filesystem is a bit controversial? Okay, I understand that this could be just a mistake in the filters passed to ripgrep, but then why not roll it back immediately? This is what I would have done in my team, if this code for some reason had even passed a code review.

One of your engineers stated here that the problem will be fixed in Cursor v2.4 release. I’m on version 2.4.21 and the problem is still there.

Workarounds? Well, I have tried limiting access to the shares, but Cursor still finds its way there. I’ve tried using AppArmor to restrict access, but no luck. Currently what works is to rename or move the rg binary before I start Cursor, so it doesn’t run a full scan, however that bricks the File Search and the Agentic mode, even after I restore the binary, so not really a usable workaround. I’m thinking that creating a sandbox for Cursor might actually work, but I don’t have time to tincker with this.

This is extremely frustrating.