{"version":"2.1.280","anchor":"new-hooks-modules-gate-condition-via-bj","canonical_anchor":"new-hooks-modules-gate-condition-via-bj","heading":"New hooks-modules gate condition via BJ()","tier":"internal","area":"Hooks","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/new-hooks-modules-gate-condition-via-bj","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### New hooks-modules gate condition via BJ()\n\nA new internal check can force 'managed hooks only' mode even without the matching policy setting\n\n**Unclear.** What condition BJ() actually represents and what practical effect it has beyond the existing allowManagedHooksOnly policy is not stated.\n\n**What**\n\nClaude Code's check for whether to restrict hooks (small scripts that run automatically at certain points) to only the ones an organization manages now also returns true based on a new internal condition, `BJ()`, in addition to the existing `allowManagedHooksOnly` policy setting. `BJ()` looks at whether any hooks currently exist.\n\n**Why**\n\nThis adds another path that can trigger managed-hooks-only mode beyond the explicit organization policy setting, though the finding does not say what user-facing behavior results.\n\n- Area: Hooks\n- Names: `allowManagedHooksOnly`\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}