Self-hosted runner: a nested `claude` process overwrites the parent session's governed-git config, leaving git and `gh` pointed at a closed relay port

Environment

• Claude Code 2.1.281, self-hosted environment (public beta) on Kubernetes, one session per runner pod.
• Runner flags: self-hosted-runner --use-anthropic-git-proxy --configure-git --capacity 1.
• Sessions start from Claude in Slack.

Summary

With governed git on, each session's claude process starts an agent-proxy relay on 127.0.0.1:<port> and writes that port into three files:

• <base>/_sessions/<id>.gitconfig (http.https://github.com/.proxy)
• <id>.claude-config/ccr/bin/gh (the gh shim)
• <id>.claude-config/ccr/README.md

If any tool in the session starts another claude process, even a one-shot subcommand like claude plugins list --json, that child inherits the session environment. It starts its own relay, rewrites all three files with its own port, and exits, so that port closes. The parent's relay is still running on the original port, but git and gh now point at the dead port. From then on, every git fetch/git push and gh call in the session fails with "connection refused" until the session ends.

Reproduction

1. Start a session on a runner with --use-anthropic-git-proxy.
2. From the session's Bash tool, run any command that starts claude, e.g. claude plugins list --json. We hit it through Vercel CLI 59.x, which runs exactly that command to check for its Claude plugin during vercel env pull.
3. git config -f <base>/_sessions/<id>.gitconfig --get http.https://github.com/.proxy now shows a new port. curl http://127.0.0.1:<new port>/__agentproxy/status is refused, while the port in the parent's debug log ([agent-proxy] relay listening on 127.0.0.1:<port>) still answers.
4. git push fails with Failed to connect to 127.0.0.1 port <new port>: Connection refused.

Evidence

• In each affected session, all three files had the same mtime, down to the nanosecond.
• That timestamp was the same second as the nested claude invocation.
• The parent process wrote no agent-proxy log lines at that time, and was idle.
• On our fleet, 8 of 8 sessions whose startup ran vercel env pull were affected. 0 of 6 sessions that didn't run it were affected.

Expected

A nested or short-lived claude process inside a governed session should not take over the parent's session-scoped git config. Any of these would fix it:

• Reuse the parent's relay when one is already running (it could be detected through the environment).
• Skip agent-proxy and governed-git setup for non-session subcommands (plugins, mcp, --version, and so on).
• Have the parent re-assert its routing, or detect that its port was replaced.

Workaround

We stopped the tool from starting claude. For Vercel CLI, we set AI_AGENT to a non-Claude value, or set pluginDeclined: true in ~/.local/share/com.vercel.cli/agent-preferences.json. Any other tool that shells out to claude will still trigger the bug.