Claude Code's October 14 Update Quietly Fixed a Gateway Key Leak: Five Request Types Sent Your Third-Party Key to Anthropic

Buried in the October 14 Claude Code changelog update, among 131 bug fixes, are two "Fixed" lines that every Claude Code user routing through a third-party gateway should stop and read. The original wording is terse:

"Fixed the server-managed settings request to Anthropic carrying a third-party gateway's API key when a managed settings file sets ANTHROPIC_BASE_URL"

"Fixed feature flag, startup, fast mode, profile and feedback requests to Anthropic carrying the API key configured for a third-party gateway (ANTHROPIC_BASE_URL); Anthropic API keys are still sent"

In plain language: before this update, if you pointed ANTHROPIC_BASE_URL at a third-party gateway — OpenRouter, a company-built LLM gateway, a cloud provider's proxy — Claude Code sent your gateway API key, verbatim in the request headers, to Anthropic on six categories of requests.

Your model traffic genuinely went through the gateway. That part was fine. But five request types — feature flag, startup, fast mode, profile, feedback — plus the server-managed settings request, went to Anthropic's official endpoints carrying the gateway's key. Anthropic issued no CVE, no severity rating, no standalone security advisory — just two fix lines in a dated changelog section. A textbook quiet fix.

Unpacking the two fixes

The first fix targets the enterprise scenario. Many companies push Claude Code configuration to employees via MDM or a unified managed settings file, including ANTHROPIC_BASE_URL — employee traffic goes through the corporate gateway for auditing, billing, and content policy. The insidious part: the end user may have no idea their client is routed through a gateway at all. They believe they're talking to Anthropic directly, while their client quietly hands their gateway key to Anthropic, with no signal and no way to investigate.

The second fix has broader reach. Feature flag, startup, fast mode, profile, feedback — these are the routine background requests Claude Code fires at launch and during runtime: pulling feature-flag configuration, reporting a startup event, fetching a profile, sending feedback. They share one trait: invisible to the user, leaving no trace in the UI. You watch the pretty streaming output in your terminal, never suspecting that every so often, a key that belongs only to your gateway is being delivered to api.anthropic.com.

The second half of the fix note — "Anthropic API keys are still sent" — reveals a surgically precise fix. Anthropic didn't strip authentication from all requests to its endpoints. It distinguished between two kinds of keys: if yours is an official Anthropic key, it keeps being sent; only a third-party gateway's key (i.e., when ANTHROPIC_BASE_URL is customized) is now withheld from Anthropic-bound requests. This is a "route authentication by key ownership" fix, which tells us the bug lived in the client's authentication branching logic, not in some forgotten header cleanup.

Why this bug belongs to the nastiest category

The core security assumption of every gateway user is a single sentence: "My gateway key goes only to my gateway." This bug shattered exactly that assumption — in the most elusive way possible: the main path was completely correct.

Think about how a careful engineer validates a gateway setup. They capture packets to confirm model requests hit the gateway's host. They check the gateway console's request logs. They verify billing flows through the gateway's account. Every one of those checks passes, because model requests genuinely went to the gateway. The problem lived in requests nobody ever audits: who inspects the target domain and Authorization header of a feature-flag pull? Who imagines the "feedback" feature carries a gateway key?

This is a recurring pattern in the agent toolchain: the attack surface is not the main path, it's the side requests. The main path is where everyone looks — the best-documented, best-tested, first-reviewed. But behind a mature agent client, dozens of auxiliary requests keep things running: telemetry, feature flags, version checks, config sync, crash reporting. They're assumed harmless, invisible to security review, and they share the same authentication logic and configuration-reading path. One missed branch, and the key walks through the wrong door.

The agent ecosystem has run this script before. MCP tool descriptions truncated, prompt injection smuggled in via tool metadata, OAuth tokens logged verbatim — every time, it was an auxiliary channel, not the main path, that broke first. The Claude Code gateway key leak is this script's newest chapter, under the heading of authentication routing.

How it likely happened, technically: an honest speculation

The changelog gives no root-cause analysis, but the fix wording supports a fairly reliable reconstruction — and I'll mark clearly which sentences are fact and which are inference.

Fact: model requests through a custom ANTHROPIC_BASE_URL authenticated correctly; only Anthropic-bound side requests carried the wrong key; after the fix, "Anthropic API keys are still sent."

