Stop hook re-fires despite stop_hook_active: true, causing /goal loop to spin after completion #78121

CC version

2.1.211

Summary

The /goal loop's internal Stop-hook handling does not appear to honor stop_hook_active: true in the hook payload. When a goal's stop condition cannot be internally satisfied (see repro below), the Stop hook re-fires repeatedly instead of allowing the session to end once stop_hook_active is set, even though the underlying build work was already complete and correct.

Repro

1. Kick off a /goal build whose "Done means" stop condition includes a step that cannot be satisfied inside the loop (e.g., waiting on an external human/gate action rather than a verifiable local condition — a bad practice on our end, see Mitigation below, but one the hook should still tolerate gracefully).
2. Let the loop reach a state where its own work is finished and it re-invokes the Stop hook to check whether it can end.
3. Observe the Stop hook payload includes stop_hook_active: true on the re-entrant call, but the session does not exit — it keeps re-prompting/continuing instead of stopping.

Observed

On 2026-07-16, during a real build session (PR #95), this fired approximately 9 times in a row. The build's actual work was already correct and complete (confirmed post-hoc) — the loop simply couldn't stop. This burned roughly 20 minutes and 35K tokens of pure post-completion spin with no new work being done.

Expected

When the Stop hook payload carries stop_hook_active: true, the session should be allowed to exit cleanly (no further block/continue re-prompt) rather than re-entering the loop.

Our mitigation (so this report is actionable, not just a complaint)

We've updated our internal goal-prompt protocol so that a goal's stop condition ("Done means") never includes a human/external gate — those must happen outside the loop, after reaching PR-ready-with-proof. This avoids triggering the runaway condition in normal use for us going forward. However, the underlying Stop-hook behavior (not honoring stop_hook_active) seems like a real defect independent of prompt design, since a hook payload flag that's provided specifically to prevent recursive re-entry should be honored regardless of what caused the loop to reconsider stopping.

Ask

Please confirm whether stop_hook_active is intended to suppress further Stop-hook-driven continuation, and if so, fix the /goal loop's internal handling to exit (no block/continue output) when it's true.