GitHub may now ask anonymous HTTPS clones to authenticate

GitHub changed how it protects itself during traffic spikes on 19 October. During periods of unusual traffic, it can now temporarily require authentication for clones and fetches of public repositories over HTTPS, something that has always worked anonymously. An affected request fails with an authentication prompt; retrying later without credentials, or authenticating immediately, both work.

GitHub says it applies the protection narrowly, based on traffic anomaly signals, and that it is temporary rather than a permanent policy change. SSH clones, authenticated HTTPS, pushes and other GitHub traffic are unaffected. For anything automated, GitHub’s advice is to stop relying on anonymous HTTPS: use the built-in GITHUB_TOKEN inside Actions, or a GitHub App installation token or personal access token elsewhere.

env:
  GIT_ASKPASS: echo
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Why it matters: a lot of scripts, Dockerfiles and CI steps do a plain git clone https://github.com/... on a public repo because it has always just worked. This measure means that assumption can fail intermittently and without warning, during exactly the high-traffic windows when you most need the build to succeed. Anything unattended that clones a public GitHub repo over HTTPS is worth auditing for a token now, rather than after it fails during an incident.

The caveat: GitHub hasn’t published the traffic thresholds that trigger this, so there’s no way to know in advance whether a given pipeline is at risk, only that it is possible.