Go-based CLI tools (gh, terraform, etc.) fail with TLS error due to built-in HTTPS proxy

Could be related to https://github.com/anthropics/claude-code/issues/23416

+1 for fixing gh usage

+1

+1 please!

+1

+1

This is fixable with a setting more surgical than enableWeakerNetworkIsolation — and the root cause, at least when the sandbox is enabled, is a bit different from the MITM-cert framing in the issue.

On macOS, Go's crypto/x509 doesn't verify certificates in-process — it delegates to the system trustd daemon via a Mach-service lookup (SecTrustEvaluateWithError → com.apple.trustd.agent). When Claude Code's Seatbelt sandbox is active, that Mach lookup is denied, so Go can't get a trust verdict and surfaces it as x509: OSStatus -26276 even though the certificate is valid. curl/git/Python/Node verify in-process against a CA bundle and never call trustd, which is why they're unaffected. (Go also ignores SSL_CERT_FILE on macOS, so that knob doesn't help.)

Whitelisting just that one Mach service fixes it without loosening anything else:

"sandbox": { "network": { "allowMachLookup": ["com.apple.trustd.agent"] } }

In my testing, network isolation stayed fully intact (a non-allowlisted host the Go CLI tried to reach was still blocked), and it did not reintroduce permission prompts for network commands. enableWeakerNetworkIsolation targets the same trustd path but loosens network isolation broadly — and in some versions it's a no-op that the settings validator strips (see #28954), which may be why it "does not fix this" as noted above — so allowMachLookup is the tighter, more reliable fix. Requires a Claude Code restart to take effect.

A working fix: sandbox.excludedCommands — with three gotchas that make it look broken

On macOS the OSStatus -26276 error is Seatbelt blocking the Go binary from reaching the system trust daemon (trustd); the proxy env vars (HTTPS_PROXY, ALL_PROXY, etc.) are injected into every command regardless, so the tool can't validate the cert. The documented fix — adding the tool to sandbox.excludedCommands so it runs outside Seatbelt — does work (confirmed on 2.1.170), but three things made it appear ineffective for us:

**1. Patterns match the command as executed, and need a wildcard.** "gh" only matches the bare command gh — it does not match gh api user. You need:

"sandbox": { "excludedCommands": ["gh", "gh *", "terraform", "terraform *"] }

**2. The command must start with the excluded binary.** A compound or looped command like for x in ...; do gh ...; done or echo foo; gh ... starts with for/echo, so the whole thing runs sandboxed and the gh calls inside inherit Seatbelt. Run excluded tools as standalone commands.

3. Watch out for command-rewriting PreToolUse hooks — e.g. rtk (Rust Token Killer). rtk's hook auto-rewrites gh … → rtk gh … before the command executes, so the sandbox matches against rtk gh api user, not gh api user. The plain gh * exclusion silently never matches and the tool keeps running sandboxed. Exclude the rtk-wrapped form too:

"excludedCommands": ["gh", "gh *", "rtk gh", "rtk gh *"]

This was the final missing piece for us — two restarts looked like failures purely because the executed command was rtk gh … rather than gh ….

Verified working afterwards: gh auth status shows ✓ and gh api calls succeed. Note excludedCommands only takes effect after restarting Claude Code, since sandbox config is read at session start.

Adding a version boundary that I haven't seen pinned down yet: this regressed in Claude Code 2.1.172.

gh worked fine inside the sandbox for me for weeks, then broke the instant 2.1.172 installed. Evidence from my local session transcripts (macOS 26 / arm64):

• One May 19 session ran 217 gh commands in-sandbox with zero TLS errors. No OSStatus -26276 appears in any session before today.
• The first OSStatus -26276 anywhere is timestamped 17:19:24; the 2.1.172 binary was installed at 17:19:25 — one second apart.
• I jumped 2.1.170 → 2.1.172 (no 2.1.171 changelog entry exists), and the 2.1.172 notes mention nothing about sandbox, network isolation, or trustd. So this looks like an undocumented change to the macOS Seatbelt profile.

Mechanism (consistent with @pradeep-mj's analysis above): on macOS, Go's crypto/x509 delegates verification to trustd via a Mach-service lookup (SecTrustEvaluateWithError → com.apple.trustd.agent). 2.1.172 stopped granting that lookup, so Go can't get a trust verdict and surfaces x509: OSStatus -26276 even though the cert is valid. curl/git/Python/Node verify in-process and are unaffected. The local proxy is a transparent CONNECT tunnel here (not a MITM) — curl to the same host returns 200 — so the proxy/MITM framing isn't the cause in the sandbox-enabled case.

Fix that works on 2.1.172, re-granting just that one Mach service (restart required):

"sandbox": { "network": { "allowMachLookup": ["com.apple.trustd.agent"] } }

After this, the stock Homebrew gh works in-sandbox again using real system trust, and network isolation stays intact (a non-allowlisted host the Go tool tried was still blocked). This also fixes terraform/kubectl/go. Would be good to either restore the prior default or document this in the 2.1.172 notes, since it silently broke every Go CLI in the sandbox.

this continues to be a problem for me as well

+1