Git: Unable to create index.lock File exists

Fix Git index.lock errors by confirming no Git process is running, then removing a stale lock left by an interrupted command.

beginnerdebugginggitversion-control

Symptoms

fatal: Unable to create '.git/index.lock': File exists
A Git command fails after an editor or CI job was interrupted
Every Git command fails until the lock is removed

Possible causes

Another Git process is genuinely running against the repository
A previous Git command was killed and left the lock behind
An editor or GUI tool holds the repository locked
A crash during a merge or rebase abandoned the lock file

Diagnosis steps

Check for a running Git process

ps aux | grep "[g]it"

Interpretation

An active process means the lock is legitimate and you should wait, not delete.

Confirm the lock is stale

Interpretation

If no Git process runs and the command still fails, the lock is leftover from an interrupted operation.

Inspect the repository state after removing it

git status

Interpretation

After deleting a stale lock, status should be consistent; leftovers may indicate a partial merge or rebase.

Root cause

Git writes an index.lock file while modifying the index and removes it when finished. If the process is interrupted by a crash, a kill, or a full disk, the lock remains, and Git refuses further index writes to avoid corruption. The lock is a safety mechanism, so deleting it while another process is active risks a corrupted index.

Fix

First ensure no Git process is actually running, then remove only the stale lock with rm .git/index.lock and rerun the command. After a killed merge or rebase, run git status and reset or continue the operation as needed. Avoid running concurrent Git commands against one repository, and fix disk-full conditions that cause the crash.

Verify the fix

Run git status and the command that failed; both succeed, and no index.lock is recreated unexpectedly, confirming the lock was stale and the repository is healthy.

Symptoms

Git refuses to run with Unable to create '.git/index.lock': File exists. It affects commands that write the index, and every attempt fails the same way until resolved.

Diagnosis

Verify no Git process is active before touching the lock:

ps aux | grep "[g]it"
ls -la .git/index.lock

If no process runs and you recently killed a Git command, the lock is stale.

Fix

Remove only a stale lock:

rm .git/index.lock
git status

If a merge or rebase was interrupted, inspect the state and continue or abort:

git merge --abort

Verification

Run git status and the original command; both succeed and no index.lock reappears, confirming the leftover lock is gone and the repository is consistent.

When the Lock Is Legitimate

The lock is not a bug; it is how Git prevents two writers from corrupting the index. An IDE performing an automatic fetch, a background Git process started by a tool, or a second terminal running a commit all take the lock briefly and legitimately. Deleting the lock while one of those is active can corrupt the index and lose staged changes. The safe habit is always to check for a running process first, wait a moment and retry, and only remove the file once you are certain no process owns it. Long-running operations such as a large rebase also hold the lock for the whole operation, so patience beats deletion.