claude mcp login fails with 'unable to get local issuer certificate' against standard, non-intercepted certs

Description

claude mcp login <server> fails with SDK auth failed: unable to get local issuer certificate when authenticating against a remote MCP server (reproduced against Atlassian's hosted MCP server, https://mcp.atlassian.com/v1/sse), even though the certificate chain involved is completely standard and publicly trusted (not a corporate MITM proxy issue).

This looks like the same underlying root cause as #25977 (WebFetch/Bun ignoring NODE_EXTRA_CA_CERTS), but affecting the MCP OAuth login flow instead of WebFetch. That issue was auto-closed for inactivity by the stale bot, not because it was fixed — filing this as a fresh, narrower repro against the current version.

Environment

• Claude Code version: 2.1.226 (native Mach-O binary, arm64)
• OS: macOS (Darwin 25.5.0, Apple Silicon)
• Install method: native installer (~/.local/bin/claude symlink to ~/.local/share/claude/versions/2.1.226)
• Network: corporate network with a Palo Alto Networks TLS-inspecting proxy present in the system/login keychain — but see evidence below showing this proxy is not involved in the failing connections.

Reproduction Steps

1. claude mcp add --transport sse atlassian https://mcp.atlassian.com/v1/sse --scope user
2. claude mcp login atlassian
3. Observe: Couldn't complete authentication for "atlassian": SDK auth failed: unable to get local issuer certificate

Evidence this is NOT a corporate-proxy/cert-trust problem

• curl -v https://mcp.atlassian.com/v1/sse succeeds cleanly (HTTP/2 401 with a normal Atlassian OAuth error body — expected without a token), using the OS default trust store.
• openssl s_client -connect mcp.atlassian.com:443 -showcerts shows a completely standard Amazon-issued cert chain (issuer=/C=US/O=Amazon/CN=Amazon ECDSA 256 M04), not signed by the corporate proxy's CA.
• Same result for auth.atlassian.com (Amazon RSA 2048 M01 issuer) — another domain plausibly involved in the OAuth flow.
• Rebuilt NODE_EXTRA_CA_CERTS from a bundle containing all certs from /System/Library/Keychains/SystemRootCertificates.keychain, /Library/Keychains/System.keychain, and the user's login.keychain-db (171 certs total, verified via openssl verify that the corporate proxy's root validates against this bundle) — claude mcp login atlassian still failed identically with this bundle set and confirmed loaded (echo $NODE_EXTRA_CA_CERTS verified correct in a fresh shell before invocation).
• Setting NODE_TLS_REJECT_UNAUTHORIZED=0 (diagnostic only, disables all cert verification) makes claude mcp login atlassian succeed immediately — confirming this is purely a certificate validation failure in the CLI's own HTTP client, not a network block, DNS issue, or missing CA.
• Per current docs (https://code.claude.com/docs/en/network-config), the native installer build should read the OS certificate store by default (CLAUDE_CODE_CERT_STORE=bundled,system) without needing NODE_EXTRA_CA_CERTS at all — this default does not appear to be effective for the mcp login OAuth code path.

Expected behavior

claude mcp login should validate certificates using the same trust store that curl/openssl/the OS already trust (or at minimum honor NODE_EXTRA_CA_CERTS / CLAUDE_CODE_CERT_STORE=system), consistent with the documented behavior in the enterprise network config docs.

Actual behavior

The MCP OAuth login HTTP client fails to validate a completely standard, publicly-trusted certificate chain, regardless of NODE_EXTRA_CA_CERTS contents, and regardless of whether the connection is actually intercepted by any corporate proxy.

Related: #25977