{"version":"2.1.288","anchor":"hook-matching-failures-now-logged-and-reported-instead-of-si","canonical_anchor":"hook-matching-failures-now-logged-and-reported-instead-of-si","heading":"Hook matching errors are now logged instead of silently ignored","tier":"notice","area":"Hooks","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288\/e\/hook-matching-failures-now-logged-and-reported-instead-of-si","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288","markdown":"### Hook matching errors are now logged instead of silently ignored\n\nWhen Claude Code can't work out which hooks match an event, it now logs the failure instead of quietly running no hooks\n\n**Unclear.** It is not clear what the stand-in path for plugin hooks is for.\n\n**What**\n\nHooks are your own commands that Claude Code runs at set moments, such as before a tool is used. Before this change, if Claude Code hit an error while working out which hooks match an event, it ran no hooks and said nothing. Now it:\n\n- logs \"Failed to resolve matching hooks for\" followed by the event\n\n- records the failure in usage data, unless usage data is turned off\n\n- passes the error on, if the hook rules had already been read\n\nHooks that belong to a plugin can also now have their `if` conditions checked against a stand-in for the tool's input.\n\n**Why**\n\nA broken hook rule used to switch hooks off without any sign. Now there is a log line you can find.\n\n- Area: Hooks\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}