Sandbox blocks macOS Keychain access, breaking CLI tools that use keyring auth (gh, bee)

Description

When sandbox mode is enabled, CLI tools that store credentials in the macOS Keychain (via security framework / keyring) fail to authenticate. This affects tools like gh (GitHub CLI) and other CLI tools using keyring-based auth.

Environment

• macOS (Apple Silicon, Darwin 25.0.0)
• Claude Code (CLI) v2.1.92
• Sandbox enabled with enableWeakerNetworkIsolation: true

Reproduction

In sandbox (default):

$ gh auth status
github.com
  X Failed to log in to github.com account (default)
  - The token in default is invalid.

$ security find-generic-password -s "gh:github.com"
security: SecKeychainSearchCreateFromAttributes: A Module Directory Service error has occurred.
security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain.

Outside sandbox (dangerouslyDisableSandbox: true):

$ gh auth status
github.com
  ✓ Logged in to github.com account (keyring)

$ security find-generic-password -s "gh:github.com"
keychain: ".../login.keychain-db"  ← found

Root Cause

The sandbox filesystem restrictions block read access to ~/Library/Keychains/ (or the underlying Security framework calls). The enableWeakerNetworkIsolation setting only relaxes network restrictions—it doesn't affect Keychain access.

Impact

Any CLI tool that uses macOS Keychain for credential storage silently fails in sandbox mode. Common tools affected:

• gh (GitHub CLI) — uses keyring by default on macOS
• Any npm/pip CLI tool using keyring for API key storage

Current Workaround

Users must use dangerouslyDisableSandbox: true for every Bash call that needs keyring access.

Suggested Fix

Consider one of:

1. Allow Keychain read access by default — ~/Library/Keychains/ is read-only access to encrypted credential storage, low risk
2. New sandbox option like allowKeychainAccess: true to opt in
3. Document the limitation so users know to configure token-based auth (e.g., GH_TOKEN env var) as an alternative