Git "RPC failed; HTTP 400 ... result=22" on Push in CI

By Kaveh Alemi·Latchkey

A push was rejected with HTTP 400 before Git could send the whole pack. The usual cause is a request body larger than a proxy or server allows, so the upload is refused outright.

What this error means

A git push (often the first push of a large history) fails with error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400. Small pushes to the same remote succeed.

git push output

error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

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

Body larger than a proxy/server limit

A reverse proxy in front of the Git host caps request body size. A large pack exceeds it and the proxy returns 400 before the push completes.

Pack chunked in a way the proxy rejects

With a small http.postBuffer, Git uses chunked transfer encoding that some proxies reject with 400; buffering the whole body avoids it.

How to fix it

Raise the HTTP post buffer

A buffer larger than the pack lets Git send a single non-chunked body, which most proxies accept.

Terminal

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

Push less at once or use SSH

Push the history in smaller commit ranges instead of one giant pack.
Switch the remote to SSH, which is not subject to the HTTP body limit.
If you control the server proxy, raise its max request body size.

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

Raise http.postBuffer on runners that push large packs over HTTPS.
Prefer SSH for very large initial pushes.
Keep proxy body-size limits aligned with your largest expected push.

Frequently asked questions

What causes Git "RPC failed; HTTP 400 ... result=22" on push in CI?

There are 2 common causes: body larger than a proxy/server limit and pack chunked in a way the proxy rejects. A reverse proxy in front of the Git host caps request body size.

How do I fix Git "RPC failed; HTTP 400 ... result=22" on push in CI?

There are 2 fixes depending on which cause you have: raise the http post buffer and push less at once or use ssh. Work through them in order, since the first is the most common.

What does Git "RPC failed; HTTP 400 ... result=22" on push in CI actually mean?

A git push (often the first push of a large history) fails with error: RPC failed; HTTP 400 curl 22 The requested URL returned error: 400.

How do I stop Git "RPC failed; HTTP 400 ... result=22" on push in CI happening again?

Raise http.postBuffer on runners that push large packs over HTTPS. The prevention section lists 3 changes that keep it from recurring.