[FEATURE] Claude Desktop (MSIX): Support interactive proxy authentication (NTLM) for corporate VPN environments

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Impact: Claude Desktop is completely unusable on corporate VPN networks with
NTLM-authenticated proxies.
Affected platform: Windows 11, MSIX package only.
Workaround available: No (browser-only alternative exists, losing all Desktop features).

Tags: proxy, NTLM, MSIX, Windows, authentication, corporate, Electron, Chromium,
HTTP-407, PAC, VPN

---

Claude Desktop (MSIX package on Windows 11) cannot connect through corporate proxies
that require NTLM authentication when a VPN is active.

Root cause: The Chromium renderer inside Claude Desktop reads the Windows system proxy
settings but does not show an authentication popup when the proxy returns HTTP 407.

Effect: The app shows "Unable to connect to Claude" with no recovery path for the user.

Context: Other Chromium-based apps (Chrome, Edge) handle this correctly by showing a
native Windows authentication dialog via WinINet. Claude Desktop has no equivalent
mechanism.

Additional constraint: Environment variables (HTTPS_PROXY, HTTP_PROXY) set via
settings.json or batch file are not propagated to the Chromium renderer due to MSIX
sandbox restrictions, making local relay proxies (CNTLM, Px) ineffective as workarounds
even when they successfully authenticate to the upstream proxy.

Related issue: #45994 (same problem affecting Cowork VM).

Proposed Solution

Claude Desktop should handle proxy authentication in one or more of these ways:

1. Show a native Windows authentication popup when the proxy returns HTTP 407,

as Chrome and Edge do via WinINet.

1. Add a "Network / Proxy" section in Claude Desktop Settings where users can

manually configure:

• Proxy URL (e.g., http://proxy.company.com:8080)
• Authentication credentials (username/password or NTLM)
• NO_PROXY exceptions list
• Custom CA certificate path (for SSL inspection environments)

1. Ensure that HTTPS_PROXY / HTTP_PROXY set in settings.json are propagated

to the Chromium renderer process, not just to Claude Code CLI — so that
local relay proxies (Px, CNTLM) can be used as a workaround in enterprise
environments where changing the Windows system proxy is not permitted
by company policy.

Alternative Solutions

The following workarounds were attempted and confirmed unsuccessful:

1. HTTPS_PROXY / HTTP_PROXY via settings.json

• Tested in: ~/.claude/settings.json and MSIX LocalCache path
• Result: Read by Claude Code CLI, ignored by Chromium renderer (MSIX restriction)

1. Windows User and Machine environment variables

• Result: Ignored by Claude Desktop Chromium renderer regardless of scope

1. proxy field in claude_desktop_config.json

• Tested formats: pac+ and http://
• Result: File is read, but proxy setting has no effect on Chromium renderer

1. Local relay proxy with CNTLM

• Result: Listens on localhost but receives no traffic from Claude Desktop
• Confirmed via verbose CNTLM logs (no incoming connections)

1. Local relay proxy with Px (genotrance/px)

• Result: Successfully authenticates to corporate proxy (HTTP 200 tunnel

established, confirmed via verbose logs), but Claude Desktop does not
route traffic through it — MSIX apps do not inherit environment variables
from parent process

• Note: Px correctly interprets PAC file (iso-8859-1 encoding) and resolves

the correct upstream proxy server

1. Batch file launch setting HTTPS_PROXY before starting Claude.exe directly

• Result: Environment variables not propagated to MSIX process

Current workaround: Opening claude.ai in a browser (Chrome/Edge) before connecting
to VPN keeps the session alive. Claude Desktop has no equivalent workaround and
loses all Desktop-exclusive features (Claude Code, MCP connectors, Cowork).

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A consultant working for a large enterprise connects daily to a corporate VPN
that routes all internet traffic through an NTLM-authenticated proxy.

Step 1: User opens Claude Desktop while connected to the corporate VPN.
Step 2: Claude Desktop detects the system proxy but cannot authenticate (HTTP 407).
Step 3: App shows "Unable to connect to Claude" — no credential prompt, no recovery path.
Step 4: User tries HTTPS_PROXY via settings.json and Windows environment variables
— all ignored by Chromium renderer due to MSIX restrictions.
Step 5: User sets up Px local relay proxy — successfully authenticates to corporate
proxy (verified via logs), but Claude Desktop does not route traffic through it.
Step 6: User is forced to use claude.ai in a browser, losing Claude Code, MCP
connectors, and Cowork features entirely.

Expected behavior at Step 2: A native Windows credential dialog (as shown by Chrome
and Edge) would allow the user to enter proxy credentials, and the app would connect
normally.

Additional Context

Technical Analysis

Root cause (identified): Claude Desktop MSIX uses a Chromium renderer that reads
the Windows system proxy but does not implement interactive proxy authentication
(HTTP 407 challenge-response). Chrome and Edge handle this via WinINet, which
surfaces a native Windows credential dialog. Claude Desktop has no equivalent.

MSIX sandbox restriction: Environment variables set in settings.json, Windows
User/Machine scope, or a parent batch process are not propagated to the Chromium
renderer process. This is a known MSIX security behavior and makes local relay
proxies ineffective as workarounds, even when they successfully authenticate to
the upstream proxy (confirmed via verbose logs showing HTTP 200 tunnel established).

PAC file: Corporate network uses PAC file for proxy auto-configuration. Px correctly
interprets the PAC file (iso-8859-1 encoding) and routes traffic to the correct
upstream proxy. The missing piece is only Claude Desktop routing its traffic through Px.

What works (confirmed): Px successfully authenticates to the corporate NTLM proxy
(HTTP 200 tunnel established to api.anthropic.com, confirmed via PowerShell test).
Claude Desktop does not send traffic to Px.

Log Evidence (from Claude Desktop main.log)

• "proxy for https://claude.ai resolved (proxied)" → proxy is detected correctly
• "Bootstrap API returned 407" → authentication challenge not handled
• "net::ERR_TUNNEL_CONNECTION_FAILED" → tunnel cannot be established

Reference Issues

• #45994 — same problem affecting Cowork VM (NTLM proxy, no workaround)
• #29367 — Cowork Windows: API unreachable behind corporate NTLM proxy
• #4560 — Feature request: Windows Integrated Authentication for corporate proxies

Similar Features in Other Tools

• Chrome/Edge: native WinINet proxy authentication popup on HTTP 407
• VS Code: supports proxy settings via settings.json including authenticated proxies
• Px proxy (genotrance/px): open source tool that bridges NTLM auth for

Electron/non-WinINet apps — could serve as reference implementation

Environment

• OS: Windows 11 Enterprise
• Claude Desktop: MSIX package (Claude_pzs8sxrjxfjjc)
• Proxy type: NTLM + Basic (Griffon - corporate web gateway)
• Proxy config: PAC file auto-configuration
• VPN: Always-on corporate VPN (forces all traffic through proxy)
• Tested Claude Desktop versions: multiple recent versions