{"version":"2.1.265","anchor":"new-diagnostics-for-unreadable-plugin-component-folders","canonical_anchor":"new-diagnostics-for-unreadable-plugin-component-folders","heading":"Better diagnostics for plugin file-access failures","tier":"notice","area":"Plugins","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/new-diagnostics-for-unreadable-plugin-component-folders","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Better diagnostics for plugin file-access failures\n\nPlugin loading now surfaces underlying filesystem errors instead of silently treating failures as missing files\n\n**What**\n\n- Plugin loading now produces clearer diagnostics when something goes wrong reading a plugin's component folders: checking each default folder (commands\/agents\/skills\/output-styles\/themes\/workflows) now logs an error and records a diagnostic entry when the failure is something other than \"not found\", instead of silently treating the folder as absent.\n\n- When a plugin or marketplace manifest path can't be found and there's an associated system error number (errno), the error message now includes that errno and suggests likely causes, such as a self-referential symlink, a broken network mount, or a permissions problem, and tells the user to run `\/reload-plugins`.\n\n**Why**\n\nThese changes make it much easier to diagnose why a plugin failed to load, by surfacing the actual underlying filesystem error instead of just treating any failure as a missing file.\n\n- Area: Plugins\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}