1.0.93 regression on macOS: all native HTTPS requests fail with "bad certificate format" when com.apple.SecurityServer is not reachable (sandboxes)

[polarctos]

Describe the bug

Starting with 1.0.93, Copilot CLI on macOS can't connect to its API when it runs inside a sandbox that denies the Mach service com.apple.SecurityServer. Sandboxes such as nono deny this service so the agent can't read keychain secrets. Every native request (user lookup, /models, chat) fails with:

[ERROR] Error loading models: Error: error sending request for url (https://copilot-api.<host>/models): client error (Connect): bad certificate format

The CLI then reports that the user isn't logged in. stderr also shows
CSSM_ModuleLoad(): One or more parameters passed to a function were not valid.

1.0.92 works in the same sandbox.

Affected version

1.0.93 and 1.0.94-4 (1.0.92 works)

Steps to reproduce the behavior

No third-party sandbox is needed. Denying only this one service with sandbox-exec is enough:

prof='(version 1)(allow default)(deny mach-lookup (global-name "com.apple.SecurityServer"))'
COPILOT_GITHUB_TOKEN="$(gh auth token)" sandbox-exec -p "$prof" copilot --prefer-version 1.0.92 -p "Reply with just: hi"   # works
COPILOT_GITHUB_TOKEN="$(gh auth token)" sandbox-exec -p "$prof" copilot --prefer-version 1.0.93 -p "Reply with just: hi"   # bad certificate format

Expected behavior

TLS works without access to the keychain daemon, like in 1.0.92.

Additional context

From 1.0.93 on, more requests run in the native runtime (runtime.node). It contains two TLS stacks:
rustls-platform-verifier and native-tls (Security.framework / Secure Transport). The failing requests use
native-tls. Secure Transport needs com.apple.SecurityServer (the legacy CSSM path) to evaluate certificates and returns errSSLBadCert (-9808, "bad certificate format") when the service is not reachable.

I checked this with a small reqwest client, run under sandbox-exec denying one keychain-related Mach service at a time:

Denied service	reqwest + native-tls	reqwest + rustls-platform-verifier
none	OK	OK
com.apple.SecurityServer	-9808	OK
com.apple.securityd	OK	OK
com.apple.security.keychaind	OK	OK
com.apple.secd	OK	OK
com.apple.security.agent	OK	OK

Custom roots (SSL_CERT_FILE / NODE_EXTRA_CA_CERTS) make no difference: native-tls fails with and without them, and rustls-platform-verifier works with and without them.

Using rustls-platform-verifier, which is already bundled, for all native requests would fix this. Apple has
deprecated Secure Transport.

The same regression shows up elsewhere:

• Execution failed: Failed to get response from the AI model ... invalid peer certificate: UnknownIssuer #5081: 1.0.93 native model requests fail through a proxy on Windows (UnknownIssuer); reported fixed in 1.0.94-3. That fix does not cover this case: 1.0.94-4 still fails as described above.
• Enterprise MCP registry unreachable on macOS: rustls rejects private CA cert (Apple -67901), fail-closed blocks all MCP #4364: native Rust TLS on macOS rejects a private CA cert (-67901) after requests moved out of Node.

macOS 26.7.1 (Apple Silicon).