[BUG] HTTP_PROXY/HTTPS_PROXY stripped from PowerShell/Bash tool subprocess env on Windows (NO_PROXY survives)

Open 💬 0 comments Opened Jun 17, 2026 by Kazunori-Sato

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

Environment

  • Claude Code version: 2.1.179
  • OS: Windows 11 Enterprise 10.0.26200
  • Shell tool: PowerShell (pwsh 7.6.2), with CLAUDE_CODE_USE_POWERSHELL_TOOL=1
  • Network: mandatory corporate authenticating proxy

Bug Description

HTTP_PROXY / HTTPS_PROXY are NOT present in the environment of the shell subprocess that Claude Code spawns for the PowerShell tool, even though they are configured. Critically, **NO_PROXY from the same settings.json env block DOES reach the subprocess** — only the proxy-endpoint variables are missing. This strongly suggests Claude Code consumes HTTP_PROXY/HTTPS_PROXY for its own networking and removes them from the environment passed to spawned tools.

Steps to Reproduce

  1. On Windows, set in ~/.claude/settings.json:

``json
"env": {
"HTTP_PROXY": "http://user:***@proxy.example.com:8080",
"HTTPS_PROXY": "http://user:***@proxy.example.com:8080",
"NO_PROXY": "localhost,127.0.0.1,internal.example.com",
"CLAUDE_CODE_USE_POWERSHELL_TOOL": "1"
}
``

  1. Also set HTTP_PROXY/HTTPS_PROXY at the Windows User environment scope.
  2. In the PowerShell tool, run: echo "[$env:HTTP_PROXY] [$env:NO_PROXY]"

Expected Behavior

HTTP_PROXY (and HTTPS_PROXY) are present in the spawned shell, like NO_PROXY.

Actual Behavior

  • $env:HTTP_PROXY → empty, $env:HTTPS_PROXY → empty
  • $env:NO_PROXY → present (correct value)
  • A normal PowerShell in the same login session shows HTTP_PROXY correctly (from the User-scope variable). Only Claude Code's spawned pwsh lacks it.

What I ruled out (tested)

  • Sign-out / sign-in (fresh process tree): no effect.
  • Setting at OS User scope: present in normal pwsh, still stripped in the tool.
  • settings.json env: NO_PROXY propagates, HTTP_PROXY/HTTPS_PROXY do not.
  • The PowerShell tool runs pwsh -NoProfile, so a profile cannot re-add them.
  • The Bash tool only has them because BASH_ENV sources a profile that re-exports them — i.e. not inherited from Claude Code either.

Impact

Tools that rely solely on the HTTP_PROXY/HTTPS_PROXY env vars — AWS CLI, Python (requests/botocore), Node — cannot reach the network when run inside the PowerShell tool, breaking app testing behind a mandatory corporate proxy. Windows-native tools that use the system proxy (WinINET/WinHTTP) are unaffected.

Request

Pass HTTP_PROXY/HTTPS_PROXY through to spawned shell-tool subprocesses (as NO_PROXY already is), or provide a supported, documented mechanism to do so. Possibly a regression — please advise the last version where this worked.

View original on GitHub ↗