Support NTLM fallback for Negotiate-authenticated corporate proxies #5407

Describe the feature or problem you'd like to solve

Support Windows Integrated Authentication when a corporate HTTP proxy advertises Negotiate and SSPI selects NTLM instead of Kerberos. In this environment Copilot CLI 1.0.107 cannot fetch destinations requiring proxy authentication, although other destinations, model requests, and a Negotiate-capable curl request work through the same proxy.

Proposed solution

Support the NTLM fallback selected by Windows SSPI during proxy Negotiate, or provide another supported way for Copilot CLI and its web_fetch tool to use Windows-integrated proxy authentication. Preserve the existing URL and destination security checks. If this authentication mode is intentionally unsupported, report that actionable reason to the user instead of only a generic transport failure.

Example prompts or workflows

• Fetch the title or content of https://example.com/ using web_fetch in a corporate Windows environment.
• Fetch public documentation from destinations that require proxy authentication, without running a separate local authenticating proxy.

Additional context

Environment: GitHub Copilot CLI 1.0.107; Windows 11 Enterprise, build 26200, x64; Windows Terminal; corporate HTTP CONNECT proxy. HTTP_PROXY and HTTPS_PROXY were explicitly set to the same proxy. NODE_USE_ENV_PROXY=1 and NODE_USE_SYSTEM_CA=1 were set. The test ran in a separate prompt-mode session with isolated state and auto-update disabled. No TLS verification was disabled.

Minimal reproduction: replace proxy.example:3128 with a corporate proxy that advertises Negotiate and causes Windows SSPI to select NTLM. The proxy address below is a placeholder, not the tested address.

$env:HTTP_PROXY = 'http://proxy.example:3128'
$env:HTTPS_PROXY = $env:HTTP_PROXY
$env:NODE_USE_ENV_PROXY = '1'
$env:NODE_USE_SYSTEM_CA = '1'

curl.exe --proxy 'http://proxy.example:3128' --proxy-negotiate --proxy-user ':' https://example.com/
copilot --no-auto-update --no-custom-instructions --disable-builtin-mcps --model claude-haiku-5.5 --allow-url example.com -p 'Use web_fetch to read https://example.com/ and report the page title or the precise error.'

Observed comparison:

The proxy did not challenge the Python destination in the direct curl comparison, so a successful request to one host does not establish that authentication works for all destinations.

Extracted debug evidence (proxy host, SPN, credentials, and other metadata omitted):

proxy Negotiate probe complete
attempting proxy Negotiate authentication
proxy CONNECT response: scheme=Negotiate leg=0 status=407 offered_schemes=Negotiate NTLM Basic
proxy sent Connection: close on the initial 407 challenge, opening a fresh proxy connection to carry the first authenticated CONNECT
proxy CONNECT response: scheme=Negotiate leg=1 status=407 offered_schemes=Negotiate
proxy Negotiate tunnel failed: reason=negotiate_step_failed
error=proxy tunnel failed: tunnel CONNECT handshake failed: proxy negotiation failed: failed to advance proxy authentication: negotiate selected NTLM instead of Kerberos

The user-facing tool result says only web_fetch could not retrieve this URL: a transport-level failure (DNS, connection, or TLS handshake). The installed Windows curl build does not support --proxy-ntlm explicitly, and I did not establish which mechanism curl selected internally; the comparison only establishes that its --proxy-negotiate request succeeds.

Related issues: #523 covers Kerberos proxy support and was closed as completed; #5142 covers native HTTP MCP through Kerberos/Negotiate and was closed for 1.0.107; #3948 covers an earlier web_fetch proxy failure. #5230 concerns DNS resolution in a proxy-only environment and does not establish this NTLM selection failure.

AI-assisted with OpenCode.