## 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

Confirming this on a different configuration, which suggests the scope is broader than MSIX + gateway deployments. **Environment** - Claude Desktop version: 1.28929.0 (d1a6bc) - Install method: standard Windows installer (not MSIX / Microsoft Store) - Platform: Windows 11 - Backend: direct claude.ai sign-in — no LLM gateway involved - Corporate SSL inspection proxy with self-signed root CA **Same error, verbatim:** ``` API Error: Unable to connect to API: Self-signed certificate detected. Chec

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

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 3 comments · opened Jun 23, 2026

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

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)
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
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
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.

View original on GitHub ↗

3 Comments

hhmmkk · 1 month ago

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.

coraora · 17 days ago

Confirming this on a different configuration, which suggests the scope is broader than MSIX + gateway deployments.

Environment

Claude Desktop version: 1.28929.0 (d1a6bc)
Install method: standard Windows installer (not MSIX / Microsoft Store)
Platform: Windows 11
Backend: direct claude.ai sign-in — no LLM gateway involved
Corporate SSL inspection proxy with self-signed root CA

Same error, verbatim:

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

What rules out the certificate itself

The corporate root CA is installed in CurrentUser\Root, and Windows verifies the chain to api.anthropic.com successfully:

> curl.exe --ssl-no-revoke -I https://api.anthropic.com
HTTP/1.1 404 Not Found
Server: cloudflare
...

(404 is expected for the bare root path — the point is that the TLS handshake completed.) Without --ssl-no-revoke the same request fails only on CRYPT_E_NO_REVOCATION_CHECK, a Schannel revocation-endpoint check unrelated to chain trust.

So on this machine the chain verifies outside the app, and the Desktop Code tab still rejects it.

Also tried, no effect

NODE_EXTRA_CA_CERTS in %USERPROFILE%\.claude\settings.json env block
NODE_EXTRA_CA_CERTS as a Windows user environment variable
Root CA imported into CurrentUser\Root
Clean reinstall of Claude Desktop
Full quit via system tray between each attempt

Why this adds signal

The original report is MSIX-installed and behind a corporate LLM gateway, which leaves open that MSIX sandboxing or the gateway is a necessary condition. Neither is present here: standard installer, plain claude.ai login, Windows 11. That points at the Electron layer's bundled cert store as the sole cause, consistent with the root-cause analysis above.

Planning to move to the terminal CLI as a workaround.

coraora · 17 days ago

Follow-up to my comment above, with a finding that isolates this to the Electron layer more tightly.

Desktop downloads and manages its own Claude Code binary at %APPDATA%\Claude\claude-code\2.1.227\claude.exe. The VS Code extension on this machine launches that same binary — I have no claude on PATH and never installed the CLI separately.

Same binary, same version, same cert config, same machine, same proxy:

VS Code extension → connects and works normally
Desktop Code tab → fails with Self-signed certificate detected

The only variable is whether the Electron shell wraps the process, which matches the root cause described in the original report.

Also worth noting 2.1.227 is past the v2.1.217 change to settings-file handling in app-managed sessions, so that isn't the explanation here.