{"version":"2.1.265","anchor":"worktreecreate-hook-path-now-conditionally-used-via-cwt-in","canonical_anchor":"worktreecreate-hook-failure-no-longer-throws-when-no-hook-is","heading":"WorktreeCreate\/WorktreeRemove hook gating and fallback behavior refined","tier":"notice","area":"Worktrees","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/worktreecreate-hook-path-now-conditionally-used-via-cwt-in","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### WorktreeCreate\/WorktreeRemove hook gating and fallback behavior refined\n\nWorktree create\/remove hook handling was refined: fewer spurious errors and clearer checks for whether a hook applies\n\n**What**\n\n- In the worktree-create flow, if no hook commands ran at all, the code used to always throw a \"hook is configured but did not run\" error. Now it first checks whether any `WorktreeCreate` hook is actually configured, and silently continues if none is, only throwing when a hook is genuinely configured but failed to run.\n\n- The decision of whether to use a `WorktreeCreate` hook (instead of falling back to the built-in git worktree flow) now goes through a renamed gate that checks either an existing predicate or the presence of a registered `WorktreeCreate` hook.\n\n- The existing `WorktreeCreate`\/`WorktreeRemove` hook events are now also checked through a broader capability lookup (not just whether hooks are registered for them), used to decide whether the worktree create\/remove UI is shown at all.\n\n**Why** These changes reduce spurious \"hook is configured but did not run\" errors when no worktree hook is set up, and make the logic for whether worktree create\/remove hooks and UI are active more consistent.\n\n- Area: Worktrees\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}