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

Claude Code v2.1.248 ·

Retaining tool definitions across context loss and credential changes, off by default

Tool definitions could survive context loss and credential changes, but both halves are off.

Nothing to try yet In Development
JSON All of v2.1.248
Nothing to try yetTier: how much it should matter to you
2Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
ToolsArea: what it touches
In DevelopmentKind: in v2.1.248,
What probably matters to youSection of the release

Two server-controlled gates fall back to off, so behaviour is unchanged.

What

New machinery keeps dynamically loaded tool definitions usable after the messages that first declared them scroll out of the conversation window, and separately preserves already-built tool descriptions when your credentials or access token change rather than rebuilding them all. Both halves are behind server-controlled gates that fall back to off, so this build behaves exactly as before unless the server turns them on.

Details
  • Deferred tool retention is gated on tengu_plucky_orchard; if no server value comes back the feature resolves to off for the whole session and that decision is cached.
  • Retention is forced off when the environment variable CLAUDE_CODE_SIMPLE or CLAUDE_CODE_DISABLE_ATTACHMENTS is set.
  • Retained tools are tracked per tool-use id and tool name in a bounded map with a generation counter and a fail-closed latch, then spliced back into the tool list sent with the request.
  • The strict property is stripped from retained schemas when the request does not use structured outputs.
  • Logs Dynamic tool loading: keeping … departed deferred tool(s) declared; and emits the event mcp_kept_deferred_tools with kept_count, kept_mcp_count and stripped_reference_count; failures surface as plan_failed, retraction_failed or record_failed.
  • Credential-change retention is gated on tengu_still_kestrel, which would keep completed tool descriptions and discard only the ones still being built; with the gate off the whole per-host description cache is thrown away, which is the existing behaviour.
  • The tengu_still_kestrel reader is registered at startup and deliberately returns nothing when the value came from the compiled-in fallback, in which case the helper answers false. Nothing in this build sets a value for either gate.
Evidence

tengu_still_kestrel, tengu_plucky_orchard

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

Read from
Feature flag
tengu_still_kestrel Gate removed from the code

This release deleted the gate from the code while it was still reading on for the account this site reads, so the code path no longer asks a flag before running.

This account: on · anonymous baseline: on · compiled default in v2.1.248: not a boolean we can read

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

What has happened since
Flag reading moved The flag server now returns on for tengu_plucky_orchard, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Flag reading moved The flag server now returns nothing at all, having stopped carrying it for tengu_plucky_orchard, read as this account. A reading is one sample. Claude Code evaluates its flags remotely, so no client sees the targeting rule behind a value and this says nothing about your account.
Gate removed from the code v2.1.267 removed the tengu_plucky_orchard gate from the code while it was still reading on for the account this site reads. The code path no longer asks a flag before it runs.
Gate removed from the code v2.1.248 removed the tengu_still_kestrel gate from the code while it was still reading on for the account this site reads. The code path no longer asks a flag before it runs.

See this across every release →

See this entry in the whole of v2.1.248 →

Feedback