Sweep 19 Sep 2026 · 02:36Z Build v2.1.278 500 read Stable v2.1.267 Latest v2.1.278 Next v2.1.278 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.277 ·

New reserved-name lock for skills, commands and tools

Skills, commands and tools whose name collides with a reserved settings key now get a distinct 'reserved-name' lock

TierYou'll noticehow much it should matter to you
Useful2my rating, 1 to 5
Signal1worth watching, 1 to 5
AreaPermissionswhat it touches
KindImprovementsin v2.1.277,
Group of 4 You'll notice

Skills, commands and tools whose name collides with a reserved settings key now get a distinct 'reserved-name' lock

What

  • Skills whose name fails a new reserved-name check are locked to on/user-invocable-only, ignoring any user override.
  • The permissions UI now shows a distinct "reserved-name" state when a skill's or command's configured name can't be stored in settings because it collides with a reserved key, with guidance to rename the skill's folder or the command file.
  • Tools or commands named exactly __proto__ are always treated as reserved-name and forced to stay callable (on or user-invocable-only), regardless of user or policy settings for slash-command visibility.
  • The permission-mode cycling control now treats "reserved-name" the same as "policy" or "flag" sources: it leaves the mode unchanged instead of letting it be cycled.

Why

Names like __proto__ can collide with reserved keys used internally by settings storage, which previously could cause confusing or unsafe override behavior. The new reserved-name category makes this collision visible in the UI and stops such names from being silently disabled, hidden, or mis-cycled.

See this entry in the whole of v2.1.277 →