{"version":"2.1.283","anchor":"hooks-modules-whether-a-hook-may-run-a-command-is-now-decid","canonical_anchor":"hooks-modules-whether-a-hook-may-run-a-command-is-now-decid","heading":"Loading hook modules now hold back only the commands they cover","tier":"internal","area":"Mods","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/hooks-modules-whether-a-hook-may-run-a-command-is-now-decid","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Loading hook modules now hold back only the commands they cover\n\nWhile hook modules are still loading, Claude Code now checks each command against those modules instead of applying one blanket check\n\n**Unclear.** What Claude Code does with the result of this per-command check is not stated.\n\n**What**\n\nHooks are actions that run automatically at set points while Claude Code works, and hook modules are what supply them. While some of those modules are still loading, Claude Code now decides for each command whether a hook may run it, by checking the command against each module still loading. A module that declares nothing about which commands it covers is treated as covering every command.\n\nBefore, there was one check covering all commands at once while modules were loading.\n\n**Why**\n\nA slow-loading hook module may now hold back only the commands it actually covers, instead of every command.\n\n- Area: Mods\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}