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.
Names in the bundle__proto__
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed since
Anthropic's documentation has since written up __proto__, on Claude Code changelog.
* Fixed organization per-tool permission ceilings being silently dropped for an MCP tool named `__proto__`changelog see the edit
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up __proto__, on Claude Code changelog.