Hey, this is a known issue. Source Control can sometimes get stuck on “Scanning workspace for Git repositories…” when you have multiple repos inside the same parent folder.
The most reliable workaround right now is to disable full directory scanning:
Settings Cmd+Shift+, then search for git.autoRepositoryDetection
Set it to openEditors
This skips the recursive scan of subfolders, which is what causes the freeze. If your repos don’t get picked up automatically after this, open any file from the repo you want and it should detect it.
You can also try restarting the built-in Git extension Extensions > @builtin git > Restart and tweaking git.repositoryScanMaxDepth.
I’m using the "git.autoRepositoryDetection": "openEditors" option, but without success. Cursor is still taking a long time, and the startup time is also terrible.
Thanks for getting back to me. Since openEditors didn’t help, let’s narrow it down. It looks like this isn’t only about scanning itself.
Since you’re on Windows, slowdowns here are usually caused not by Cursor itself, but by external factors. Please check these:
Windows Defender or antivirus. Real-time scanning of .git folders can seriously slow down git operations. Add your repos folder and Cursor itself to Defender exclusions: Settings > Virus & threat protection > Exclusions.
Where your repos are stored. If the folder is on OneDrive, a network or mapped drive, or inside a sync folder, it can cause huge delays during scanning. It’s best to keep repos on a local disk.
Fully disable auto-detect. Try git.autoRepositoryDetection: false instead of openEditors, and set git.repositoryScanMaxDepth: 0. This will tell us if the freezing goes away completely.
For slow startup, launch Cursor from the command line with cursor --disable-extensions and compare load time. If it starts much faster with extensions disabled, the issue is one of them. You can narrow it down via Cmd+Ctrl+Shift+P > Developer: Open Process Explorer.
Let me know what helps, and roughly how many repos and files are in your workspace. That’ll help us figure out if we’re hitting a core scanning bug or something Windows-specific. The scanning hang is known and already logged, but I don’t have an ETA yet.
Also, the Electron downgrade fix from the other thread is Linux Arch specific and doesn’t apply on Windows, so you can ignore that.
