Public GitHub Clone Suddenly Requires Authentication: What to Change in CI
A CI job cloning a public GitHub repo sometimes dies on a credential prompt no one is there to answer. Why is a public repo asking for a login?
- A public repository can temporarily require authentication for an HTTPS clone or fetch.
- Configure credentials for the Git process on your laptop or CI worker.
- Persistent failures still warrant checking the URL, permissions and cached credentials.
Public visibility does not guarantee an anonymous transfer
A credential prompt does not necessarily mean the repository became private. GitHub’s October 19 announcement describes temporary authentication requirements for some public HTTPS clones and fetches during unusual traffic. Affected operations can authenticate and retry, or wait until the protection ends.
Authenticated HTTPS operations, SSH Git, pushes and unrelated web or API traffic are outside this protection. It is not a universal login requirement.
The practical problem is sharper on unattended workers. In a GitHub Community discussion, a developer reported intermittent failures while cloning the public MariaDB repository from CI, including a disabled-terminal-prompts error. That is a user report, but the situation is recognizable: a job expecting anonymous access has no person available to answer a credential prompt.
Connect your local Git client to a credential helper
With GitHub CLI installed, the documented login flow starts with gh auth login. Choose HTTPS for Git operations and agree to authenticate Git with those credentials.
gh auth login
gh auth setup-git
git clone https://github.com/OWNER/REPOSITORY.gitReplace the owner and repository placeholders. The second command explicitly configures gh as Git’s credential helper; it requires an authenticated host. This connects an existing login to Git rather than creating a login by itself.
Resetting an account password is not the relevant fix. HTTPS Git authentication uses tokens or a credential helper, not the account password. Git Credential Manager is another supported way to manage that connection.
Make sure the clone actually receives credentials
In GitHub Actions, actions/checkout defaults its token input to the built-in token and recommends contents: read for ordinary checkout. Inspect the failing step: a configured checkout and a separate anonymous shell clone are different operations.
| Environment | Authentication path |
|---|---|
| Developer machine | GitHub CLI or Git Credential Manager supplies Git credentials. |
| GitHub Actions | Check the checkout token input and read permission. |
| Other CI | GitHub recommends an App installation token; a personal access token is also possible. |
The built-in Actions token is created for a job and has permissions limited to its repository. Checking out another private repository requires credentials with access to that target. An environment variable containing a token is not, on its own, proof that an arbitrary Git command consumes it. The checkout action or helper must connect the credential to the operation.
A continuing failure needs a separate diagnosis
GitHub’s cloning troubleshooting guide also points to incorrect URLs, missing access and stale cached credentials. Those explanations remain relevant after authentication is configured. An existing SSH setup offers another route, but changing a remote URL does not create the required SSH credentials.
Start with the exact failing step and its authentication method. For an unattended public clone, the useful change is a working credential path all the way to Git—not merely a successful login elsewhere on the machine.