Git "error: object file ... is empty" - Corrupt Object in CI

A loose object in the local .git/objects store is zero-length or corrupt. The repository data on disk was damaged - typically a clone or write that was interrupted, or a cached .git directory restored incompletely.

What this error means

Git operations fail with error: object file .git/objects/ab/cdef... is empty and fatal: loose object ... is corrupt. It tends to appear on runners that cache the .git directory or after a clone was killed mid-write.

error: object file .git/objects/4d/7a214614ab2935c943f9e0ff69d22eadbb8f32b is empty
fatal: loose object 4d7a214614ab2935c943f9e0ff69d22eadbb8f32b (stored in
.git/objects/4d/7a214614ab2935c943f9e0ff69d22eadbb8f32b) is corrupt

Common causes

An interrupted clone or write

A clone or fetch killed partway (OOM, timeout, runner termination) can leave a zero-byte object file behind, corrupting the store.

A bad cached .git directory

Caching .git between jobs can restore a partially-written or inconsistent object store, so the next job reads an empty/corrupt object.

How to fix it

Re-clone into a clean workspace

The simplest reliable fix in CI is to discard the damaged checkout and clone fresh.

rm -rf repo
git clone https://github.com/org/repo.git repo

Prune the empty objects and refetch

If you must keep the checkout, remove the empty loose objects and let a fetch repopulate them.

find .git/objects/ -type f -empty -delete
git fetch -p origin
git fsck --full

How to prevent it

• Avoid caching the .git directory; cache build outputs instead.
• Use ephemeral runners or clean the workspace on persistent ones.
• Give clones enough memory/time so they are not killed mid-write.

Related guides