Cursor is creating and holding onto a .git/index.lock file, preventing all git operations (add, commit, push) from working. The lock file persists even when no explicit git operations are being performed through the UI.
Status: File exists and cannot be deleted (access denied)
Error Messages
fatal: Unable to create 'C:/ol/legacy-explorer/.git/index.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
Affected Operations
git add - FAILS
git commit - FAILS
git push - FAILS (also has network/proxy issue)
Any git operation that requires index access
Steps to Reproduce
Steps to Reproduce
Open a git repository in Cursor
Make some file changes
Attempt to stage changes via terminal: git add <file>
Observe error: lock file already exists
Evidence
No other git processes running (verified via Get-Process)
Only Cursor processes are active
Lock file was created at 11:34:54 AM (recent, during active Cursor session)
Lock file is empty (0 bytes), suggesting a crashed or stuck process
Cannot delete lock file (access denied), indicating Cursor is holding a handle to it
Expected Behavior
Expected Behavior
Cursor should properly clean up git lock files after operations complete
Lock files should not persist when no git operations are active
Manual git operations via terminal should work independently of Cursor’s git operations
This looks like a known issue. Cursor can keep a handle on the .git/index.lock file, which blocks Git operations. We had a similar bug that was fixed, but this looks like either a regression or an incomplete fix.
Workaround for now:
Fully close Cursor (make sure all processes are closed)
Manually delete .git/index.lock
Restart Cursor
If the file still can’t be deleted after closing Cursor, please check Process Explorer or Task Manager to confirm all cursor.exe processes are actually terminated.
If this keeps happening regularly, I can pass it to the team to investigate. Let me know how it goes.
Having the same issue on macOS in auto mode, issue went away after switching to Opus 4.5 but still getting the error with auto mode. Seem to happen when the agent tries running too many git operations at once.
fatal: Unable to create '/Users/**/.git/index.lock': Operation not permitted
How I Fixed Git and Coverage File Locking Issues After Cursor Update
After updating Cursor, I encountered two issues:
Git commands were failing with file locking errors (similar to index.lock problems)
Coverage files (.coverage*) were getting locked during test runs, causing PermissionError: [WinError 5] Access is denied
Root Cause:
The problem was caused by Cursor’s terminal shell integration feature, which was interfering with file operations. The integration wrapper was trying to collect environment variables after each command execution, causing conflicts with file locks.
Solution:
I disabled the shell integration by adding the following setting to Cursor’s user settings file:
In short, the previous setup also didn’t work well. The MCP server on GitHub didn’t understand it, and the glitches were still there. Only rolling back to version 2.3 helped. Now it’s fine with that version, like it was before.