Claude Desktop Code tab ignores NODE_EXTRA_CA_CERTS on Windows MSIX install behind corporate SSL proxy

[cd1amond]

Environment

• Claude Desktop version: 1.14271.0.0 (MSIX/Windows Store install)
• Platform: Windows 11 Enterprise
• Backend: Corporate LMG gateway behind SSL inspection proxy (self-signed cert)
• Leidos Cloud PKI Root CA-2 installed in Windows trusted root store

Describe the bug

The Claude Desktop Code tab fails with a cert error when behind a corporate SSL inspection proxy, even after correctly configuring NODE_EXTRA_CA_CERTS. The terminal Claude Code CLI works fine with the same cert configuration.

Error shown in Code tab:

API Error: Unable to connect to API: Self-signed certificate detected. Check your proxy or corporate SSL certificates

Exit code in logs:

Failed to get commands from temporary query {
  error: Error: Claude Code process exited with code 3

What was tried

1. NODE_EXTRA_CA_CERTS set as a Windows User environment variable pointing to the CA cert — ignored by Desktop (MSIX sandboxed app does not inherit Windows user env vars)
2. env block added to claude_desktop_config.json with NODE_EXTRA_CA_CERTS — Desktop rewrites this file on every restart, stripping unknown fields including the env block
3. NODE_EXTRA_CA_CERTS added to settings.json env block — passed to the claude.exe subprocess but the Electron layer itself still fails cert validation before the subprocess starts
4. CA cert imported into Windows LocalMachine\Root trusted store — Electron ignores Windows system cert store and uses its own bundled store

Root cause

Claude Desktop's Electron layer uses its own bundled cert store and does not use NODE_EXTRA_CA_CERTS or the Windows system cert store for its own TLS connections (OAuth, session init, etc.). The claude.exe subprocess it spawns can be configured via settings.json, but the Electron layer's startup queries (get commands, get agents) fail before the subprocess even starts.

Expected behavior

NODE_EXTRA_CA_CERTS configured in claude_desktop_config.json (or another durable config location) should be respected by the Electron process itself, not just the subprocess it spawns. Alternatively, an --use-system-ca-store flag or equivalent should be supported for enterprise deployments.

Workaround

Use the terminal Claude Code CLI instead of Desktop's Code tab. The CLI correctly reads NODE_EXTRA_CA_CERTS from settings.json env block and works behind the corporate proxy.

[hhmmkk]

Confirming the same issue in a different corporate environment
(Windows domain-joined PC, internal TLS inspection with a corporate CA chain).

Same pattern:

• Desktop app (MSIX 1.13576.4): Chat tab works, Code tab fails — in my case
  with API Error: Unable to connect to API: SSL certificate has expired
  (slightly different message from OP's, same root cause)
• Native Claude Code CLI v2.1.201 on the same machine: works with zero
  extra configuration (reads the Windows trust store)
• NODE_EXTRA_CA_CERTS set at both User and Machine level: ignored by the app

Additional data point: I captured the TLS chain actually served for
api.anthropic.com via an SslStream callback — all 4 certificates in the
corporate chain are valid (root NotAfter 2045), and SChannel validates it
cleanly. So the chain itself is trustable; the failure is entirely in how
the desktop app / Code subprocess resolves trust, consistent with OP's
root-cause analysis.

Given the Windows build is MSIX-only now, affected enterprise users have no
desktop workaround other than the terminal CLI.