Adds NO_PROXY support for proxy configuration. Closes #7165

[Zekai-Zhao-321]

Summary

• Adds shouldBypassProxy() method to request.ts that checks NO_PROXY/no_proxy environment variables before applying proxy configuration
• Supports standard patterns: exact hostname, *.domain.com, .domain.com, and * (bypass all)
• Sets proxy: false explicitly when bypassing to prevent Axios from falling back to its own env-var proxy detection
• Updates proxy documentation with NO_PROXY usage and supported patterns

Closes #7165

Test plan

• npm run build passes
• All 9 new NO_PROXY tests pass
• Existing proxy tests still pass (proxy applied when NO_PROXY doesn't match)
• Verified end-to-end behind a corporate proxy with HTTP_PROXY and NO_PROXY set — m365 status and m365 teams chat list both succeed without a wrapper workaround

[waldekmastykarz]

This shouldn't be necessary. Axios, which we're using for handling HTTP requests, supports NO_PROXY natively. Before we start changing the code, let's understand what's wrong exactly.

[Zekai-Zhao-321]

Thanks for the review. You're right, Axios handles NO_PROXY natively via proxy-from-env. I traced through why it doesn't work today and through the history of how the current code got here.

The root cause is the manual proxy code from #2698. createProxyConfigFromUrl reads HTTP_PROXY/HTTPS_PROXY and sets options.proxy explicitly on every request. When Axios sees an explicit proxy config, it skips its native proxy-from-env resolution entirely, which is where NO_PROXY is handled. In Axios's setProxy function: if proxy is already set (not undefined or false), the proxy-from-env call never runs.

When #2698 was merged (March 2023), there were two separate HTTP stacks in the CLI. MSAL v2.6.0 had its own HttpClient built on raw Node.js http/https modules, not Axios. It accepted a proxyUrl config and implemented proxy tunneling via http.request() with HTTP CONNECT. The CLI's data requests (Graph, SharePoint, etc.) went through request.ts which used Axios. #2698 added proxy support to both paths. For the MSAL side, proxyUrl had to be set explicitly because MSAL's HttpClient was its own implementation. For request.ts, the same pattern was replicated (read env vars, build proxy config), but Axios already handled HTTP_PROXY/HTTPS_PROXY natively via proxy-from-env. Axios 1.6.4 with proxy-from-env 1.1.0 was already in use at that point, and the setProxy behavior was identical to the current version.

Later, when MSAL upgraded from v2 to v5, it switched from raw http/https to native fetch(), which has no proxy support. The proxyUrl config was removed. That broke auth behind proxies, which #6290 (April 2025) fixed by adding MsalNetworkClient to route MSAL's HTTP through request.ts and Axios. That unified everything through one path, but also meant both auth and API requests now go through the manual proxy code that blocks Axios from checking NO_PROXY.

In the initial PR I kept the manual proxy code intact since I wasn't sure if removing it would break anything. Looking at it more closely, removing it and letting Axios resolve everything natively is the cleaner fix. The 4 existing proxy tests that inspect the options.proxy config object would be removed along with createProxyConfigFromUrl.

Separately, createProxyConfigFromUrl also hardcodes protocol: 'http' regardless of the actual proxy URL scheme. That's unrelated to NO_PROXY, but would also be resolved by switching to native handling.

I'm thinking the right fix is to remove the manual proxy code entirely and let Axios handle everything natively. Happy to rework the PR.

This shouldn't be necessary. Axios, which we're using for handling HTTP requests, supports NO_PROXY natively. Before we start changing the code, let's understand what's wrong exactly.