GitHub Actions · Checked November 3, 2026

GitHub Actions: "fatal: could not read Username for 'https://github.com'"

git had no credential for that request, tried to ask for a user name, and there is no one to ask in a CI job. If the line above it says warning: redirecting to, the token was there and git threw it away; that started in October 2026 and is the first section. Without that line, see "Other causes".

What it looks like

warning: redirecting to https://github.com/<org>/<repo>/
fatal: could not read Username for 'https://github.com': terminal prompts disabled

From runner-images #15014. The text after the last colon varies with how git was started: "terminal prompts disabled" with GIT_TERMINAL_PROMPT=0, "No such device or address" without a terminal. A push may add failed to push some refs; git ls-remote adds fatal: expected flush after ref listing.

1. A token in the URL, dropped after a curl security update

No redirect happened. Ubuntu's bug 2171054 explains it:

• The fix for curl's CVE-2026-94266 (curl 8.23.0, and Ubuntu's 8.5.0-2ubuntu10.16 on 24.04 and 7.81.0-1ubuntu1.30 on 22.04) makes libcurl report the URL it fetched with the user name and password removed.
• git up to 2.56.0 compares that with the URL it asked for as plain text, decides it was redirected, prints the warning with the credentials stripped (hence the extra / at the end) and starts over from that URL, which has no token.
• Anything that writes the token into the URL is hit: https://${TOKEN}@github.com/... as a remote, url.<base>.insteadOf rules, and tools that build such URLs, such as semantic-release (semantic-release #4321) or pr_comet (pr_comet #505).

Where it shows up:

• GitHub-hosted Ubuntu runners. GitHub reproduced it on Ubuntu 22.04, 24.04 and 26.04 and ubuntu-slim, and decided on October 22 to roll the images back. A comment there reports the same on Azure Pipelines' Microsoft-hosted Ubuntu agents (the same message on Azure DevOps). The ubuntu-24.04 image released on October 26 (20261026.354) lists curl 8.5.0-2ubuntu10.16 and Git 2.56.0, and the fix to git (76524c2604, September 28) is not in 2.56.0. The Docs workflow of commonmark failed this way on its October 26 nightly (commonmark #1167).
• Containers and self-hosted machines with the new curl and an older git. Ubuntu's own git packages carry the fix since October 19 (1:2.43.0-1ubuntu7.4 on 24.04, 1:2.34.1-1ubuntu1.18 on 22.04), so apt-get install git from Ubuntu is fine. The git-core PPA's 2.56.0 build of October 23, which the runner images use, lists only the new upstream release.

Do not rotate the token first. PX4's sync job failed from October 19, the token was suspected (PX4 #29520), and the real fix needed no new token (PX4 #29528).

What works now

• Give git the token through a credential helper instead of the URL. PX4 now clones without credentials and lets gh answer:

  - run: |
      gh auth setup-git
      git clone https://github.com/owner/private-repo.git
    env:
      GH_TOKEN: ${{ secrets.PRIVATE_REPO_TOKEN }}

  The token stays out of the command line and out of .git/config.
• Send it as a header. actions/checkout already does this, so its own fetch is not affected, and for your own repository its token: input covers later pushes too. For other commands:

  git -c http.https://github.com/.extraheader="AUTHORIZATION: basic $(printf 'x-access-token:%s' "$TOKEN" | base64 -w0)" \
    clone https://github.com/owner/private-repo.git

• As a quick change, put the token in the password slot: https://x-access-token:${TOKEN}@github.com/. GitHub's runner image team found that this worked on every image where the token-as-user-name form failed, and Gradle switched its update script to it (gradle #39697). Ubuntu's bug report shows a user-and-password URL failing against another kind of server, so prefer one of the two above for anything you keep.

Holding back the curl packages also makes it go away, and leaves the security fix out.

Other causes (no "redirecting to" line)

• The checkout saved no token. With persist-credentials: false, a later git fetch or git push has nothing to send; public repositories still fetch anonymously, so it fails only on private and internal ones (tooling-configs #76).
• Another private repository: a Go module, a git dependency or a submodule. GITHUB_TOKEN only reaches the workflow's own repository, so the job needs a token for the other one (spectrum-x-operator #355).
• An empty secret. Runs from forks get no secrets, and Dependabot runs get only Dependabot secrets, so https://${TOKEN}@github.com/ becomes a URL with no token.

Telling it apart

• remote: Permission to owner/repo.git denied to github-actions[bot] with a 403: git did send a token, and it could not write ("Permission to ... denied to github-actions[bot]").
• refusing to allow a GitHub App to create or update workflow: the token was sent, and the push changes a workflow file ("refusing to allow a GitHub App to create or update workflow").

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Permission to ... denied to github-actions[bot]" · "refusing to allow a GitHub App to create or update workflow" · "The ubuntu-latest label will migrate to Ubuntu 26" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語