fix(repo-hygiene): keep the read-only scan off the network so it never pops git prompts

[kyle-sexton]

Problem

The read-only scan behind /repo-hygiene:clean (and every repo of clean-batch --tier scan) runs a networked git command with nothing making it non-interactive. On Windows, Git for Windows routes SSH host-key confirmation and credential requests to GUI dialogs, so a scan of a repo whose remote is unknown, unreachable, or needs credentials opens a modal dialog on the user's desktop. An unattended fleet run blocks on it.

On main (repo-hygiene 0.18.6, commit 6f59096):

• plugins/repo-hygiene/skills/clean/scripts/scan.sh:92: STALE_REFS="$(git remote prune origin --dry-run 2>/dev/null | head -5 | tr '\n' '; ')". git remote prune --dry-run contacts the remote. No GIT_TERMINAL_PROMPT=0, no </dev/null, no SSH batch mode. 2>/dev/null hides error text, not a GUI prompt.
• plugins/repo-hygiene/skills/clean/scripts/clean-batch.sh:299 runs scan.sh once per repo for --tier scan.
• plugins/repo-hygiene/skills/clean/scripts/git-branch-audit.sh:362 (the --remote path): GIT_TERMINAL_PROMPT=0 git -C "$REPO_ROOT" ls-remote --heads origin 2>/dev/null </dev/null. Better, but still incomplete: GIT_TERMINAL_PROMPT=0 does not stop an SSH host-key or passphrase prompt (SSH asks through SSH_ASKPASS, which Git for Windows points at git-askpass.exe), and does not cover a credential-helper GUI.
• Acting paths, attended but with the same exposure: git-prune.sh (--apply runs git remote prune origin, listed in lib/cleanup-paths.sh:58) and git-tree-reset.sh:199 (git fetch "$UPSTREAM_REMOTE").

Evidence

Verified this pass (read-only on origin/main):

• The lines above.
• The caller that produced the observed dialog: plugins/repo-hygiene/skills/clean/scripts/clean-batch.test.sh:505 sets a fixture repo's origin to exactly git@GitHub.com:owner/repo.git, and the --tier scan --fleet cases that follow (around :537-541) run scan.sh on it, which reaches scan.sh:92. The HTTPS fixtures at :506 (https://user@github.com/owner/repo) and :507 (https://github.com/owner/other.git) go through the same path and can reach the credential helper.
• clean-batch.sh:690 already reports the git tier's shared object store with "remote prune not measured", so the batch report has a precedent for not measuring the remote.
• No existing issue covers this. Related closed issue repo-fleet-hygiene:audit: every ls-remote probe fails because run_git_probe discards global core.sshCommand, so merged-remote-branch never reaches HIGH #4211: repo-fleet-hygiene's probes failed because they discarded the global core.sshCommand (Windows OpenSSH, which reaches the Windows SSH agent) and the system credential.helper.

Observed by the producing session on 2026-10-03 (Windows, Git Bash), process trace of one dialog:

git-askpass.exe "The authenticity of host 'github.com (140.82.114.3)' can't be established.
  ED25519 key fingerprint is: SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
  This key is not known by any other names. Are you sure you want to continue connecting ...?"
  <- ssh.exe   ssh -o SendEnv=GIT_PROTOCOL git@GitHub.com "git-upload-pack 'owner/repo.git'"
  <- git.exe   git remote prune origin --dry-run
  <- bash.exe  .../plugins/repo-hygiene/skills/clean/scripts/scan.sh

The GitHub.com spelling was not in known_hosts, so SSH asked through the GUI askpass for a repository that does not exist.

Not verified: which setting reliably suppresses Git Credential Manager's GUI for HTTPS remotes (candidates: GCM_INTERACTIVE=never, -c credential.interactive=false, an empty GIT_ASKPASS). Confirm against GCM's docs before relying on one.

Proposed approach

Recommended, fewest moving parts first:

1. Make scan.sh local-only. Drop the git remote prune origin --dry-run call and report stale remote-tracking refs from local state only, or print "remote prune not measured" as clean-batch.sh:690 already does. The scan is the read-only inventory; git-prune.sh --apply is the step that acts and may contact the remote.
2. For the remaining networked calls (git-branch-audit.sh:362, git-prune.sh --apply, git-tree-reset.sh:199), add one shared helper in skills/clean/scripts/lib/ that runs git non-interactively: GIT_TERMINAL_PROMPT=0, stdin from /dev/null, SSH batch mode with a connect timeout, and a credential-helper no-GUI setting once verified. On failure, report "remote unreachable" rather than hang.
3. Tests use a local file:// bare repository as any fixture remote that is actually contacted, and the dedupe fixtures in clean-batch.test.sh:505-507 stay as URL strings that nothing contacts once 1 lands.

Alternative considered: keep the network call in scan.sh but guard it with the helper. Rejected as the default because a read-only inventory gains little from a live remote check and a guarded call still costs a connection per repo in a fleet run.

Files: plugins/repo-hygiene/skills/clean/scripts/scan.sh, scan.test.sh, lib/ (new helper), git-branch-audit.sh, git-prune.sh, git-tree-reset.sh, clean-batch.test.sh, and the skill text if it describes the scan's stale-refs line.

