Andy Garcia · freelance dev
FRENES
Back to the blog
DevOps & CI

GitHub Now Says Some Anonymous Public Repo Clones May Fail. CI Users Reported It on September 2.

October 19, 2026 8 min read

On Monday, October 19, GitHub posted a short changelog entry with a long tail: "During periods of unusual traffic, GitHub may temporarily require authentication for some clones and fetches of public repositories over HTTPS to help protect github.com's availability." An affected operation "will fail with a message indicating that authentication is required."

Authenticated Git over HTTPS, Git over SSH, pushes and unrelated web and API traffic are not affected. The protection applies to repositories on github.com across all plans. GitHub did not say how often it expects to switch it on, or for how long.

The entry is new. The behavior is not. On September 2, a GitHub Community discussion titled "Unauthenticated clone of a public repo intermittently returns 401 (prompts for Username) from CI workers" opened with a team whose Docker-based CI workers clone the public MariaDB/server repository over HTTPS with no credentials. Other users reported the same symptom on CI runners, on Homebrew updates and on TrueNAS app catalogs. On September 3, a GitHub Community Admin replied that GitHub had "expanded our traffic protections for unauthenticated requests" and that, when they apply, "we now return 401 signaling Git to retry with authentication if it has credentials available." The October 19 entry does not link to that thread, but it describes the same outcome: an anonymous clone refused with a request to authenticate.

Read quickly, it sounds like a non-event: public repositories stay public, and you can wait and retry. Read by someone who ships software, it says something sharper. Any build step that clones a public repository without credentials can now fail with no change on your side, intermittently, and with an error message that can point at the wrong cause.

In September I wrote about where your code lives when GitHub goes down. This is the quieter version of the same question: GitHub stays up, and your build is the one that stops.

What the post actually commits to

Three sentences carry the policy. GitHub "applies this protection as narrowly as possible using signals associated with anomalous traffic." It concedes that "legitimate unauthenticated operations may occasionally be affected." And it adds: "This is not a general authentication requirement for public repositories."

So nothing is promised in either direction. Your anonymous clone is not the target, but it is not shielded either. And "all plans" means that paying for GitHub does not exempt a runner that does not say who it is.

GitHub does not say what the unusual traffic is. On May 8, 2025, when it updated the rate limits for requests made without authentication, "cloning repositories over HTTPS" included, it cited "an increase in scraping activity targeting our API" and encouraged everyone to authenticate. Seventeen months later, the advice is the same, and anonymous clones now carry an explicit warning that they may simply fail.

Why your laptop will be the last to know

By default, Git does not send credentials until the server asks for them. GitHub's September 3 reply put it this way: "in most cases Git will attempt all requests without authentication first, and only authenticate if it receives a 401 response." The gitcredentials manual says Git "may need to ask for a username and password in order to access a remote repository over HTTP," and it tries configured credential helpers before falling back to a prompt on the terminal.

On a developer machine, a helper often already holds a GitHub token. GitHub's own docs recommend GitHub CLI or Git Credential Manager to remember HTTPS credentials. When GitHub demands authentication, the helper answers, the clone goes through, and nobody notices.

A CI runner, a Docker build or a fresh agent sandbox usually has no helper and nobody at the keyboard. Where GIT_TERMINAL_PROMPT is set to false, Git "will not prompt on the terminal (e.g., when asking for HTTP authentication)," and the step simply fails. The protection lands where you are least likely to be watching: the scheduled job, the deploy that runs at night.

Then comes the debugging. The Cargo Book's page on Git authentication says: "Cargo does not require authentication for public git dependencies so if you see an authentication failure in that context, ensure that the URL is correct." That is still true about Cargo. It is no longer the whole story about GitHub. An authentication error on a public dependency can now mean the URL is fine and the protection is on.

Where anonymous clones hide

I orchestrate my work with Claude Code, and the first thing I would hand an agent here is a search: every github.com URL in the files that build things. This is the list I would give it, with what each tool's own documentation says.

GitHub Actions. actions/checkout authenticates the checkout of your own repository by default: its token input defaults to the job's github.token. The question is every other clone in the workflow: a run step with git clone, a script that builds a tool from source, a package manager resolving a Git dependency.

