{"version":"2.1.314","anchor":"authorization-header-handling-refactored-now-also-applies-t","canonical_anchor":"authorization-header-handling-refactored-now-also-applies-t","heading":"Authorization header rewriting extended to a second kind of network request","tier":"internal","area":"Internals","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314\/e\/authorization-header-handling-refactored-now-also-applies-t","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.314","markdown":"### Authorization header rewriting extended to a second kind of network request\n\nThe rule that rewrites the Authorization header on Claude Code's requests now has a version for a second kind of request as well\n\n**What**\n\nThe Authorization header is the part of a network request that carries your login credentials. Claude Code already rewrote this header on one kind of outgoing request. That decision is now a shared step, and a new helper applies the same rewrite to requests made through the standard `fetch` method as well.\n\n**Why**\n\nThe same credential handling can now cover more than one kind of request. That could stop an out-of-date login token from being sent on requests the old rewrite did not reach.\n\n- Area: Internals\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no"}