Inference: the Claude Code client likely has a unified request builder that reads the effective API key from configuration and stuffs it into every outbound request's Authorization header. Model requests were correctly routed to the gateway URL, so key and URL were paired. But feature flag, startup, and feedback requests target hardcoded Anthropic domains — they don't go through the gateway, yet shared the same "fetch the current key" logic. Result: a mismatched pairing — Anthropic's URL, the gateway's key.

Why is this inference reliable? Because "Anthropic API keys are still sent" exposes the shape of the fix: it wasn't "strip auth from Anthropic-bound requests," it was "at the point where the key is attached, ask whose key this is." If it's Anthropic's own, attach it; if it's a third-party gateway's, don't. That's key-ownership-based routing, which in turn confirms the bug's location: the authentication assembly layer, not the URL routing layer.

The lesson for developers is direct: when you write any client that emits multiple kinds of outbound requests, "whose key is this" and "who is this request for" must be two independent decisions — never assume they always agree. Any client supporting both custom base URLs and direct official access has a bug incubator at the intersection of those two decisions. Claude Code stepped in it; your agent gateway and your internal CLI tools deserve a self-audit against this case the next time you write auth logic.

Zooming out: not Claude Code's problem alone

The ANTHROPIC_BASE_URL / OPENAI_BASE_URL pattern — "swap the base URL to route through a gateway" — is the universal接入 pattern across the agent tool ecosystem: OpenRouter, Cloudflare AI Gateway, cloud vendors' model gateways, self-hosted LiteLLM proxies, all plug in through that environment variable. And "side requests don't honor the base URL" is the near-universal affliction of such clients — telemetry to the vendor, version checks to the official CDN, crash reports to the official endpoint. Those hardcoded official domains routinely get left out of the refactor that introduces base-URL overrides.

The difference is that most clients' side requests carry no credentials, or only anonymous telemetry IDs — so a wrong destination is a privacy footnote. What made the Claude Code case special: its side requests carried high-value key material — an API key that directly spends gateway quota. Same "side request, wrong door," but what it carries out the door determines the severity. That's why one vendor's one-line changelog fix goes unnoticed, while these two lines deserve an article of their own.

For gateway operators, there's another layer: once your gateway key has been sent to the upstream vendor, even a trusted one, even if "nothing happened," your threat model should treat it as a leak. Because "trusted" is not "authorized" — Anthropic was never authorized by your security policy to hold that key. Key management draws its lines at authorization boundaries, not trust levels. That's why this article lists key rotation as mandatory, not optional: the basis for rotation isn't "Anthropic will misbehave," it's "it shouldn't have it."

What we honestly don't know

Time to pause for an honesty check, because several things the changelog doesn't say are exactly what readers most want to know.

First, Anthropic published no CVE and no severity rating. The two fixes sit as ordinary bug-fix entries under a dated changelog section, lined up next to "fixed double-click word selection collapsing the row." Don't hallucinate this into a formal security incident response — by all public evidence, it wasn't one.

Second, whether Anthropic's servers logged or retained the keys is unknown. The changelog says only "no longer carried." It says nothing about what happened server-side to the requests that did carry them: rejected at auth, written to error logs, or recorded normally. Not a word. Any claim that "Anthropic wouldn't store your key" is speculation, and we don't print speculation.

Third, the affected version range is unknown. The changelog page groups by date and shows no version numbers (at the time of writing, sections are just "October 14, 2026" — no v2.1.x anywhere). So we cannot state "affected from x.y.z to x.y.z." All we can say: versions before the October 14 changelog update had the problem; versions after it contain the fix.

Writing "unknown" plainly isn't timidity — it's the only responsible way to report a security story like this. Inflating it into a catastrophe is wrong; waving it off as "fixed, move on" is equally wrong.

Timeline and blast radius: the fullest picture we can assemble

The timeline from known facts: on October 14, two fixes appeared under the "October 14, 2026" section of the official Claude Code changelog — two of 131 bug fixes, no CVE, no standalone advisory. The October 16 changelog section (the latest on the page at the time of writing) doesn't mention the issue again, suggesting the fix is considered complete. The start of the exposure window can't be determined — with no version numbers in the changelog, we know neither which release introduced the bug nor how long it silently existed. That's the other cost of a quiet fix: the fix is quiet, the introduction was quiet, and the length of the exposure window is a gap that can never be filled.

The blast radius breaks into three layers. First, individual gateway users who set ANTHROPIC_BASE_URL to a public gateway like OpenRouter. Their keys were sent to Anthropic; the risk depends on how Anthropic's servers handled those wrongly-keyed requests — unknown, hence rotation is the only safe answer. Second, the enterprise MDM scenario: employees routed through a gateway without knowing it, where the key may draw on company-wide gateway quota — one leaked key affects the whole organization's budget. Third, teams running self-hosted gateways: the key may front a directly-billed cloud channel, so in theory someone could spend your quota with it — "in theory," because we don't know whether Anthropic would ever use a received gateway key for anything, but "theoretically usable" alone triggers rotation.

One more group deserves a special reminder: teams running Claude Code in CI (Agent SDK, headless mode) with a gateway configured. Startup and feature-flag side requests fire there too, and CI machines — online around the clock, starting sessions frequently — may emit side requests far more often than a personal desktop. If your CI image pins an older Claude Code version, upgrading should jump to the top of your queue.

If you use a gateway, do three things now

The short version: upgrade, rotate, audit. In that order, skip none.

1. Upgrade to a version containing the October 14 changelog update. Run claude --version, then upgrade to the latest. Note the changelog page itself carries no version numbers, so "latest" is your target — don't hunt for a specific fixed version number, because the vendor never gave one. The fix is a client behavior change; no config change needed.

2. Rotate your gateway API key. This is the step the "it's fixed" mindset skips, but logically it's mandatory. Your gateway key was sent to Anthropic's servers, and whether Anthropic logged or retained it is unknown (see above). Once a key has left its authorized destination, conservative security practice allows exactly one move: replace it. Generate a new key in your gateway console (OpenRouter, cloud console, or self-hosted admin), update local and CI configs, revoke the old one. Ten minutes of work, negligible cost — skipping it is the expensive choice.

3. Audit the reach of enterprise managed settings. If you're the platform engineer or IT admin, find out: which devices and employees have ANTHROPIC_BASE_URL in their managed settings file? They're the population the first fix covers — and they may not know they're on a gateway. Send them a short note with three sentences: upgrade Claude Code, rotate personal gateway keys if any, ignore the panic outside this email. Also worth checking gateway-side request logs for anomalies toward api.anthropic.com. The client won't tell you the full history of the leak, but gateway-side key usage records at least confirm whether rotation was thorough.

If you've never set ANTHROPIC_BASE_URL and always used an official Anthropic key or subscription login, this fix doesn't concern you — "Anthropic API keys are still sent," and your request behavior is unchanged. You can close this tab.

A word for teams shipping agents to production

If you're rolling out agents across a company — unified gateway, unified auth, unified auditing — this incident belongs in your checklist, as a pattern, not as a case.

The pattern: every agent client emits two kinds of requests — the ones you ask it to make (model calls) and the ones it makes on its own (telemetry, feature flags, config sync, crash reports). The second kind usually outnumbers the first several times over, and its security properties — who it goes to, what auth headers it carries, how it retries on failure — almost never appear prominently in vendor docs. If your threat model covers only "model traffic goes through the gateway," you've covered half of it.

Three actionable suggestions. First, turn "who may receive this key" into a testable assertion, not a sentence in a doc: e.g., domain-allowlist the gateway key at your egress proxy and alert the moment any non-gateway-bound request carries it. Second, give agent-client upgrades the same response process as browser patches — this fix was quiet, no CVE feed will push it to you, and if you don't follow the changelog yourself you'll never know. Third, capture packets and look at the truth once in a while: run the client for ten minutes, list every outbound request's Host and Authorization header. Thirty minutes of that teaches you more about the tool you use than ten security blog posts.

Closing: a quiet fix is good news and bad news

The good news: Anthropic fixed it cleanly. Two fixes — one for enterprise managed-settings, one for five categories of side requests — with fine-grained, key-ownership-aware logic that doesn't disturb normal users. Anyone upgrading past October 14 no longer has the problem.

The bad news is the quietness itself. No CVE, no security advisory, no severity rating — meaning no standardized notification channel will ever put this in front of you. You have to build the habit of reading changelogs yourself, or rely on media you trust to watch them for you. This article exists to do that job.

Back to the opening sentence: a gateway user's core security assumption is "my gateway key goes only to my gateway." Every time that assumption breaks, it should come back hardened — not as another slogan, but as a rule that can be tested, alerted on, and audited. Next time it may not be Claude Code; it could be any agent client in your toolchain. When that happens, may your egress proxy tell you before the changelog does.