Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeReleasesv2.1.238entry #19

Claude Code v2.1.238 ·

The MCP discovery cache is now off unless explicitly turned on

The MCP discovery cache flipped from on-by-default to off unless the server or you enable it.

You'll notice Notable Nothing to try yet In Development
JSON All of v2.1.238
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
MCPArea: what it touches
In DevelopmentKind: in v2.1.238,
What probably matters to youSection of the release

The cache now resolves "not-enabled" unless MCP_DISCOVERY_CACHE is exactly true, taking this release's whole MCP account-switch rework dark with it.

What

The cache that remembers MCP server discovery between runs was previously armed with a kill switch defaulting to on. It is now controlled by tengu_mcp_discovery_cache_enable, whose built-in fallback is null, so it reports "not-enabled" unless the server returns true or MCP_DISCOVERY_CACHE is set to exactly true. Everything else in this release's MCP account-switch rework hangs off the same check and is therefore dark on a default build.

Details
  • With the cache off, the process-wide account epoch never advances, so every abort path that compares it is inert, along with cached-connection reuse, the background refresh tracking, the disabled-server check and the identity-purge helper.
  • When enabled, the cache now records settled cached-dial failures and refused rows, emits a "strike" on revalidation failure, and tracks in-flight refresh dials so a server is not reported connected while its refresh is pending.
  • An entry is dropped when the server negotiates a different protocol era on revalidation.
  • Two new ineligibility reasons: "identity-changed" for an account switch during the process, and "ambient-credential" for servers whose URL implies an ambient credential.
  • Corrupt or oversize entries now report telemetry under mcp_discovery_cache / corrupt_entry, and the log line names the entry's own reason instead of always saying "oversize".
Evidence

tengu_mcp_discovery_cache_enable, if (V.MCP_DISCOVERY_CACHE !== !0 && e !== !0) return "not-enabled";, Discovery cache entry dropped: server negotiated a different protocol era on revalidation

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

Read from
Names in the bundleMCP_DISCOVERY_CACHE
Feature flag
tengu_mcp_discovery_cache_enable Not enough to say

Nothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.

This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.238: not a boolean we can read

Read once, for one account on one subscription tier, against v2.1.238. It isn't a statement about your account. What a flag value here can and cannot tell you

How sure we are
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this buildNew in this build: tengu_mcp_discovery_cache_enable

See this entry in the whole of v2.1.238 →

Feedback