# Git LFS clean filter slow / stalls commit in CI

> Fix slow Git LFS clean-filter behavior in CI - committing or checking out many large files runs the clean/smudge filter serially and can stall a job.

Source: https://latchkey.dev/learn/command-reference/git-lfs-clean-filter-slow-in-ci  
Updated: 2026-06-30

The LFS clean filter hashes and stores each large file when it enters the index. On a job that adds or checks out many big files, this serial work can dominate runtime and look like a stall.

## Using this in CI

CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.

```.github/workflows/ci.yml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0   # history, tags, and git describe all need this

- run: |
    git rev-parse --is-shallow-repository   # expect false
    git rev-parse --abbrev-ref HEAD          # prints HEAD when detached
```

> `git rev-parse --abbrev-ref HEAD` returns the literal string `HEAD` on a detached checkout rather than a branch name. On GitHub Actions read `github.ref_name` instead; the git command cannot know what it was checked out for.

## FAQ

### What causes Git LFS clean filter slow / stalls commit in CI?

There are 2 common causes: many large files processed one at a time and no object cache between runs. The clean filter runs per file; a large batch of big objects serializes the hashing and storage work.

### How do I fix Git LFS clean filter slow / stalls commit in CI?

There are 2 fixes depending on which cause you have: cache lfs objects and raise concurrency and fetch only what the job needs. Work through them in order, since the first is the most common.

### What does Git LFS clean filter slow / stalls commit in CI actually mean?

A commit or checkout step in CI takes far longer than expected while LFS processes files, with little log output between "Filtering content" lines.

### How do I stop Git LFS clean filter slow / stalls commit in CI happening again?

Cache .git/lfs between CI runs. The prevention section lists 3 changes that keep it from recurring.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt