{"version":"2.1.274","anchor":"builtin-plugin-availability-now-also-respects-prior-load-fai","canonical_anchor":"builtin-plugin-availability-now-also-respects-prior-load-fai","heading":"Builtin plugin loading now tracks failures and blocks retrying a failed plugin","tier":"internal","area":"Plugins","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/builtin-plugin-availability-now-also-respects-prior-load-fai","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### Builtin plugin loading now tracks failures and blocks retrying a failed plugin\n\nClaude Code now records why a bundled plugin failed to load and stops treating that plugin as available afterward\n\n**What**\n\nLoading a bundled (builtin) plugin now goes through new helper logic that requires the plugin, checks its shape, and registers it, recording a structured failure entry (keyed by plugin name and the phase it failed at: require, shape, register, or is_available) when something goes wrong, along with a telemetry event.\n\nThe check for whether a builtin plugin is enabled now also looks at this failure record: a plugin is treated as unavailable if it previously failed to load, in addition to the existing `isAvailable()` check.\n\n**Why**\n\nThis prevents Claude Code from repeatedly trying to use a builtin plugin that already failed to load, and gives clearer, phase-specific information about why a given plugin isn't working.\n\n- Area: Plugins\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}