When I execute git commit or git commit & sync from the IDE the IDE blocks all windows (not just the current repo / project) and stops any interface updates in almost 80% of the cases. If I click on the IDE window Windows ask for “close or wait”. It takes around 20-30 seconds to unlock (if not more sometimes). In about 20% of the cases that do not happen for some reason. It’s really annoying, distracting and totally breaks the workflow.
Steps to Reproduce
Try to commit / sync to github
Expected Behavior
Not to block at all and especially not to block ALL IDE windows (projects) at once!
Hey, thanks for the detailed report. The version and reproducibility really help.
What you’re describing, all IDE windows going into “Not Responding” during commit or sync, isn’t intended behavior and isn’t something in your setup. Freezing during git operations is an issue we’re tracking. I can’t share an exact timeline yet, but I’ll post in the thread when there’s an update.
To help narrow it down, a few things would be useful:
During the next freeze, open Process Explorer via Cmd+Shift+P then Developer: Open Process Explorer, and share a screenshot. I want to see what’s using CPU at that moment.
Rough repo size (file count and .git size), and whether git config core.fsmonitor is enabled.
Does the same thing happen if you commit from an external terminal using git commit instead of from the IDE? That’ll help tell where the bottleneck is.
Also, since you’re on the Nightly track, if you want a quick test, you can switch to Stable for a bit and see if the behavior changes. Let me know how it goes.
Ctrl+Shift+P will be impossible during the freeze. If I click on the window I get “Close… or Wait …” messages from the Windows OS. Nothing in Cursor is accessible at that time. I haven’t tested using an external git for some time. I’ll try next time.
The repos are not big. For example :
$:> git count-objects -vH
count: 365
size: 6.62 MiB
in-pack: 0
packs: 0
size-pack: 0 bytes
prune-packable: 0
garbage: 0
size-garbage: 0 bytes
PS: One addition, Cursor is on Windows but the projects are on different Samba shares on FreeBSD and Linux servers.
Thanks, that’s helpful. And good point, if the UI fully freezes, Ctrl+Shift+P really isn’t available during the freeze. A couple of workarounds to still catch what’s happening:
Open Process Explorer ahead of time (Ctrl+Shift+P → Developer: Open Process Explorer) before you commit, and keep the panel open. Sometimes it manages to capture the spike. If it freezes too, use Windows Task Manager Ctrl+Shift+Esc. It’s a separate OS process, so it shouldn’t hang. During the freeze, check if there’s a spike in git.exe processes and which process is using CPU, then send a screenshot.
About the repo, I see it’s small (365 objects, 6,62 MiB), which narrows things down. One more question: do you have other windows with big repos open at the same time? The freeze hits all windows, so the load might be coming from another project.
When you can, try the same commit from an external terminal using git commit, not from the IDE. If it’s fast outside, that helps pinpoint where the bottleneck is.
Also check this value: git config core.fsmonitor.
Since you’re on Nightly, for a quick test you can switch to Stable for a bit and see if the behavior changes. Let me know how it goes.
I rebooted and updated at least twice since the last lock. I seems that it is gone at least for now. I did multiple commit & sync didn’t happen even once.
Thanks for the screenshot, it explains a lot. It looks like during the freeze all processes sit at 0% CPU and memory is normal. So this isn’t a git CPU spike, it’s an I/O block. The main process is waiting on the file system, and that stalls all windows at once.
And your note from the last message is the key part. Your projects are on Samba shares (FreeBSD/Linux). During git commit and the following status refresh, git does tons of stat and lstat calls across the repo tree. On SMB every one of those is a network round trip. On a local disk it’s microseconds, but on a network share it can easily turn into those 20 to 30 seconds, and while it’s synchronously waiting, everything freezes.
To confirm this, the most useful tests are:
Copy one project to a local disk (for example C:\...), open it in Cursor as a normal local repo, and try commit and sync from there. If there’s no freeze on local disk, the bottleneck is the network share.
For comparison, run git commit from an external terminal directly on the share, not from the IDE. I’m curious how slow git is by itself in that setup.
Also share the output of git config core.fsmonitor for these repos.
Testing on Stable is still useful, but I suspect the main factor is git on the network share, not the build track. Let me know what you see with the local copy, that will narrow it down the most.
One more pointer - it was happening on the both remote shares (FreeBSD and Linux) in literally the same manner, those shares are on local servers connected at 1GBit/s . It might have been something to do with Window but browsing those shares outside of Cursor (Explorer or Total Commander) there were no locks or anything. It was basically like browsing my local disk.
Might have been some windows FS cache trashing or something along those lines but now it is not happening with exactly the same repos opened.
I’ll test the git commit outside of Cursor if that starts happening again.
Good thing it’s not happening again right now, and thanks for the note about the network shares. That detail matters.
The fact that everything froze across all windows with 0% CPU, while browsing the same share in Explorer or Total Commander was smooth, fits a synchronous I/O wait on git operations. After a commit, git runs status or a refresh with lots of stat and lstat calls across the repo tree. On SMB, each call is a network round trip. Normal file browsing doesn’t create that kind of load, so you see a difference. Your guess about the Windows FS cache also sounds reasonable as something that can make it worse.
Since it’s clean now, no need to try to break it on purpose. But if it comes back, these checks will give the clearest signal:
Copy one project to a local disk C:\..., open it in Cursor as a normal local repo, and try commit and sync there. If there’s no freeze on local disk, the bottleneck is the network share.
For comparison, run git commit from an external terminal directly on the share, not from the IDE. It’s useful to see how slow git itself is in this setup.
Send the output of git config core.fsmonitor for those repos.
I’ve shared the network share observation with the team. Let me know if it starts happening again, and we’ll run the tests above.
