Recover lost workAlways fixable

Fix 'Unable to create index.lock: File exists'

Git says another git process seems to be running — how do I fix index.lock?

Short answer

Git locks the index while it works and removes the lock when it finishes. A crashed command, a killed process or an editor's background Git integration can leave the lock behind. Confirm nothing is actually running, then delete .git/index.lock.

quick fix
rm -f .git/index.lock

Removes the stale lock — only after checking no Git process is running

Does this match your situation?

  • 'fatal: Unable to create .git/index.lock: File exists.'
  • 'Another git process seems to be running in this repository.'
  • Every Git command fails the same way, including git status.
  • It started after a crash, a force-quit, or closing your IDE mid-operation.

Step-by-step fix

  1. Make sure no Git process is genuinely running

    Deleting the lock while a real command is mid-write can corrupt the index. Check first — this takes two seconds and removes all doubt.

    step 1
    ps aux | grep -i '[g]it'
    Show the PowerShell (Windows) version
    PowerShell (Windows)
    Get-Process git -ErrorAction SilentlyContinue
Get-Process | Where-Object { $_.ProcessName -like '*git*' }

    Also close VS Code, JetBrains IDEs, GitHub Desktop and any Git GUI - they run Git in the background constantly.

  2. Delete the lock file

    With nothing running, the lock is stale and safe to remove. Git recreates it the next time it needs one.

    step 2
    rm -f .git/index.lock
    Show the PowerShell (Windows) version
    PowerShell (Windows)
    Remove-Item .git\index.lock -Force

  3. Check whether the index survived

    Run status to confirm Git is healthy again. If it reports a corrupt index, rebuilding it from HEAD is safe — the index is derived data, not history.

    step 3
    git status

# only if the index itself is broken:
rm -f .git/index
git reset

    Deleting .git/index loses your staging selection, not any committed work. You'll need to re-stage.

  4. Look for other stale locks

    The index isn't the only thing Git locks. A crash during a ref update or a config write can leave those behind too.

    step 4
    find .git -name '*.lock'
# then remove the specific ones you find, e.g.:
rm -f .git/refs/heads/main.lock
    Show the PowerShell (Windows) version
    PowerShell (Windows)
    Get-ChildItem .git -Recurse -Filter *.lock

Why this works

Git uses lock files to make index and ref updates atomic: it writes to `index.lock`, then renames it over `index`, so a crash can never leave a half-written index. The rename is what releases the lock. If the process dies before that, the lock file remains and every later command refuses to start, because from Git's point of view another process might still be writing. The lock is pure coordination state — deleting a genuinely stale one is completely safe.

If that didn’t work

  • If the lock reappears instantly, an editor extension or file watcher is running Git in a loop - close it and retry.
  • On Windows, antivirus or a file-sync client (OneDrive, Dropbox) can hold the file open; pause it and retry.
  • If .git sits inside a synced folder, move the repository out of it - sync clients and Git conflict constantly.

How to stop it happening again

  • Don't force-quit while a Git command is running.
  • Keep repositories out of OneDrive, Dropbox and Google Drive folders.
  • Exclude .git directories from real-time antivirus scanning if you hit this often on Windows.

Commands used in this guide

git status

Show what's changed, what's staged, and what Git is ignoring.

git reset

Move the current branch pointer, optionally rewriting the index and your files.

git fsck

Scan the object database for orphaned commits and blobs the reflog no longer lists.

Still stuck?

Search the full command reference and every other rescue guide — there are 56 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

Is it safe to delete .git/index.lock?

Yes, as long as no Git process is actually running. The lock file exists only to stop two commands writing the index at once; if the process that created it has died, the file is meaningless and Git will recreate it when needed.

Why does index.lock keep coming back?

Something is running Git repeatedly in the background - usually an IDE's Git integration, a file watcher, or a Git GUI left open. Close them, delete the lock once more, and it will stop.

Will deleting the lock lose my work?

No. The lock holds no data. Even deleting .git/index itself only clears your staging area, since the index is rebuilt from HEAD - your commits and working files are untouched.

Related rescue guides

Usually recoverable

Git says 'object file is empty' or 'loose object is corrupt' — can I repair it?

Corruption is almost always a few damaged object files after a crash, disk problem or a killed process. Run git fsck to identify them, delete the empty or unreadable ones, and re-fetch the good copies from your remote. If you have a remote, a fresh clone is often the fastest fix.

Read the fix →Rarely recoverable by Git

How do I throw away all my local changes in Git?

git restore . discards edits to tracked files and git clean -fd deletes untracked ones. Both are irreversible for anything that was never staged or committed, so run git stash first if there's any doubt — it takes a second and makes the whole operation undoable.

Read the fix →Always fixable

How do I undo git add without losing my changes?

git restore --staged <file> removes a file from the staging area and leaves your edits completely untouched. The older equivalent is git reset HEAD <file>. Neither one touches the contents of your file, so this is a zero-risk operation.

Read the fix →Sometimes recoverable

I permanently deleted a file that was never committed — can I get it back?

It comes down to one question: was the file ever staged with git add? If it was, its contents are sitting in Git's object database as a dangling blob and git fsck will find it. If it was never staged and never committed, Git genuinely never saw the file and cannot help — but your editor's local history almost certainly can.

Read the fix →
← All Git Rescue guides