Git "RPC failed; curl 18 transfer closed" on Large Clones

By Kaveh Alemi·Latchkey

The clone started successfully but the connection dropped partway through transferring the pack. Large repositories over a flaky or buffered link are the usual trigger, ending in early EOF or index-pack failed.

What this error means

A clone of a large repository gets some way through "Receiving objects" then dies with RPC failed; curl 18 transfer closed and early EOF / fetch-pack: unexpected disconnect. Small repos clone fine; the big one fails, often at a different percentage each time.

git clone output

remote: Enumerating objects: 482931, done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
error: 7423 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: index-pack failed

Diagnose it: depth, refs, or credentials?

CI checkouts are shallow and detached by default, which breaks anything that needs history or a branch name. Before treating it as a credential problem, confirm what the runner actually fetched.

.github/workflows/ci.yml

- run: |
    git rev-parse --is-shallow-repository
    git rev-parse --abbrev-ref HEAD      # prints HEAD when detached
    git log --oneline -3
    git remote -v
    git for-each-ref --format="%(refname)" | head

Common causes

A large pack over an unstable connection

Transferring a multi-gigabyte pack over a network that drops or stalls causes the HTTP transfer to close before completing. The bigger the repo, the more likely a single blip aborts it.

A proxy or buffer truncating the response

An intermediary proxy with a small buffer or an aggressive idle timeout can cut off a long-running pack transfer, producing curl 18.

How to fix it

Shallow-clone to shrink the transfer

Most CI only needs the tip. A shallow clone transfers a fraction of the data and rarely hits the timeout.

Terminal

git clone --depth 1 https://github.com/org/big-repo.git

Raise the HTTP buffer

A larger post buffer lets Git move bigger chunks before flushing, which helps with proxies that choke on long streams.

Terminal

git config --global http.postBuffer 524288000   # 500 MB

Retry, or fetch in stages

Retry the clone - a transient disconnect often succeeds on the next attempt.
Clone shallow, then deepen incrementally with git fetch --deepen 100 if you need more history.
Prefer the SSH remote if HTTPS proxies keep truncating the transfer.

The checkout options that fix most of this

.github/workflows/ci.yml

- uses: actions/checkout@v4
  with:
    fetch-depth: 0        # full history: diffs, tags, git describe
    submodules: recursive # submodules are NOT fetched by default
    persist-credentials: false  # if a later step pushes with its own token

How to prevent it

Use shallow clones in CI unless full history is genuinely needed.
Cache the repository or use a partial clone for very large monorepos.
Raise http.postBuffer on runners that sit behind buffering proxies.

Frequently asked questions

What causes Git "RPC failed; curl 18 transfer closed" on large clones?

There are 2 common causes: a large pack over an unstable connection and a proxy or buffer truncating the response. Transferring a multi-gigabyte pack over a network that drops or stalls causes the HTTP transfer to close before completing.

How do I fix Git "RPC failed; curl 18 transfer closed" on large clones?

There are 3 fixes depending on which cause you have: shallow-clone to shrink the transfer, raise the http buffer, and retry, or fetch in stages. Work through them in order, since the first is the most common.

What does Git "RPC failed; curl 18 transfer closed" on large clones actually mean?

A clone of a large repository gets some way through "Receiving objects" then dies with RPC failed; curl 18 transfer closed and early EOF / fetch-pack: unexpected disconnect.

How do I stop Git "RPC failed; curl 18 transfer closed" on large clones happening again?

Use shallow clones in CI unless full history is genuinely needed. The prevention section lists 3 changes that keep it from recurring.

Can Latchkey fix this automatically?

Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.