Sandboxed Bash intermittently strips Authorization header on HTTPS egress (gh CLI gets 401 "Requires authentication" despite valid keyring login)

Environment

• Claude Code 2.1.167 (npm CLI) / desktop harness reporting 2.1.170 in CLAUDE_CODE_EXECPATH, macOS (Darwin 25.5.0)
• gh 2.92.0 authenticated via keyring (gh auth status ✓), no GH_TOKEN/GITHUB_TOKEN/proxy env vars

Symptom

In sandboxed Bash tool calls, authenticated gh API calls (gh api user, gh pr create, gh secret list, GraphQL) intermittently fail with HTTP 401: Requires authentication — GitHub's "no credential received" message — while gh auth status / gh auth token are healthy. In one observed window (~22 min), ~12 calls across 4 concurrent sessions failed this way.

Evidence that the header is stripped in transit

GH_DEBUG=api shows gh attaching Authorization: token ████ and still receiving 401. Discriminating probe with a deliberately wrong token, identical command:

curl -s -H "Authorization: Bearer gho_WRONGtoken00000000000000000000000000" https://api.github.com/user

• sandboxed (default): {"message": "Requires authentication"} → the header never reached GitHub
• same call with dangerouslyDisableSandbox: true: {"message": "Bad credentials"} → header arrived

An explicit GH_TOKEN=<valid> in the sandboxed command is stripped the same way, so the credential source is irrelevant. TLS cert chain, DNS, /etc/hosts, and system proxy were all clean; git push over HTTPS was unaffected.

Intermittency

The strip is state-dependent, roughly 10–20 minute on/off windows: the same sandboxed wrong-token probe later returned Bad credentials (header passed), and during a passing window an Authorization header also reached httpbin.org/headers intact from sandboxed curl. Every observed failure was sandboxed; unsandboxed calls never failed. Feels like a TTL'd allowlist/approval cache in the sandbox egress proxy.

Expected

Either of these would be fine; silent intermittent stripping is the painful part:

1. Document the sandbox network credential behavior and provide a supported settings.json mechanism (per-domain credential allowlist, or a way to run specific commands unsandboxed without dangerouslyDisableSandbox).
2. If a request's credentials would be stripped, fail loudly (block the request with an explanatory error) instead of forwarding it anonymously — the anonymous-forward turns into confusing downstream 401s that look like tool/auth bugs (we burned a multi-session debugging arc on gh's keyring before isolating the harness).

Happy to provide timestamps/more probes if useful.