Skip to main content
DevOps Insightsguides & answers

Git · troubleshooting

fatal: could not read Username for 'https://github.com': terminal prompts disabled

Git needed a username and password for an https:// repository, had none stored, and was not allowed to ask. Usually a CI job with no credentials for that repository, a private or misspelt repository URL, or a script running without a terminal.

Reproduced on Git 2.50.1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 9 sections

Before you start

  • The repository URL the command used, and where it ran (a terminal, a script, a CI job).

Run this first

step 1 of 1
GIT_TERMINAL_PROMPT=0 git ls-remote URL HEAD

Look for A commit hash (access works) or this same error (credentials, URL or access)

Asks the server for the repository without prompting, the same way CI does.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Does the URL point at the job's own repository, or another one?

Cause space

3 of 3 still possible

  • A CI job reaches a second private repositoryCommon
  • The repository URL is wrong, or you have no accessCommon
  • This machine has no stored credential for the hostOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    GIT_TERMINAL_PROMPT=0 git ls-remote URL HEAD

    Asks the server for the repository without prompting, the same way CI does.

    Look for A commit hash (access works) or this same error (credentials, URL or access)

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

A CI job reaches a second private repository

Common

GitHub's GITHUB_TOKEN only has permissions on the repository that contains the workflow. Cloning another private repository, a private submodule or a private Go or npm dependency over https needs a credential that can see it.

Confirm

grep -rn 'github.com/' .gitmodules go.mod package.json 2>/dev/null

An https://github.com/ URL for a repository other than the workflow's own

Fix

  • Check out the other repository with its own token, as the actions/checkout README shows: a second checkout step with repository: org/name and token: ${{ secrets.GH_PAT }}, where the secret holds a token with read access to it.
  • Prefer a fine-grained token or a GitHub App token limited to the repositories the job needs, over a personal token with access to everything.

The repository URL is wrong, or you have no access

Common

GitHub asks for credentials instead of saying "not found" for a repository you cannot see, so a typo, a renamed repository or a missing invitation looks the same as a missing token.

Confirm

git remote get-url origin

A misspelt owner or name, or a repository you can open in the browser only when signed in

Fix

  • Correct the URL with git remote set-url origin URL.
  • If the repository is private, get access to it first; then give Git a credential (next cause).

This machine has no stored credential for the host

Occasional

On a new machine, in a container, or after a credential was removed, there is nothing for Git to send, and in a non-interactive script it cannot ask.

Confirm

git config --show-origin --get-all credential.helper

No helper configured, so Git has nowhere to find a credential

Fix

  • Interactively, configure a credential helper (for example Git Credential Manager or your OS keychain) and sign in once with a token; GitHub no longer accepts account passwords for Git.
  • Or switch the remote to SSH with a key that has access.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

When a server says a repository needs signing in, Git asks its credential helper and then, as a last resort, prompts you in the terminal. In CI or a background script there is no terminal, or prompting is switched off, so Git stops with this message instead. The real question is why the server asked: a missing credential, or a repository you cannot see.

Words used on this page

Credential helper
A program Git asks for stored credentials, such as a keychain or Git Credential Manager.
GIT_TERMINAL_PROMPT=0
An environment variable that stops Git from prompting; CI systems often set it so a job fails instead of hanging.
GITHUB_TOKEN
The token GitHub Actions gives each workflow run. Its permissions are limited to the repository the workflow belongs to.
What is actually happening

Reproduced with Git 2.50.1 on macOS and Git 2.43.0 on Ubuntu 24.04, with every stored credential switched off. With GIT_TERMINAL_PROMPT=0, as CI systems set it, both printed "fatal: could not read Username for 'https://github.com': terminal prompts disabled" and exited 128. With no terminal at all, the ending changes: "Device not configured" on macOS and "No such device or address" on Linux. Same failure, different wording.

The test used a repository URL that does not exist, and GitHub still asked for a username rather than answering "not found": it does not reveal whether a repository you cannot see exists. So this message can mean a wrong URL or a private repository just as well as a missing token. A public repository answered without any credentials.

How to tell this is your problem
WhereWhat you see
CI job, GIT_TERMINAL_PROMPT=0fatal: could not read Username for 'https://github.com': terminal prompts disabled
Script without a terminal, Linuxfatal: could not read Username for 'https://github.com': No such device or address
Script without a terminal, macOSfatal: could not read Username for 'https://github.com': Device not configured

How to know it is actually fixed

  • The clone or fetch completes in the same environment where it failed, without prompting.

Stopping it happening again

  • Give each CI job only the credentials for the repositories it reads, through the checkout action or a credential helper, never in a URL.
  • Set GIT_TERMINAL_PROMPT=0 in scripts too, so a missing credential fails fast instead of hanging on a prompt nobody sees.

Security considerations

  • Do not put a token in the clone URL (https://TOKEN@github.com/…): it ends up in the repository's config, shell history and, often, CI logs. Pass it through the checkout action's token input or a credential helper.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next