Investigate macOS Keychain 'cannot be found to store git' dialog

[rolfsormo]

Context

During earlier development, a real macOS Keychain dialog ("cannot be found to store 'git'" or similar wording) was observed firing during devboost operations that touch git (clones, config). Root cause was never resolved — an earlier discussion about a possible wrapper-script fix got tangled/miscommunicated between the user and the assistant working on this at the time, and the user explicitly asked to defer this until after the Go migration completed, requesting a fresh restatement of their idea rather than reconstruction from memory.

Status

Deferred. The Go migration (this repo's v2 rewrite) is now complete. This issue exists so the deferred item has a durable home instead of living only in session-local task state, which doesn't survive between conversations.

Next step

When this is picked back up: ask the user to restate their proposed fix/idea fresh. Do not assume or guess at what was discussed previously — that led to a real, sharply-corrected miscommunication before.

Likely relates to macOS Keychain ACL staleness on ad-hoc-signed Homebrew git binaries, but this was a working hypothesis, not confirmed root cause.

[rolfsormo]

Found and fixed a concretely-diagnosed instance of this class of bug during final pre-merge verification, distinct from (but possibly related to) whatever was originally discussed here — flagging rather than closing, since this issue's own notes ask not to assume continuity with the earlier deferred conversation.

What was confirmed: a real end-to-end apply run hung indefinitely inside TPM's install_plugins.sh. Process-tree inspection (ps, lsof, sample) showed the actual git clone had already completed successfully (TCP connection CLOSED, target directory present) — the process genuinely stuck was git-credential-osxkeychain store, spawned automatically by git after a successful HTTPS clone, blocking on a Keychain GUI authorization prompt that never arrives in a headless/background context.

Root cause: credential.helper = osxkeychain is set system-wide in /opt/homebrew/etc/gitconfig (Homebrew's git formula default), not in ~/.gitconfig — so it's active regardless of $HOME.

Fix applied in engine/kinds/gitclone.go (devboost's own git clone calls now pass -c credential.helper=) and engine/modules/tmux.go (TPM's scripts, which we don't control the invocation surface of, get GIT_CONFIG_COUNT=1/GIT_CONFIG_KEY_0=credential.helper/GIT_CONFIG_VALUE_0= injected via env instead). Both disable the credential helper only for these specific clone invocations — devboost never authenticates against git remotes, so there's never a credential worth persisting.

This resolves the specific hang found during this pass. Whether it's the same trigger as the original dialog reported here is unconfirmed — per this issue's own note, that needs the user's fresh restatement rather than an assumption from this side.