IDE websocket silently proxied (and can outright fail) when lowercase no_proxy lacks loopback under NODE_USE_ENV_PROXY=1

Summary

With NODE_USE_ENV_PROXY=1 (Node's native env-proxy mode), Claude Code's /ide websocket (ws://127.0.0.1:<port> to the VS Code extension) is sent to the configured HTTPS_PROXY/HTTP_PROXY even when an uppercase NO_PROXY correctly lists localhost,127.0.0.1 — as long as a lowercase no_proxy is also set and does not itself contain a loopback entry.

Root cause appears to be Node resolving the lowercase variable first: process.env.no_proxy ?? process.env.NO_PROXY. A lowercase no_proxy without loopback silently overrides a correct uppercase exemption, so the loopback bypass Claude Code presumably intends never takes effect.

Impact is proxy-dependent:

• Permissive proxies (e.g. mitmproxy) forward the loopback CONNECT/upgrade without complaint — /ide appears to work, but local IDE traffic is transiting the proxy that it should never reach (audit/privacy concern, and needless dependency on proxy health for a purely local connection).
• Stricter proxies (common in corporate/auditing setups) refuse or mishandle the loopback upgrade — /ide fails outright with "Failed to connect to Visual Studio Code."

Both are the same underlying bug; which one you see just depends on how tolerant your proxy is of a loopback CONNECT it shouldn't have received in the first place.

Environment

• Claude Code 2.1.215, Node-bundled CLI
• macOS (Darwin 25.5)
• NODE_USE_ENV_PROXY=1

Repro

Throwaway local proxy (mitmproxy, standing in for any corporate/MITM proxy):

mitmdump -p 18080

In a second terminal, cd into the folder VS Code has open, then:

Run A — lowercase no_proxy missing loopback, uppercase NO_PROXY correct:

env NODE_USE_ENV_PROXY=1 HTTPS_PROXY=http://127.0.0.1:18080 HTTP_PROXY=http://127.0.0.1:18080 \
    no_proxy=example.com NO_PROXY=localhost,127.0.0.1 \
    claude

Then /ide.

Observed: /ide reports connected, but the proxy log shows the IDE websocket transited the proxy:

server connect 127.0.0.1:13447
GET http://127.0.0.1:13447/ << 101 Switching Protocols
[... websocket frames ...]
[... closed, code 1000]

(13447 was the VS Code extension's loopback port for this session.)

Run B — lowercase no_proxy includes loopback (uppercase NO_PROXY unchanged from Run A):

env NODE_USE_ENV_PROXY=1 HTTPS_PROXY=http://127.0.0.1:18080 HTTP_PROXY=http://127.0.0.1:18080 \
    no_proxy=example.com,localhost,127.0.0.1 NO_PROXY=localhost,127.0.0.1 \
    claude

Then /ide.

Observed: /ide connects, and the proxy log has zero entries for port 13447 — loopback correctly bypassed the proxy entirely.

The only variable that changed between Run A and Run B is the lowercase no_proxy value; uppercase NO_PROXY is identical in both, and correctly lists the loopback addresses in both.

(A prior pass without NODE_USE_ENV_PROXY=1 connected cleanly in both runs — the bug requires Node's native env-proxy mode to trigger.)

Asks

1. Never route the IDE loopback websocket through a proxy at all — it's a local connection to a local editor extension and has no reason to be proxy-aware. Failing that, at minimum honor loopback in NO_PROXY regardless of whether a lowercase no_proxy is also set.
2. Document the lowercase-first precedence (no_proxy before NO_PROXY) in the network-config docs, since today only uppercase NO_PROXY is documented and users have no way to know a stray lowercase var will silently take priority.

Related issues

• #1868 — lowercase proxy vars unsupported (API traffic; open, unanswered) — same case-precedence root cause, different traffic path
• #39862 — NO_PROXY ignored for base-URL requests (v2.1.83; open)
• #15684 — VS Code extension ignores proxy settings (closed, not planned) — related surface, different direction (this issue is Claude Code's client wrongly proxying, not the extension)