In Cursor, Source Control remains stuck on the message: Scanning workspace for Git repositories…
Because of this, Git repositories are not detected or loaded correctly, and Source Control cannot be used as expected.
The issue does not occur in regular Visual Studio Code, where the same workspace and Git setup work normally. This is unexpected, since Cursor is based on VS Code.
This problem was already reported in a previous ticket, but that ticket was automatically closed after 22 days. The issue itself is still present and remains reproducible in Cursor.
Current behavior:
Cursor Source Control stays indefinitely on “Scanning workspace for Git repositories…”
Repositories do not appear, or do not load correctly
Git operations through the Source Control panel are blocked or unusable
The same setup works correctly in Visual Studio Code
Steps to Reproduce
Sometimes it’s fast
Sometimes it’s slow
Sometimes it’s hangs forever
Expected Behavior
Cursor should complete the workspace scan successfully
Git repositories should be detected and displayed normally
Source Control should become available for regular use, consistent with Visual Studio Code behavior
Sorry about the auto-close on the previous thread. This is a known issue — the Git extension’s repository scanning can hang on certain workspace configurations, particularly on Windows.
A few things to try that should help:
Change the repository detection mode. Open Settings (Ctrl+,), search for git.autoRepositoryDetection, and set it to openEditors. This skips the full directory scan and only detects repos for files you actually open. This is the most impactful fix.
Restart the built-in Git extension. In the Extensions panel, search for @builtin git, click the gear icon on “Git” and choose Disable, then Enable it again, and Reload the window. Another user in the previous thread confirmed this unblocked them.
Open the project folder directly rather than a parent or higher-level directory.
Our team is aware of this and is working on a fix. Let me know if the openEditors setting resolves it for you.
Thanks for your help. It is good to hear that your team is aware of this issue and is working on it. However, after trying your suggestions, I am still experiencing the same problem.
A slightly off-topic question : I have also noticed that the startup time of the cursor appliction is realy slow. Is that a known issue as well?
Impact: Source-control dependent UI/features in Cursor were broken or stuck.
User-Visible Errors
Dev console / renderer stack:
Error checking git status: Error: No full commit provider registered
Error fetching branch data: Error: No full commit provider registered
Historical renderer logs contained repeated:
No full commit provider registered: Error: No full commit provider registered
Call sites included JNc.getCurrentBranch, Gps.loadFromStorage, and editor-group init path.
Root Cause
Cursor 3.2.11 (built on VSCode 1.105.1, Electron 37 line) was executed with system Electron 41 due Arch cursor-bin wrapper/dependency behavior:
Wrapper (/usr/share/cursor/cursor) used name=electron (generic).
On this machine, electron resolved to /usr/lib/electron41/electron.
This version skew caused startup/runtime incompatibilities in Cursor internal extension hosts (especially always-local/git worker), so the full commit provider was not registered before renderer calls needed it.
Runtime Evidence
Wrong Electron runtime selected:
Process exec path during failing runs: /usr/lib/electron41/electron.
cursor-bin dependency included generic electron (not pinned major).
V8/launch mismatch signal:
Captured stderr: Error: unrecognized flag --nodecommit_pooled_pages.
Cursor app code includes Linux js-flag injection of --nodecommit_pooled_pages.
Extension host instability:
Logs showed extension host unresponsive events in failing sessions.
Git worker host existed, but provider registration path still failed in renderer startup.
Reproducible renderer failure in prior sessions:
~/.config/Cursor/logs/20260425T171954/window1/renderer.log had multiple No full commit provider registered entries shortly after extension-host startup.
Setting electron to eletron37 worked for me too. Please bump this thread when there is a real fix so I can set it back to using the latest electron instead of being stuck with 37 forever and probably forgetting about it.
: I have also noticed that the startup time of the cursor appliction is realy slow. Is that a known issue as well?