web_fetch fails DNS validation in proxy-only environments despite working native HTTP transport (1.0.102) #5230

Describe the bug

The built-in web_fetch tool fails for public HTTPS URLs in a corporate proxy-only environment where local DNS does not resolve public destination hostnames. The configured HTTP CONNECT proxy can resolve and fetch those destinations successfully.

Both curl and the same installed Copilot CLI native HTTP transport can retrieve the page through the existing proxy without local destination DNS resolution.

Environment

• GitHub Copilot CLI: 1.0.102
• OS: Linux on WSL2 / Windows
• Installation: npm (@github/copilot)
• System Node.js: v24.18.0
• Corporate HTTP CONNECT proxy: Zscaler
• HTTP_PROXY, HTTPS_PROXY, and lowercase equivalents are configured and inherited.
• no_proxy does not exclude the tested public destinations.
• NODE_EXTRA_CA_CERTS points to the trusted system CA bundle.

Steps to reproduce

1. Use an environment where public Internet access works through an HTTP CONNECT proxy, but local DNS returns NXDOMAIN for public destination hostnames.
2. Configure HTTP_PROXY, HTTPS_PROXY, and required CA trust.
3. Ask Copilot CLI to fetch https://docs.github.com/ or https://example.com/ using built-in web_fetch.
4. Compare with the following request from the same environment:

curl --fail --silent --show-error --location \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -w 'HTTP %{http_code}; TLS verify %{ssl_verify_result}\n' \
  https://docs.github.com/

Actual behavior

Both tested destinations fail in web_fetch with:

WebFetchBlockedUrlError: failed to lookup address information: Name or service not known

Diagnostic evidence

For the last comparison, I loaded runtime.node from the installed CLI 1.0.102 package and invoked networkFetchStreamStart with a GET request, redirect: "follow", pinnedAddresses: [], and allowLocalhost: false. The proxy environment was unchanged. This was a diagnostic transport probe, not a proposed replacement for URL validation.

This isolates the observed failure to local destination resolution in the built-in tool's validation path, rather than missing proxy variables, TLS trust, or a WSL-only DNS problem. The precise internal validation implementation has not been verified from source.

Expected behavior

Please provide a supported, security-preserving way for web_fetch to work when the configured proxy handles destination DNS and local public-name resolution is unavailable.

If local destination DNS is an intentional prerequisite, please document that limitation and return an actionable error distinguishing it from proxy connectivity or TLS problems.

This is not a request to disable SSRF protection, allow private/loopback/metadata destinations, or bypass corporate network policy. Any solution needs appropriate destination and redirect validation.

Related issues

• web_fetch rejects public domains resolved to Surge Fake-IP addresses on macOS (CLI 1.0.98) #5180: related conflict between local address validation and proxy-managed DNS, but concerns Fake-IP addresses rather than unavailable resolution / NXDOMAIN.
• Any web_fetch: TypeError: fetch failed #3948: previous proxy failures were marked resolved as of 1.0.88; this failure reproduces on 1.0.102.
• Built-in web_fetch does not work with HTTP proxies #4019: previous built-in web_fetch proxy support report.

Workaround

Use shell curl through the configured proxy. No system DNS settings, CLI package files, TLS verification settings, or URL-safety checks were modified during investigation.