gh token and gitconfig persist differently — git HTTPS auth breaks after container recreation

[alanbem]

Problem

Only ~/.claude lives in the persistent volume. dclaude gh (gh auth login) writes to two places:

• Token → ~/.config/gh/hosts.yml — container layer, lost on dclaude rm
• Credential helper → .gitconfig (GIT_CONFIG_GLOBAL=/home/claude/.claude/.gitconfig) — volume, survives:

credential.https://github.com.helper=!/usr/bin/gh auth git-credential

After recreating the container, the persisted gitconfig still routes git's HTTPS auth through a gh that has no token. Instead of a clean "not authenticated", git fails through a broken credential helper — confusing to debug, and it also shadows other auth methods the user might expect to work.

The same persistence split applies to everything else installed at runtime (npm globals, apt/brew packages, Claude auto-updates in ~/.local) — those are at least documented, but the gh/gitconfig case actively corrupts auth rather than just forgetting it.

Fix options

1. Persist gh config too: symlink ~/.config/gh into the volume (e.g. entrypoint: ln -s /home/claude/.claude/gh-config ~/.config/gh) so token and helper live and die together
2. Or the reverse: have dclaude gh warn that auth lasts only for the container's lifetime, and have the entrypoint strip stale gh auth git-credential helper entries when ~/.config/gh/hosts.yml is absent

Option 1 matches user expectations ("I logged in once") and mirrors how .gitconfig already works.

---

Found during a full-project code review.