[BUG] proxyAuthHelper credential is applied only to model requests; bootstrap and feature-flag fetches CONNECT without Proxy-Authorization

Version: Claude Code 2.1.288, macOS (native install)

Setup

• HTTPS_PROXY points at a forward proxy that requires Proxy-Authorization on CONNECT (it answers 407 with a Proxy-Authenticate challenge otherwise).
• CLAUDE_CODE_ENABLE_PROXY_AUTH_HELPER=1, with proxyAuthHelper set in settings to a command that prints the credential.

What happens

• Messages API requests (POST /v1/messages) arrive on a tunnel that carries the helper's credential. Works as expected.
• Other requests to api.anthropic.com open their CONNECT with no Proxy-Authorization header, and do not retry after the 407:
• the feature-flag fetch: claude remote-control then fails with "Couldn't verify Remote Control eligibility — the feature-flag service was unreachable";
• GET /api/claude_cli/bootstrap: observed arriving on an unauthenticated tunnel; behind a proxy that refuses those, bootstrap data (additional_model_options and the rest) never arrives.
• Measured with a CONNECT-logging shim in front of the proxy: repeated CONNECT api.anthropic.com:443 with no auth header → 407, followed by the Remote Control eligibility failure. With the same credential embedded in the proxy URL instead (http://user:token@proxy:port), every CONNECT is authorized and Remote Control works.

Expected
Every connection Claude Code opens through HTTPS_PROXY uses the proxyAuthHelper credential (or answers a 407 challenge with it), not only the Messages API client.

Why the workarounds are poor

• Credential in the proxy URL: static, so it cannot be refreshed the way the helper can, and it is inherited by every child process (MCP servers, hooks, tools).
• Letting the proxy accept unauthenticated CONNECTs to api.anthropic.com: works, but the proxy can no longer tell which machine a request came from, which is the point of proxy authentication.