Acceptance criteria

• scan.sh on a repo whose origin is git@unknown-host.invalid:owner/repo.git finishes with exit 0, prints a stale-refs line that does not depend on the network, and starts no ssh, git-askpass, or ssh-askpass process. Test setup: set GIT_SSH_COMMAND to a recording shim (or point GIT_CONFIG_GLOBAL at a test config whose core.sshCommand is the shim) and set GIT_CONFIG_NOSYSTEM=1, so the shim records any connection even on a host whose global core.sshCommand is an absolute path that a PATH shim would never intercept. The test must fail on current main.
• clean-batch.sh --tier scan --fleet over the existing fixtures, under the same shim setup, records no ssh invocation and reaches no credential helper.
• Every remaining networked git call in the plugin goes through the shared non-interactive helper, and a test proves an unreachable ssh remote yields a "remote unreachable" style result without hanging.
• The helper keeps the user's configured core.sshCommand (a test sets core.sshCommand to a recording shim and asserts the shim is what runs, with BatchMode=yes in its arguments).
• The repo-hygiene test suite passes with networking unavailable.

Constraints and gotchas

• Do not set GIT_SSH_COMMAND="ssh -o BatchMode=yes" as a fixed string: GIT_SSH_COMMAND overrides core.sshCommand. On a Windows machine where the global core.sshCommand is C:/Windows/System32/OpenSSH/ssh.exe, that silently swaps in Git for Windows' bundled ssh, which cannot reach the Windows SSH agent, so every authenticated remote fails. This is the failure repo-fleet-hygiene:audit: every ls-remote probe fails because run_git_probe discards global core.sshCommand, so merged-remote-branch never reaches HIGH #4211 hit. Resolve git config core.sshCommand (default ssh) and append -o BatchMode=yes -o ConnectTimeout=5 to it.
• Do not discard global or system git config (GIT_CONFIG_GLOBAL=/dev/null) for the same reason; repo-fleet-hygiene:audit: every ls-remote probe fails because run_git_probe discards global core.sshCommand, so merged-remote-branch never reaches HIGH #4211 also lost credential.helper that way.
• The test-only GIT_SSH_COMMAND or GIT_CONFIG_GLOBAL override above exists to intercept connections in tests; it does not contradict the production rule against replacing core.sshCommand.
• GIT_TERMINAL_PROMPT=0 alone stops neither the SSH host-key prompt nor a GUI credential helper.
• Version bump and CHANGELOG entry for repo-hygiene.

Context

Source: local handoff item 20261003-053544-repo-hygiene-scan-network-prompts.md (retired into this issue). Related: #4211 (closed; the core.sshCommand and credential.helper lesson).

[kyle-sexton]

Test-side detail for this issue, from a second report of the same clean-batch.test.sh run (Windows, Git Bash, 2026-10-03). Re-verified against main b3691e5.

Fixture remotes that are actually contacted. plugins/repo-hygiene/skills/clean/scripts/clean-batch.test.sh:

• SSH: :505 (FL_A, git@GitHub.com:owner/repo.git).
• HTTPS: :506 (FL_CLONE), :507 (FL_B) and :508 (FL_CZ, https://github.com/owner/dotfiles.git). The issue body names :506-507 but not :508.
• The scan-tier calls that reach scan.sh:92 with these fixtures: :529 (--tier scan --fleet), :547 (--tier scan --repo "$FL_CLONE" "$FL_A") and :561 (--tier scan --fleet --skip "$FL_A"). The :547 explicit-selection case is not named in acceptance criterion 2, which covers --fleet only.
• Does not reproduce: the report also named :566, but the set-url block at :565-568 runs only --tier caches, which contacts nothing. A grep of the plugin's remote add / set-url lines finds no other real remote URL; the one other remote, https://example.com/o/r.git in lib/batch-common.test.sh:265, feeds a dedupe helper that never contacts it.

HTTPS reaches Git Credential Manager (reported by the producing session, not reproduced here). During that run, two git-credential-manager processes started for the HTTPS fixtures and exited on their own. This bears on the issue's "not verified" note on suppressing GCM: a test cannot rely on GCM exiting by itself.

Detection: a shim instead of process polling. The report asked for a check that no git-askpass, ssh-askpass or credential-manager process starts during the run. Polling the process list on Windows is racy (these processes can start and exit between samples). Extend the recording-shim approach in criterion 1 instead. In the test-only GIT_CONFIG_GLOBAL config, set credential.helper to a recording shim (after an empty credential.helper= line, which clears inherited helpers) next to core.sshCommand, and assert both record nothing.

The 29 Windows failures are a separate problem. The report counted 29 failures in this suite on Windows. #6065's body identifies them as path-form assertions, the same 29 with and without that change. They are not network failures. Do not chase them under this issue, and do not let them mask the new assertions.

One caution on the suggested fix. The report proposed GIT_SSH_COMMAND="ssh -o BatchMode=yes". That is acceptable only as a test-side shim, as this issue's gotchas already say. In product code it overrides core.sshCommand and repeats #4211.

Source: local handoff item 20261003-074553-repo-hygiene-clean-batch-tests-reach-network.md (retired into this comment).