{"version":"2.1.284","anchor":"proxyauthhelpers-proxy-authorization-header-now-sent-throug","canonical_anchor":"proxyauthhelpers-proxy-authorization-header-now-sent-throug","heading":"Proxy sign-in from proxyAuthHelper is now sent on more connections","tier":"notice","area":"Internals","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284\/e\/proxyauthhelpers-proxy-authorization-header-now-sent-throug","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.284","markdown":"### Proxy sign-in from `proxyAuthHelper` is now sent on more connections\n\nThe proxy sign-in header produced by `proxyAuthHelper` is now also attached to connections made through Claude Code's other proxy route\n\n**Unclear.** It is not clear which of Claude Code's requests go through the route that now gets the header.\n\n**What**\n\nThe `proxyAuthHelper` setting names a command that prints a sign-in value for a proxy server that requires one. Claude Code sends that value in a `Proxy-Authorization` header. It has two internal ways of making connections through a proxy, and before, only one of them attached this header. Now both do, using the value the helper last returned. Client certificates and the `CLAUDE_CODE_PROXY_RESOLVES_HOSTS` behaviour are unchanged.\n\n**Why**\n\nIf you work behind a proxy that requires sign-in, some connections could fail even with `proxyAuthHelper` set up. Those connections should now carry the sign-in value too.\n\n- Area: Internals\n- Names: `proxyAuthHelper`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}