Description
When HTTP_PROXY / HTTPS_PROXY is set alongside NO_PROXY, the CLI ignores NO_PROXY entirely. Every request — including MSAL authentication to login.microsoftonline.com — is tunneled through the proxy, even if the destination matches a NO_PROXY pattern.
This is a problem in corporate environments where proxy is required for general traffic but Microsoft OAuth endpoints must be accessed directly (because the proxy blocks them).
Root cause: In src/request.ts (~line 157), the proxy is applied unconditionally:
const proxyUrl = process.env.HTTP_PROXY || process.env.HTTPS_PROXY;
if (proxyUrl) {
options.proxy = this.createProxyConfigFromUrl(proxyUrl);
}NO_PROXY / no_proxy is never checked. This also affects MSAL auth flows because MsalNetworkClient.ts delegates to the same request.ts → Axios path.
Steps to reproduce
- Set environment variables:
HTTP_PROXY=http://your-corp-proxy:port
NO_PROXY=*.microsoftonline.com,*.microsoft.com,*.azure.net
- Run
m365 login
- Observe:
ClientAuthError: network_error: Network request failed
- Clear
HTTP_PROXY, run m365 login again → succeeds
Expected results
The CLI should respect NO_PROXY (and no_proxy). When a request URL matches a NO_PROXY pattern, proxy should be bypassed — consistent with how curl, wget, Python requests, and Node.js undici/fetch all behave.
Actual results
All requests go through the proxy regardless of NO_PROXY. MSAL auth fails with network_error because the corporate proxy blocks OAuth endpoints.
Diagnostics
Traced through the source:
src/request.ts line ~157: reads HTTP_PROXY/HTTPS_PROXY, never reads NO_PROXYsrc/auth/MsalNetworkClient.ts: overrides MSAL's default HttpClient, routes through Axios via request.ts- Zero occurrences of
NO_PROXY or no_proxy in the entire codebase
Suggested fix
In request.ts:
const proxyUrl = process.env.HTTP_PROXY || process.env.HTTPS_PROXY;
const noProxy = process.env.NO_PROXY || process.env.no_proxy;
if (proxyUrl && !shouldBypassProxy(requestUrl, noProxy)) {
options.proxy = this.createProxyConfigFromUrl(proxyUrl);
}With a shouldBypassProxy() helper that parses NO_PROXY comma-separated patterns (supporting *.domain.com, .domain.com, and bare domain.com forms per convention).
Additional Info
- CLI version: v11.5.0
- Node.js version: v24.12.0
- OS: Windows
- Shell: PowerShell
Workaround: temporarily clear HTTP_PROXY before running m365 commands.
Related closed issues: #2698, #6692, #3531 (same symptom, but NO_PROXY was never identified as root cause or fixed).
Description
When
HTTP_PROXY/HTTPS_PROXYis set alongsideNO_PROXY, the CLI ignoresNO_PROXYentirely. Every request — including MSAL authentication tologin.microsoftonline.com— is tunneled through the proxy, even if the destination matches aNO_PROXYpattern.This is a problem in corporate environments where proxy is required for general traffic but Microsoft OAuth endpoints must be accessed directly (because the proxy blocks them).
Root cause: In
src/request.ts(~line 157), the proxy is applied unconditionally:NO_PROXY/no_proxyis never checked. This also affects MSAL auth flows becauseMsalNetworkClient.tsdelegates to the samerequest.ts→ Axios path.Steps to reproduce
m365 loginClientAuthError: network_error: Network request failedHTTP_PROXY, runm365 loginagain → succeedsExpected results
The CLI should respect
NO_PROXY(andno_proxy). When a request URL matches aNO_PROXYpattern, proxy should be bypassed — consistent with howcurl,wget, Pythonrequests, and Node.jsundici/fetchall behave.Actual results
All requests go through the proxy regardless of
NO_PROXY. MSAL auth fails withnetwork_errorbecause the corporate proxy blocks OAuth endpoints.Diagnostics
Traced through the source:
src/request.tsline ~157: readsHTTP_PROXY/HTTPS_PROXY, never readsNO_PROXYsrc/auth/MsalNetworkClient.ts: overrides MSAL's default HttpClient, routes through Axios viarequest.tsNO_PROXYorno_proxyin the entire codebaseSuggested fix
In
request.ts:With a
shouldBypassProxy()helper that parsesNO_PROXYcomma-separated patterns (supporting*.domain.com,.domain.com, and baredomain.comforms per convention).Additional Info
Workaround: temporarily clear
HTTP_PROXYbefore runningm365commands.Related closed issues: #2698, #6692, #3531 (same symptom, but
NO_PROXYwas never identified as root cause or fixed).