Git LFS Pull Timeout on Large Objects in CI

A Git LFS download stalled long enough to hit the client’s activity timeout and aborted. Large objects over a slow runner link are the usual trigger, and the same pull typically completes on a retry or with a higher timeout.

What this error means

A git lfs pull or LFS checkout hangs on a large file and then fails with a client timeout. It is intermittent - re-running usually succeeds, and it is worse for the biggest objects.

git lfs output

Downloading assets/dataset.tar (3.4 GB)
LFS: Client error: timeout awaiting response headers
error: failed to fetch some objects from
'https://github.com/org/repo.git/info/lfs'

Common causes

A large object over a slow link

Multi-gigabyte LFS objects on a congested CI network can stall past the default client activity timeout, aborting the transfer before it completes.

Too little retry/timeout headroom

The default LFS activity timeout and retry count are tuned for typical files; very large objects on a flaky network exceed them.

How to fix it

Raise the LFS timeout and retries

Give large transfers more time and more attempts.

Terminal

git config --global lfs.activitytimeout 300
git config --global lfs.transfer.maxretries 5
git lfs pull

Cache LFS objects between runs

Persist the LFS object store so most jobs reuse local objects instead of re-downloading huge files.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: .git/lfs
    key: lfs-${{ hashFiles('.lfs-assets-id') }}

How to prevent it

Cache LFS objects keyed on the LFS file list.
Raise lfs.activitytimeout for repos with very large objects.
Fetch only the LFS paths a job needs to cut transfer volume.