Dockerfiles. A RUN git clone line against a github.com URL is anonymous unless you made it otherwise. Docker's documentation is blunt about the tempting fix: "Build arguments and environment variables are inappropriate for passing secrets to your build, because they persist in the final image." Use a secret mount instead. For a Git repository used as the build context or fetched with ADD, BuildKit has two predefined secrets, GIT_AUTH_TOKEN and GIT_AUTH_HEADER.

Package managers. npm accepts git+https URLs as dependencies and, given a commit, will "clone exactly that commit." Cargo resolves Git dependencies itself and "does not ask for passwords": HTTPS authentication goes through a Git credential helper you set up beforehand. Terraform, for modules hosted on GitHub, "clones and uses the default branch referenced by HEAD." Go is a partial exception. GOPROXY defaults to proxy.golang.org with a fallback to direct, so public modules normally arrive through the proxy. But a module matched by GOPRIVATE, or a 404 or 410 from the proxy, sends the go command to the version control system itself.

Swift packages. Apple's guide to building Swift packages in continuous integration says a project that depends only on public packages needs no additional configuration. It also says xcodebuild "uses Xcode's built-in Git tooling," and only uses your Mac's Git installation and configuration if you pass -scmProvider system. So a credential helper in your Git config may never reach it. For packages that need authentication, Apple's advice is SSH Git URLs with SSH credentials, and SSH is on GitHub's unaffected list.

Submodules, cron jobs and agents. A .gitmodules file with HTTPS URLs, a nightly script that clones a dataset, an install script, a coding agent that clones a library into a scratch directory to read its source: all of them are anonymous HTTPS clients unless someone configured them otherwise.

The fix, environment by environment

GitHub's recommendations are short. In GitHub Actions, use the built-in GITHUB_TOKEN. In other CI systems, "prefer a GitHub App installation access token"; a personal access token also works. Operations that cannot authenticate should retry after the temporary protection has been lifted.

On a machine that already holds credentials, Git's http.proactiveAuth setting makes it "attempt authentication without first making an unauthenticated attempt and receiving a 401 response." GitHub's September 3 reply named it, with SSH, as the two ways to force authentication.

Three details change how you wire it.

Token lifetimes. An installation access token "will expire after 1 hour." The GITHUB_TOKEN lives until the job finishes, up to 6 hours on GitHub-hosted runners. If a pipeline mints one App token at the start and a later stage clones at minute 70, that token has been dead for 10 minutes. Mint a token per stage, or let a library do it: GitHub notes that its Octokit SDKs regenerate the token once it expires.

Scope. On the personal access token route, GitHub's docs say fine-grained tokens "always include read-only access to all public repositories on GitHub." The narrowest fine-grained token you can create already reads public code. There is no reason to hand a build a classic token with broad scopes for this.

Retries. Retrying once the protection lifts is GitHub's own advice for anything that cannot authenticate, so a bounded retry with backoff around clone steps is reasonable. Keep it bounded, and log the message. An authentication error on a public repository is now a signal worth counting, not noise to swallow.

The audit I would run

As a CTO who also ships iOS apps and a strategy game on my own, I would treat this as a one-afternoon audit, not a project.

First, the inventory: workflow files, Dockerfiles, package.json, Cargo.toml, go.mod and any GOPRIVATE setting, .gitmodules, Terraform module sources, and the Package.resolved file of each Xcode project, where Xcode records every package dependency.

Second, authenticate what ships: GITHUB_TOKEN in Actions, an App token minted per stage elsewhere, a secret mount in Docker, SSH or -scmProvider system for xcodebuild.

Third, cut the number of clones. Caching dependencies between runs, where the toolchain allows it, means fewer trips to GitHub, and a clone you do not make cannot be refused.

Fourth, make the failure legible. Add a line to the runbook: an authentication error on a public GitHub repository means check credentials and GitHub's changelog first, then the URL.

Public repositories are still public. What changed on October 19 is that anonymous access is now explicitly best effort, and a build that cannot say who it is will find out on GitHub's busiest day, not yours.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk