Git Credential Manager with two github.com accounts: the account picker hangs non-interactive git

Observed November 2026 on Windows 11, using Git Credential Manager (GCM) and the GitHub CLI (gh). Versions were not recorded. Account names are replaced with generic labels.

Symptom

Git operations over HTTPS to github.com, run by automated scripts and agent shells, stalled or failed:

• a git pull --rebase run by a hook at the start of every agent session logged pull timed out after 60s;
• git push from an agent shell hung until the tool timed out;
• with terminal prompts disabled, git ls-remote failed with could not read Username;
• one earlier failure was Repository not found on a repository that existed.

A window appeared on screen that looked like a sign-in request. It was an account picker.

Cause

GCM held two stored accounts for github.com (an automation account and a personal account), and the repository had no credential.username set. For each HTTPS operation git ran git-credential-manager get, and GCM could not choose. The GCM trace contained:

Found 2 accounts... Multiple accounts available - prompting user to select one

In a non-interactive shell nobody could see or answer the picker, so git-credential-manager get and the git process above it both stayed alive; both were still running when the session inspected them. Picking the wrong account has a different failure signature: the account without access to a private repository makes GitHub answer Repository not found, not an authentication error. That link was inferred for one earlier failure and the hook log was not checked, so it is labelled likely.

Not established: why the picker was sometimes answered with the wrong account, and which other repositories use github.com.

Fixes

• Per repository, no global change. Pin the account for that repository:

`` git -C <repo> config credential.username <account> ``

or, written against the host, git config --local credential.https://github.com.username <account>. The second form was recorded as applied to a repository, after which a plain git push used that account without prompting. The first form was proposed in the diagnosis session and was not shown applied there.

• One command, no configuration change, for a stalled push from an agent shell (Git Bash):

`` GIT_TERMINAL_PROMPT=0 GCM_INTERACTIVE=never timeout 90 git -c credential.helper= -c credential.helper='!gh auth git-credential' push ``

The empty credential.helper= clears the configured helpers; the second hands the job to gh, which was already signed in. timeout 90 keeps a hang from blocking the session.

• If a hang has already happened, the diagnosis session's advice was to answer the picker or kill the hung git-credential-manager process before retrying.

With prompts disabled by the environment alone, the recorded result was the could not read Username failure above, not a silent success; the one-off command that worked also sets GCM_INTERACTIVE=never and replaces the helper.