[FEATURE]: Allow the built-in /goal Stop hook under allowManagedHooksOnly (or add a managed opt-in)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 29, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

/goal is implemented as a runtime-registered Stop hook. In deployments governed by managed settings with allowManagedHooksOnly: true, /goal is refused outright:
/goal can't run while hooks are restricted (disableAllHooks or allowManagedHooksOnly is set in settings or by policy).
(Observed on v2.1.246, Linux, file-based managed-settings.json.)
allowManagedHooksOnly exists so that only admin-owned hook configurations execute — its purpose is preventing arbitrary, unmanaged hook scripts. The goal evaluator does not fit that threat shape: it is engine-internal, and per the documentation the goal condition is judged by a small model (a prompt-based check) — no user-supplied command executes. Blocking it removes a core engine feature from every governed environment while adding no governance value: there is currently no way to have both hook governance and /goal.
Related: #74925 requests the same kind of exemption for the built-in statusLine — both stem from one built-in-vs-arbitrary-hook conflation under these gates.

Proposed Solution

Preferred: treat the engine's own goal Stop hook as built-in and exempt it from allowManagedHooksOnly (it is not a user/project/plugin hook, which is what the setting is documented to restrict).
Alternative, fully backward compatible: a managed-settings opt-in (e.g. allowBuiltinGoalHook: true) so admins explicitly re-enable /goal while keeping the general restriction; unset preserves today's behavior.
Either way, when /goal is blocked by policy, surface that in /doctor — today the refusal message is the only signal.

Alternative Solutions

Dropping allowManagedHooksOnly org-wide (defeats the setting's purpose), or recreating goal-style continuation with external orchestration (loses the native UX and the engine's own check-in machinery).

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

An automation-heavy environment locks hook governance org-wide (allowManagedHooksOnly: true) because sessions run with elevated autonomy. Those same sessions are where "keep going until the suite is green" is most valuable — and /goal is the one feature the governance setting takes away.

Additional Context

_No response_

View original on GitHub ↗