Follow Discord
Sweep 06 Nov 2026 · 01:32Z Build v2.1.319 537 read Stable v2.1.311 Latest v2.1.318 Next v2.1.319 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.267 ·

Tool-entry dedup logic loosened in schema-change tracking

Tool-entry dedup when tracking schema changes now only checks against already-kept entries, not a separate reference set

Under the hood Internal Changes
JSON All of v2.1.267
Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
MCPArea: what it touches
Internal ChangesKind: in v2.1.267,
Internal ChangesSection of the release

Unclear What visible effect this has for users, since the finding only describes the internal dedup condition, not its downstream consequence.

What

In the internal logic that tracks which tool entries are kept, stripped, or removed when a tool's schema changes, an entry is no longer excluded from the "kept" list just because a tool of the same normalized name exists in a separate reference set. Now, an entry is only blocked from being added if it's already in the kept list itself.

Why

This loosens the deduplication rule, which likely means fewer tool entries get incorrectly dropped from the kept list during schema-change tracking, though the finding doesn't specify the exact downstream effect.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhat visible effect this has for users, since the finding only describes the internal dedup condition, not its downstream consequence.

See this entry in the whole of v2.1.267 →

Feedback