Investigate gh-backed HTTPS credential helper as a managed, cross-platform git auth strategy

[kelchm]

Background

On 2026-08-03, gh auth setup-git was run on the primary macOS machine — almost certainly by a coding-agent session working around git SSH failures while 1Password was locked (1Password provides both the SSH agent and commit signing here, so a locked vault fails SSH operations). It wrote the following directly into the home ~/.gitconfig, outside chezmoi management:

[credential "https://github.com"]
    helper =
    helper = !<mise-install-path>/gh_2.96.0_macOS_arm64/bin/gh auth git-credential
[credential "https://gist.github.com"]
    helper =
    helper = !<mise-install-path>/gh_2.96.0_macOS_arm64/bin/gh auth git-credential

Two problems with the as-written state:

• It's unmanaged, so chezmoi apply silently deletes it (this has since happened / will happen — SSH remotes, the normal path, are unaffected).
• The helper path is pinned to a specific gh version inside mise's install directory, so it dangles on the next gh upgrade.

PR #12 briefly templated a portable form (helper = !gh auth git-credential) into dot_gitconfig.tmpl, then reverted it: blessing a one-machine workaround without thinking it through isn't the move.

Question to investigate

Should gh-backed HTTPS credential auth be a deliberate, managed part of the git config — and if so, how, on every platform?

Points to work through:

• Interplay with 1Password. SSH (auth + signing) via 1Password is the primary path on macOS/Windows. Is the actual problem "agents need git to work while the vault is locked"? If so, is an HTTPS fallback the right fix, or should the fix be on the SSH/agent side (e.g. unattended-friendly key handling for agent sessions)?
• Cross-platform shape. gh is already a managed package everywhere (Brewfile on macOS, GitHub.cli in winget.json on Windows). Windows currently uses credential.helper = manager — would gh take over github.com/gist there, with manager remaining the fallback for other hosts? What does Linux look like?
• Helper form. PATH-based !gh auth git-credential vs. absolute paths; behavior in non-interactive/GUI contexts where PATH may differ.
• Auth bootstrap. gh auth login is per-machine state — document it as a setup step, or is there a sane check in a run_onchange script?
• Scope. github.com + gist.github.com only, or a general policy for HTTPS remotes?

Outcome

Either a managed, templated credential config that works identically on macOS/Windows/Linux, or an explicit decision to stay SSH-only and let HTTPS failures surface loudly.

🤖 Generated with Claude Code