Mike Swanson
261988956d
Vault sync was failing with "remote: Failed to authenticate user" against git.azcomputerguru.com. Root cause: Git Credential Manager (first in the helper chain) shadowed the valid PAT in the store helper with a stale cached OAUTH_USER JWT. Fix (machine-local git config, already applied — not in the repo): - Reset the vault repo credential.helper to store-only (drop inherited GCM). - Pin azcomputerguru@ in the vault remote URL so store returns the durable PAT instead of a volatile OAUTH_USER JWT. Repo change here is documentation only: a feedback memory capturing the diagnosis + fix, plus an index line in MEMORY.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_vault_gcm_shadow_auth | Vault git push/fetch "Failed to authenticate user" cause+fix — GCM shadows the store token; pin store-only + username in remote URL |
|
sync.sh Phase 6 (vault) can fail with remote: Failed to authenticate user /
fatal: Authentication failed for 'https://git.azcomputerguru.com/.../vault.git' even though
the token is valid and the ClaudeTools repo syncs fine.
Why: The vault remote uses host git.azcomputerguru.com (public, 72.194.62.10) while ClaudeTools
uses the LAN host 172.16.3.20:3000 — same Gitea instance (1.25.2), but a different credential-helper
match. Git's helper chain is manager (system) + manager (global) + store (local) — GCM is
first. GCM had a stale token cached for git.azcomputerguru.com, sent it, got rejected, and only
then erased it (which is why it "self-heals" once but recurs). Compounding it: ~/.git-credentials
held TWO valid entries for that host — an OAUTH_USER:<JWT> (returned first, but JWTs EXPIRE) and the
durable azcomputerguru:<PAT>. A bare https://git.azcomputerguru.com/... URL lets git grab the
volatile JWT first.
Durable fix (machine-local, non-destructive) — applied on GURU-5070 2026-06-07:
cd <vault>
# 1) drop inherited GCM from the chain (empty value resets earlier helpers), store-only:
git config --local --unset-all credential.helper
git config --local --add credential.helper "" # <reset> — clears manager,manager
git config --local --add credential.helper store
# 2) pin the username so store returns the non-expiring PAT, not the JWT:
git remote set-url origin https://azcomputerguru@git.azcomputerguru.com/azcomputerguru/vault.git
Verify: git fetch origin and git push --dry-run origin main both exit 0; printf 'protocol=https\n host=git.azcomputerguru.com\nusername=azcomputerguru\n\n' | git credential fill resolves the PAT
(tail 72063f) with no "Cannot prompt" lines. Did NOT delete the JWT entry — pinning the URL is enough.
Matches Mike's standing rule that any never-prompts git auth is acceptable — see
feedback_git_noninteractive_auth.md. GCM_INTERACTIVE=Never + GIT_TERMINAL_PROMPT=0 (set in
settings.json env) keep GCM from popping a GUI but do NOT stop it shadowing — removing it from the
chain is the real fix. Both PAT and JWT live in ~/.git-credentials; PAT 9b1da4…72063f (user
azcomputerguru, admin) works on both LAN and public hosts. If Howard's box shows the same vault
failure, apply the same two steps.