HTTP_PROXY/HTTPS_PROXY env vars not respected by azd CLI when invoked from VS Code extension on Windows
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 136
Description
## Environment
- OS: Windows 11 Enterprise (corp-managed)
- VS Code: latest
- Extension: ms-azuretools.azure-dev (latest)
- Network: corporate HTTPS-intercepting proxy
## Description
When zd CLI is invoked by the VS Code extension (for zd up, zd deploy, zd auth login, etc.), the CLI process does not consistently inherit proxy environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) from the Windows environment.
The extension spawns zd as a child process. On corp Windows machines where these vars are set as system-level environment variables, the spawned process sometimes fails to pick them up — resulting in network failures for Azure Resource Manager calls, template fetching, and Azure CLI auth flows. The failure mode is silent: the output shows a generic network error without indicating that proxy configuration is the root cause.
## Steps to Reproduce
1. Windows 11 corp machine with HTTPS_PROXY set as a system env var (not session-only)
2. Install the zure-dev extension
3. Open a project with zure.yaml and run Azure Developer CLI: Up from command palette
4. Observe: azd reports network/auth error; no proxy-related guidance in output
## Expected vs Actual Behavior
**Expected:** zd CLI spawned by the extension inherits system proxy env vars; alternatively, the extension reads http.proxy from VS Code settings and injects it into the child process environment.
**Actual:** zd bypasses the proxy and fails with opaque network errors on corp-proxy-gated networks.
## Additional Context
The zure-dev CLI itself has no dedicated proxy configuration option documented in its help output or docs site. A section in the extension README covering HTTP_PROXY/HTTPS_PROXY and how to verify they are active (e.g. via zd env show) would help corp users.
Contributor guide
Assessment
This issue has not been assessed yet.