Go binaries fail TLS in Claude Code macOS sandbox (Security framework blocked)

[jaeyeom]

Problem

Go binaries (e.g., gh CLI) cannot make HTTPS connections inside the Claude Code macOS sandbox. TLS certificate verification fails with:

tls: failed to verify certificate: x509: OSStatus -26276

This prevents gh issue list, gh api, and all other gh commands from working.

Root Cause

The Claude Code sandbox on macOS blocks access to the Security framework (used by Go's crypto/x509 package with cgo for TLS certificate verification). This is an OS-level sandbox restriction that cannot be bypassed through:

• excludedCommands in settings.json — the sandbox applies to the entire process tree
• SSL_CERT_FILE env var — Go with cgo on macOS ignores this, preferring Security framework
• GODEBUG=x509usefallbackroots=1 — doesn't trigger fallback for this failure mode

What Works vs. What Doesn't

Command	TLS Backend	Works in Sandbox?
curl	SecureTransport / LibreSSL	Yes
python3 urllib	OpenSSL	Yes
gh (Go binary)	Security framework via cgo	No
Any Go binary with cgo TLS	Security framework via cgo	No

Current Workaround

The Claude wrapper script (setup-claude-sandbox.yml) exports GH_TOKEN so auth works without keychain access, but TLS remains broken. Using curl with GH_TOKEN header works as a fallback:

curl -s -H "Authorization: bearer \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" https://api.github.com/user

Potential Solutions

1. Python HTTPS proxy — Start a lightweight Python proxy in the wrapper that Go binaries route through (Python uses OpenSSL, not Security framework)
2. gh wrapper using curl — Replace gh with a shell script that delegates common subcommands to curl + jq
3. Compile gh with CGO_ENABLED=0 — Forces pure-Go TLS which respects SSL_CERT_FILE (but may break other things)
4. Upstream fix in Claude Code — Allow Security framework Mach services in the sandbox profile

Reproduction

1. Start Claude Code with sandbox enabled on macOS
2. Run: gh auth status → fails with keychain error
3. Run: gh api user → fails with x509 OSStatus -26276
4. Run: curl -s https://api.github.com/zen → works
5. Run with dangerouslyDisableSandbox: true → works

Environment

• macOS (Apple Silicon)
• Claude Code sandbox enabled
• gh CLI installed via Homebrew

[jaeyeom]

Investigation Results

After deeper research, the issue description is accurate but option 3 (CGO_ENABLED=0) will NOT work on modern Go (1.18+) without an additional step, due to how macOS Go uses //go:cgo_import_dynamic directives to call the Security framework — even binaries built with CGO_ENABLED=0 still call SecTrustEvaluateWithError() at runtime.

Root Cause

On darwin, root_darwin.go returns a CertPool with systemPool: true, delegating all verification to systemVerify() which calls into the Security framework via dynamic linking. The root_unix.go file that reads SSL_CERT_FILE has a build constraint explicitly excluding darwin, so that env var is also ineffective.

GODEBUG=x509usefallbackroots=1 alone similarly doesn't work because it only activates if x509.SetFallbackRoots() has already been called to populate an alternative pool.

Working Fix: Embedded Fallback Root Certificates

The correct solution is to use the golang.org/x/crypto/x509roots/fallback package, which embeds the Mozilla/NSS root CA bundle directly into the binary. Combined with GODEBUG=x509usefallbackroots=1, Go replaces the darwin system pool and never calls the Security framework.

go get golang.org/x/crypto/x509roots/fallback

Add a blank import in main.go:

import (
    _ "golang.org/x/crypto/x509roots/fallback"
)

Build and set env:

CGO_ENABLED=0 go build -o bin/gh ./cmd/gh

// ~/.claude/settings.json
{
  "env": {
    "GODEBUG": "x509usefallbackroots=1"
  }
}

How It Works

1. The fallback package's init() calls x509.SetFallbackRoots(embeddedMozillaRoots)
2. GODEBUG=x509usefallbackroots=1 causes initSystemRoots() to replace the darwin system pool with the fallback pool
3. Since the replacement pool has systemPool: false, verify.go skips the systemVerify() path entirely — the Security framework is never consulted

Security tradeoff: No real-time OCSP revocation checks via the OS, and the embedded CA bundle is fixed at build time (requires periodic rebuild). These are the same tradeoffs every Go binary on Linux accepts.

Alternative: enableWeakerNetworkIsolation

Anthropic added enableWeakerNetworkIsolation in Claude Code specifically for this, which re-enables Mach IPC access to com.apple.trustd.agent. However, Anthropic's own docs warn it opens a potential data exfiltration vector through the trustd service — so the embedded fallback approach is preferable for security-conscious setups.

This issue also affects other Go binaries that make HTTPS connections (terraform, kubectl, gcloud, etc.) and is tracked upstream at anthropics/claude-code.