Sandbox network proxy causes TLS failures for gh CLI (and other Go binaries)

Bug Description

gh CLI fails with TLS certificate verification errors when run inside Claude Code's sandbox, even when gh is in excludedCommands and api.github.com is in allowedHosts.

Error

Post "https://api.github.com/graphql": tls: failed to verify certificate: x509: OSStatus -26276

Environment

• OS: macOS (Darwin 23.6.0)
• Claude Code: Latest
• gh CLI: Latest
• Go: Uses native x509 certificate verification

Steps to Reproduce

1. Add gh to excludedCommands in settings
2. Add api.github.com and github.com to sandbox.allowedHosts
3. Run any gh command from Claude Code (e.g., gh api /zen)
4. Observe TLS verification failure

Expected Behavior

gh should be able to reach api.github.com without TLS errors, especially when:

• The host is in allowedHosts
• The binary is in excludedCommands

Actual Behavior

The sandbox injects HTTPS_PROXY=http://localhost:<port> (and http_proxy, ALL_PROXY) into the shell environment for all commands, including those in excludedCommands. The proxy performs TLS MITM on outbound HTTPS connections. Go's x509 verifier rejects the proxy's injected certificate.

Root Cause Analysis

1. excludedCommands only bypasses filesystem sandboxing, not the network proxy. The proxy env vars are still injected.
2. The proxy does TLS MITM on all HTTPS traffic, even for hosts explicitly listed in allowedHosts.
3. Go binaries are especially affected because Go's x509 verifier uses the OS certificate store and rejects the proxy's certificate (which isn't in the system trust store).
4. git works because it uses SSH (git@github.com:...), never hitting the HTTPS proxy. gh has no SSH mode — it must use HTTPS.
5. NO_PROXY is set by the sandbox but doesn't include api.github.com.
6. Managed settings env cannot override proxy vars — the sandbox injects them after managed env vars.

Evidence

• gh api /zen fails inside sandbox
• gh api /zen works with dangerouslyDisableSandbox: true
• Same gh binary, same auth token, same host — only difference is the proxy env vars

Suggested Fixes (any of these would resolve it)

1. excludedCommands should also exclude from the network proxy — don't inject HTTPS_PROXY/http_proxy/ALL_PROXY for excluded binaries
2. Add a sandbox.networkExcludedCommands setting for binaries that should bypass the network proxy
3. Transparent passthrough for allowedHosts — the proxy should not perform TLS MITM for hosts already in the allowlist; just pass the TLS connection through without intercepting

Current Workaround

Users must use dangerouslyDisableSandbox: true for every gh command, which defeats the purpose of the sandbox and requires manual approval each time.

Impact

This affects any Go binary (and potentially other languages with strict certificate verification) that needs to make HTTPS requests through the sandbox. gh is particularly impactful since it's a core developer tool for GitHub operations (creating PRs, checking CI status, managing issues).