[BUG] macOS sandbox blocks Security.framework TLS verification, breaking Go binaries (gh, terraform, etc.)

Status Open
Reported on v2.1.31
Maintainer reply None cached
Activity 9 comments · opened Feb 5, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Description

When sandbox mode is enabled via managed-settings.json, any Go-based CLI tool (gh, terraform, kubectl, aws-cli, etc.) fails with:
tls: failed to verify certificate: x509: OSStatus -26276

Root Cause

Go on macOS uses cgo to call Security.framework for TLS certificate verification. The sandbox blocks these syscalls. Python (which uses OpenSSL) works fine in the same sandbox.

Evidence

  • gh api user inside sandbox → x509 error
  • python3 urllib.request.urlopen('https://api.github.com') inside sandbox → works
  • gh api user outside sandbox → works
  • Disabling sandbox → gh works
  • Setting SSL_CERT_FILE, GIT_SSL_CAINFO, copying certs locally → still fails
  • Using GH_TOKEN env var (bypassing keyring) → still fails
  • Zscaler disabled → still fails
  • Removing network settings from managed-settings.json → still fails

What Should Happen?

Go binaries should be able to verify TLS certificates when making HTTPS requests to allowed domains.

Error Messages/Logs

Error: Exit code 1
     Get "https://api.github.com/user": tls: failed to verify certificate: x509: OSStatus -26276

Steps to Reproduce

Reproduction Steps

  1. Enable sandbox in managed-settings.json with "enabled": true
  2. Add api.github.com to allowedDomains
  3. Run gh api user inside Claude Code

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.31 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Suggested Fix

Either allowlist Security.framework syscalls for TLS verification in the sandbox profile, or automatically set SSL_CERT_FILE to a bundled/accessible cert store for sandboxed processes.

View original on GitHub ↗

9 Comments

stekern · 8 months ago
ehsan · 8 months ago

FWIW I asked Claude to write this script that patches the locally installed Claude Code to work around this bug: https://gist.github.com/ehsan/8c1bc6570c1c924f6ac4f8e1e58158ba

You would need to rerun this script every time Claude Code updates to re-apply the patch but it might help someone in the meantime.

jamestelfer · 8 months ago

I'm looking forward for the fix to merge. I do find it odd that (considering the blast radius) that the fix would be disabled by default.

ehsan · 7 months ago

Any updates on this issue? 🙏

dlhck · 7 months ago

Any updates on this?

mmizutani · 7 months ago

Looking forward to seeing something like a new sandbox.enableWeakerNetworkIsolation option for macOS based on the fix https://github.com/anthropic-experimental/sandbox-runtime/pull/120 added in the sandbox configurations of Claude Code.

compojoom · 7 months ago
➜ strings ~/.local/share/claude/versions/2.1.63 2>/dev/null | grep -oE '"0\.0\.[0-9]+"' | sort -u "0.0.0" "0.0.1" "0.0.36" "0.0.37"

Not sure if I'm right or not, but it seems that the latest claude version is bundled with anthropic-sandbox 0.0.37(which is supposed to have this). Unfortunately passing
"sandbox" : {
....
"enableWeakerNetworkIsolation": true,
}

doesn't seem to be forwarded properly to the sandbox? I don't have explanation?

gustafj · 7 months ago
Looking forward to seeing something like a new sandbox.enableWeakerNetworkIsolation option for macOS based on the fix anthropic-experimental/sandbox-runtime#120 added in the sandbox configurations of Claude Code.

This is implemented in 2.1.69 and that feature when enabled fixed my issue.

ChaseHendrick · 10 days ago

A symptom of this that isn't mentioned here yet, and that sends agents (and users) down the wrong path: inside the sandbox, gh auth status reports a perfectly valid token as invalid.

Claude Code 2.1.286, macOS 27.0 (arm64), default Bash sandbox, gh installed at ~/bin/gh:

$ gh auth status          # sandboxed
github.com
  X Failed to log in to github.com account ChaseHendrick (keyring)
  - The token in keyring is invalid.
  - To re-authenticate, run: gh auth refresh -h github.com

$ gh api user --jq .login  # sandboxed
Get "https://api.github.com/user": tls: failed to verify certificate: x509: OSStatus -26276

$ gh api user --jq .login  # same command, sandbox disabled
ChaseHendrick

The keychain isn't the problem: /usr/bin/security find-generic-password -s gh:github.com succeeds inside the sandbox. gh reads the token fine, its validation request then fails TLS (the trustd lookup this issue describes), and gh reports that as an invalid token.

The cost: when the agent sees "The token in keyring is invalid… run gh auth refresh", it reasonably concludes the credentials are bad. In my session the agent told me my token had expired and walked me through a fresh gh auth login, which wasn't needed. Only after that did the "invalid" token turn out to work outside the sandbox.

Until the TLS issue is fixed, it would help if the sandbox-failure guidance (or the system prompt's list of sandbox symptoms) named this one explicitly. A gh "token invalid" message on macOS inside the sandbox should be treated as a sandbox failure, not a credential failure.