[BUG] Claude Desktop Extension wrapper filters env vars — blocks Custom CA configuration for enterprise integrations (Instana / SwissSign / mcp-instana 0.3.1)

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?

⚠️ NOTE" an den Anfang ihres Issue-Bodies: "This issue concerns the Claude Desktop macOS app, NOT the Claude Code CLI."

Hello Anthropic Support,

We are using the IBM Instana Desktop Extension (mcp-instana 0.3.1) in Claude Desktop on macOS to monitor our internally hosted Instana backend. The extension cannot establish a TLS connection to our Instana API endpoint, and we have been able to pinpoint the root cause to a specific behavior of Claude Desktop's Extension wrapper.

This ticket is filed of a regulated insurance group as an enterprise feedback. We don't expect a quick fix, but we believe this is a product gap that affects any enterprise customer using Desktop Extensions to access internally hosted services with corporate-CA-issued certificates.

=== Environment ===

• Product: Claude Desktop on macOS (version 1.5354.0)
• Extension: IBM mcp-instana 0.3.1 (Python 3.11, installed via pipx)
• Target endpoint: instanaserver.internalURL.de (internally hosted Instana, public SwissSign DV certificate)
• API token: read-only

=== Symptom ===

Every MCP tool call fails with:

SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)'))

=== Root Cause Identified ===

Claude Desktop wraps every Desktop Extension subprocess with the helper binary at:

/Applications/Claude.app/Contents/Helpers/disclaimer

This wrapper actively filters environment variables when spawning the MCP subprocess. We verified this empirically by inspecting the subprocess at runtime with ps eww:

• Claude Desktop main process (PID 65778) inherits all environment variables from its launching shell, including SSL_CERT_FILE, REQUESTS_CA_BUNDLE, and NODE_EXTRA_CA_CERTS pointing to a custom SwissSign root bundle.
• The Instana MCP subprocess (PID 66364, parent: Claude Desktop) only retains HOME and a modified PATH. All TLS-related environment variables are stripped.

This means standard Python TLS configuration mechanisms (REQUESTS_CA_BUNDLE, SSL_CERT_FILE) and Node.js mechanisms (NODE_EXTRA_CA_CERTS) cannot reach the extension's runtime, regardless of how they are set on the host system or how Claude Desktop is launched.

=== Verification of Other Causes (Ruled Out) ===

1. Server-side certificate chain is correct: openssl s_client confirms three certs delivered in correct order (Leaf -> SwissSign DV ICA 2022 -> Cross-Signed Root 2022 by SwissSign Gold CA G2).
2. Standard certifi bundle (Mozilla-based) contains both relevant SwissSign roots — verified in our own Python environment.
3. macOS TCC permissions (Documents, network) are granted.
4. Bundle file is correctly placed and readable.
5. Env vars are correctly set in the host shell and verified to propagate to the Claude Desktop main process.

The filtering by the disclaimer wrapper is the only remaining variable.

=== Request ===

1. Could you confirm that the Helpers/disclaimer wrapper intentionally strips environment variables for Desktop Extension subprocesses?
2. If yes — what is the supported mechanism for enterprise customers to provide custom CA bundles to Desktop Extensions when the target service uses certificates issued by a CA that is not in the extension's bundled trust store, OR when the bundled trust store version lags behind the system trust store?
3. If no current mechanism exists — could this be considered for the product roadmap? Possible patterns we would consider sufficient:

• An optional extension manifest field declaring environment variables that should be passed through.
• A per-extension configuration UI accepting a CA bundle path.
• A global Desktop setting for additional trusted CA bundles applied to all extensions.

1. As a workaround, are we right to assume that hosting the MCP server ourselves (e.g., on-premise as a remote MCP) and using Claude.ai's Custom Connector feature would bypass this restriction? This is acceptable for us if confirmed.

We are happy to provide additional logs, packet captures, or process inspection details on request. The full diagnostic chain is documented and reproducible.

Best regards,

What Should Happen?

We expect to use the instana extension in claude desktop to get connected to local instana instances as well without certification issues when public certificates are used.

Error Messages/Logs

Steps to Reproduce

Install Claude Desktop
Install Instana Extension provided by Anthropic
Configure the extension against the local instana server with api key connection
Try to use the extension and read data from instana from a claude desktop chat.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_