Background status fetch triggers a macOS Keychain password prompt through git-credential-osxkeychain and retries it every 15 minutes

[josephv123]

What happened

After Homebrew upgraded git, macOS started asking for the login password on behalf of git roughly every 10-15 minutes, usually right after switching back to T3 Code. It was a Keychain prompt; the exact dialog text wasn't captured.

Diagnosis

The prompt comes from the background status fetch (GitVcsDriver.fetchRemoteForStatus) on a project whose origin is a private GitHub repo over HTTPS, with credential.helper=osxkeychain (Homebrew's /opt/homebrew/etc/gitconfig sets this by default).

1. A saved Keychain item only trusts the app that created it. Homebrew upgraded git to 2.55.0 earlier that day, which replaced git-credential-osxkeychain, so macOS now asks for the login password before releasing the github.com credential. That part is normal macOS behavior.
2. STATUS_UPSTREAM_REFRESH_ENV sets GCM_INTERACTIVE, GIT_ASKPASS, GIT_TERMINAL_PROMPT, SSH_ASKPASS and SSH_ASKPASS_REQUIRE (from [codex] Make background VCS fetch non-interactive #3133, for [Bug]: Github login popup keep opening multiple times repeatedly in desktop app, UX is getting very bad due to this #2874). None of them affect this dialog, because it comes from the macOS Security framework rather than from git. So a background poll still produces a system password dialog.
3. The fetch is killed after 5s (STATUS_UPSTREAM_REFRESH_TIMEOUT). That isn't enough time to notice a dialog and type a password, and every attempt on this machine timed out.
4. Failures back off from 30s up to 15 minutes and never stop, so the prompt keeps coming back. Window focus triggers a refresh ([Bug]: Window focus runs git fetch even with Git fetch interval set to 0 #13235), so it tends to land right when the user returns to the app.

Public repos fetch without credentials, which is why only the private project prompts. A public-repo project on the same machine fetched fine throughout.

Checked against v0.0.42 and current main: the env, the 5s timeout and the 15-minute cap are unchanged. #13812 (--no-auto-gc) doesn't touch this path.

Possible directions: after a few consecutive timeouts, stop polling that remote and show that the background fetch needs attention, instead of retrying forever. Or run background status fetches without credential helpers that can open a GUI.

Steps to reproduce

Derived from this machine's traces and config; not re-run from a clean setup.

1. On macOS, use Homebrew git with the default credential.helper=osxkeychain.
2. Clone a private GitHub repo over HTTPS so git saves the token to the login keychain.
3. brew upgrade git, so git-credential-osxkeychain is replaced by a new binary.
4. Add the repo as a T3 Code project and open a thread in it.
5. Switch to another app for more than 15s, then switch back.
6. macOS asks for the login password on behalf of git-credential-osxkeychain. GitVcsDriver.fetchRemoteForStatus fails with Git command timed out after 5s, and the dialog returns on later refreshes, at most 15 minutes apart.

Version

0.0.42 (desktop app)

Environment

macOS 26.2 (25C56) arm64, desktop app running the server, git 2.55.0 (Homebrew), gh 2.101.0

Evidence

server.trace.ndjson, GitVcsDriver.fetchRemoteForStatus (local time):
  22:43:36  <private-repo>  5007ms  Failure  Git command timed out.
  23:01:12  <private-repo>  5007ms  Failure  Git command timed out.
  23:17:18  <private-repo>  5007ms  Failure  Git command timed out.
  23:44:24  <private-repo>  5008ms  Failure  Git command timed out.
  Same window, <public-repo>: every fetch succeeded in 216-660ms.

Homebrew installed git 2.55.0 at 20:04 the same day. Traces before 22:16
have rotated out, so the first failure isn't captured.

Workaround check, the driver's exact env after `gh auth setup-git`:
  GCM_INTERACTIVE=never GIT_ASKPASS= GIT_TERMINAL_PROMPT=0 SSH_ASKPASS= \
  SSH_ASKPASS_REQUIRE=never git fetch --dry-run --quiet --no-tags origin
  -> exit 0, 0.62s, no dialog

Related issues

#11930 is the same gap in STATUS_UPSTREAM_REFRESH_ENV, but for a GUI SSH agent on the worktree bootstrap fetch. #2874, fixed by #3133, is the Git Credential Manager version; the Keychain helper isn't covered. #13235 explains why the prompt lands on window focus. None of them covers git-credential-osxkeychain or the poller retrying a prompting fetch indefinitely.

Fix applied or workaround

Ran gh auth setup-git, so git gets github.com credentials from gh auth git-credential instead of the Keychain helper. Verified under the driver's env (see Evidence). Alternative: run git fetch once in a terminal and click Always Allow, though that comes back after the next git upgrade.

Filed by

Claude Code (claude-opus-5-5), following .github/triage/PLAYBOOK.md from a T3 Code thread

[juliusmarminge]

Triage

Confirmed on main at cb97415948. A background upstream refresh still runs git-credential-osxkeychain for a private HTTPS remote, the 5s timeout kills that attempt before the login-keychain dialog can be approved, and the failure is retried forever.

fetchRemoteForStatus is the poll. It runs git --git-dir <common-dir> fetch --quiet --no-tags --no-auto-gc <remote> with STATUS_UPSTREAM_REFRESH_TIMEOUT (5s) and STATUS_UPSTREAM_REFRESH_ENV (GCM_INTERACTIVE=never, empty GIT_ASKPASS, GIT_TERMINAL_PROMPT=0, empty SSH_ASKPASS, SSH_ASKPASS_REQUIRE=never). Those variables cover Git Credential Manager, terminal prompts, and OpenSSH askpass. They do not cover credential.helper, which Homebrew's gitconfig sets to osxkeychain. The helper is merged in via extendEnv, and the Security-framework dialog is raised by the helper binary, not by git's askpass. The evidence command was git fetch --dry-run --quiet --no-tags origin. The live command has no --dry-run. #13812 did change this function: it added --no-auto-gc. That does not affect credentials.

A timed-out fetch is cached and backed off from 30s, doubling each time, capped at 15 minutes (statusUpstreamRefreshFailureCooldown). The count never resets except on success, and nothing stops the remote from being polled again. The ~16 minute trace gaps match that cap. The longer gap fits the poller not running while no client lease allows vcs-status work.

Window focus does not skip that cache. GitActionsControl focus and visibilitychange call vcs.refreshStatus, which invalidates the GitManager status cache and then statusDetailsRemote → refreshStatusUpstreamIfStale. The driver's statusRemoteRefreshCache is left alone, so a refocus only fetches again once the cooldown has expired. "Switch away for 15s" is the success-path TTL (STATUS_UPSTREAM_REFRESH_INTERVAL). After a timeout the next attempt waits at least 30s. That matches the report landing on return to the app, not a fetch on every focus. The 5s kill also cancels the helper before Always Allow can be stored, so answering the dialog during a background fetch does not stick.

Not a duplicate. #2874 / #3133 added this env for Git Credential Manager. #11930 (and #11946) is the GUI SSH agent on the 30s worktree bootstrap fetchRemote, not this poll. #13235 is why focus still calls refreshStatus when the fetch interval is 0. None of them stop osxkeychain or cap these retries.

Do not clear credential.helper on every background fetch. That would also drop silent keychain and gh auth git-credential success, so ahead/behind on private HTTPS repos would freeze. STATUS_UPSTREAM_REFRESH_ENV is shared with explicit fetchRemote, so changing the env object would change user-initiated fetch too. Explicit pull is separate: git pull --ff-only with a 30s timeout and without this env, though it does call statusDetails first and that still hits this poll.

Stop retrying a remote after repeated background-fetch timeouts and surface that upstream status needs attention. A keychain item that unlocks without UI keeps updating. An explicit pull can still present the dialog long enough to click Always Allow.