docs(memory): vault git-auth fix — GCM shadows store token on git.azcomputerguru.com

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>

.claude/memory/MEMORY.md

@@ -45,6 +45,7 @@
 - [/tmp path mismatch on Windows](feedback_tmp_path_windows.md) — Write tool and Git Bash resolve `/tmp` to DIFFERENT real dirs. Use heredoc or workspace path for JSON payloads handed to curl.
 - [Windows bash command mapping](feedback_windows_bash_mapping.md) — `bash` often resolves to WSL stub instead of Git/MSYS bash required by the harness. Fix by prepending `C:\Program Files\Git\bin` (and usr\bin) to PATH, or source `.claude/scripts/ensure-git-bash.ps1`. Profile has the logic; use plain `bash .claude/scripts/...` after remap. See the helper and this memory file for details.
 - [Git must authenticate non-interactively](feedback_git_noninteractive_auth.md) — Mike's gripe with Git for Windows is the constant password prompts (GCM) that hang automation, NOT the tool itself. D:\ClaudeTools is set to `credential.helper=store` primed with the azcomputerguru Gitea API token (host 172.16.3.20:3000); always set `GIT_TERMINAL_PROMPT=0`. Any never-prompts solution is acceptable.
+- [Vault git auth — GCM shadows store token](feedback_vault_gcm_shadow_auth.md) — vault sync "Failed to authenticate user" on git.azcomputerguru.com: GCM is first in the helper chain and shadows the valid store token. Fix (machine-local): store-only credential.helper reset + pin `azcomputerguru@` in the vault remote URL so store returns the durable PAT (not the volatile OAUTH_USER JWT). Applied GURU-5070 2026-06-07.
 - [Antigravity agy.exe is not a headless CLI](reference_antigravity_agy_not_headless.md) — the `agy` skill's real backend is `@google/gemini-cli`, not the Antigravity `agy.exe` (IDE agent, no stdout, hangs). Don't reinstall agy.exe expecting headless output. Mike has a paid Gemini account, so stay on gemini-cli past the June 18 free-tier sunset (prefer `GEMINI_API_KEY`).
 - [SQL instance role — verify by connections, not name](feedback_sql_instance_role_by_connection.md) — Standard installed under default `SQLEXPRESS` instance name is real. Prove role with `sys.dm_exec_sessions` + `Get-NetTCPConnection -OwningProcess` before recommending stop/uninstall.
 - [Clear-RecycleBin fails silently as SYSTEM](feedback_clear_recyclebin_system_context.md) — RMM-dispatched cleanup scripts cannot use `Clear-RecycleBin -Force`; the cmdlet uses Shell COM and silently no-ops without an interactive desktop. Enumerate `C:\$Recycle.Bin\<SID>\*` directly.

.claude/memory/feedback_vault_gcm_shadow_auth.md

@@ -0,0 +1,40 @@
+---
+name: feedback_vault_gcm_shadow_auth
+description: Vault git push/fetch "Failed to authenticate user" cause+fix — GCM shadows the store token; pin store-only + username in remote URL
+metadata:
+  type: feedback
+---
+
+`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:**
+```bash
+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.