Skip to content
Latchkey

Clojure private git deps (GITLIBS) auth failure in CI

tools.deps clones :git/url dependencies into the GITLIBS directory (default ~/.gitlibs). For a private repository the clone needs credentials, and a fresh runner has none, so the fetch fails with a git authentication or permission error.

What this error means

clj fails resolving a private git dependency with "Permission denied (publickey)" or "fatal: Authentication failed" while cloning the :git/url.

clj
Cloning: https://github.com/example/private-lib.git
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Error building classpath. Unable to clone io.github.example/private-lib

Common causes

No credentials for the private repository

The runner has no token or SSH key with read access, so the non-interactive git clone into ~/.gitlibs cannot authenticate.

A URL scheme that does not match the available auth

An SSH :git/url with only an HTTPS token available (or the reverse) means git cannot use the credentials that exist.

How to fix it

Inject an HTTPS token via git config

Rewrite HTTPS GitHub URLs to include a CI token so private clones authenticate non-interactively.

.github/workflows/ci.yml
git config --global url."https://${{ secrets.GH_TOKEN }}@github.com/".insteadOf "https://github.com/"
clojure -P

Provide an SSH deploy key

For SSH :git/url coordinates, load a read-only deploy key into the agent before resolution.

.github/workflows/ci.yml
- uses: webfactory/ssh-agent@v0.9.0
  with:
    ssh-private-key: ${{ secrets.CLJ_DEPLOY_KEY }}

How to prevent it

  • Match the :git/url scheme (HTTPS vs SSH) to the credentials CI provides.
  • Store git tokens and deploy keys in CI secrets, never in deps.edn.
  • Cache ~/.gitlibs so an authenticated clone is reused across runs.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →