7. Redirect git to a curated gitconfig rather than masking the host’s#
Date: 2026-05-11
Status#
Accepted
Context#
Inside the sandbox, git needs to (a) use the gh/glab credential helpers so
git push authenticates (see 6. Scope credentials to the container; re-paste PATs on every rebuild), (b)
apply ssh→https insteadOf rewrites, and (c) not pick up the host’s personal
git identity or system config. The first implementation bind-masked the host
gitconfigs (/etc/gitconfig, ~/.gitconfig) with /dev/null as
defence-in-depth. That broke tools which scrub GIT_* env vars before spawning
git (e.g. pre-commit’s no_git_env): they fell through to the masked, empty
config — and the mask added no protection beyond the env redirect.
Decision#
Redirect git by environment, not by masking the host files. The shadow sets
GIT_CONFIG_GLOBAL=/etc/claude-gitconfig and GIT_CONFIG_SYSTEM=/dev/null, and
regenerates /etc/claude-gitconfig on every launch from the host’s current
user.name/user.email — wiring the gh/glab credential helpers and the
ssh→https insteadOf rewrites. The host’s /etc/gitconfig stays readable but
is neutralised for git by the GIT_CONFIG_SYSTEM=/dev/null redirect; the host’s
~/.gitconfig is invisible anyway under the strict-under-/root inversion
(4. Isolate with bwrap: drop all capabilities, scrub the environment, invert /root to default-deny). Commit b1dd6df walked back the earlier
bind-mask; ad69881 made the regeneration per-launch.
Consequences#
A host gitconfig identity edit takes effect on the next
claudelaunch with nothing to re-run.Tools that scrub
GIT_*see the host/etc/gitconfig— intended. The env redirect, not a bind-mask, is the boundary.CLAUDE_SANDBOX_NO_FORGE=1drops the credential helpers from the generated config (see 6. Scope credentials to the container; re-paste PATs on every rebuild).The generator is untested logic inlined in the launch body, and the forge host set is hard-coded (the
glabhelper covers onlygitlab.diamond.ac.ukwhilejust glab-authdefaults togitlab.com). Both are tracked in issue #49.