Summary
Bug: a session-scoped /goal Stop hook can re-fire indefinitely with unchanged or stale text,
even after the assistant provides verifiable evidence the condition is met, or after the session
enters a deliberate hold. Only the built-in repeated-block safety valve ends the loop, and the
pattern resumes on a later turn.
Expected behavior
The /goal evaluator should recognize live transcript evidence that its condition is met, or
provide a supported way for a session to acknowledge an intentional hold (for example, an
in-flight compaction) without triggering an unbounded re-fire loop.
Actual behavior
Observed independently in four sessions across two trigger conditions:
- A session entered a deliberate hold while waiting on a scheduled context compaction. A live
/goal condition re-fired at least nine consecutive times with the same holding text, until
the repeated-block safety valve intervened.
- During ordinary autonomous work with no hold in effect, a
/goal condition re-fired at least
21 consecutive times quoting a stale multi-part goal. Two separate in-transcript corrections
citing concrete evidence that the named work had already completed did not change the
re-fired text.
Minimal reproduction
- Set a
/goal with a multi-part condition in a long-running autonomous session.
- Complete or supersede part of that condition while continuing other work, or begin a
deliberate hold (for example, waiting on a scheduled compaction).
- Observe the Stop hook re-fire with unchanged framing, unaffected by the completed work, an
explicit correction, or the deliberate hold.
- Continue until "A hook blocked the turn from ending 9 consecutive times" appears. Observe the
pattern resume on a later turn.
Environment
- Product and version: Claude Code CLI, at least 2.1.258, pattern recurring through later
2.1.26x builds.
- OS and version: Linux (Fedora 44), also observed on other Linux hosts.
- Model / resolved model ID: not applicable; independent of the active model.
- Runtime context: tmux-hosted CLI session, both fresh and resumed-after-compaction.
- Authentication/provider path: subscription and API key paths both observed.
Diagnostics
No crash and no error text are produced; the only signal is the repeated identical Stop hook
re-fire and, eventually, the built-in "hook blocked the turn from ending 9 consecutive times"
override message.
Regression and controls
- Fresh process/session: reproduces in both a fresh session and one resumed after compaction.
- Last known good version: unknown; the pattern has been present across every build checked.
- Relevant control: every locally-registered Stop hook was independently tested against a
realistic Stop payload and each exited cleanly with no output, ruling out a local hook as the
cause.
Hypothesis
The prompt-type Stop hook evaluator does not appear to re-read live transcript state when
judging whether its condition is met, and there is no supported mechanism for a session to
signal an intentional hold without continuing to be re-invoked.
Related public reports
None of the above describes the specific pattern in this report: unchanged re-fire that persists
across an explicit in-transcript evidentiary correction, and across a deliberate hold state such
as waiting on a scheduled compaction.
Summary
Bug: a session-scoped
/goalStop hook can re-fire indefinitely with unchanged or stale text,even after the assistant provides verifiable evidence the condition is met, or after the session
enters a deliberate hold. Only the built-in repeated-block safety valve ends the loop, and the
pattern resumes on a later turn.
Expected behavior
The
/goalevaluator should recognize live transcript evidence that its condition is met, orprovide a supported way for a session to acknowledge an intentional hold (for example, an
in-flight compaction) without triggering an unbounded re-fire loop.
Actual behavior
Observed independently in four sessions across two trigger conditions:
/goalcondition re-fired at least nine consecutive times with the same holding text, untilthe repeated-block safety valve intervened.
/goalcondition re-fired at least21 consecutive times quoting a stale multi-part goal. Two separate in-transcript corrections
citing concrete evidence that the named work had already completed did not change the
re-fired text.
Minimal reproduction
/goalwith a multi-part condition in a long-running autonomous session.deliberate hold (for example, waiting on a scheduled compaction).
explicit correction, or the deliberate hold.
pattern resume on a later turn.
Environment
2.1.26x builds.
Diagnostics
No crash and no error text are produced; the only signal is the repeated identical Stop hook
re-fire and, eventually, the built-in "hook blocked the turn from ending 9 consecutive times"
override message.
Regression and controls
realistic Stop payload and each exited cleanly with no output, ruling out a local hook as the
cause.
Hypothesis
The prompt-type Stop hook evaluator does not appear to re-read live transcript state when
judging whether its condition is met, and there is no supported mechanism for a session to
signal an intentional hold without continuing to be re-invoked.
Related public reports
/goalset at a compact boundary never starts its turn; a related but distinctinteraction between
/goaland compaction./goalStop hook skipped while a background task is live and never re-evaluatedafter it ends.
stop_hook_active: true.explicit stand-down.
/goalStop hook repeatedly re-fires after the user accepts a blocked outcome./goalStop condition evaluator cannot see the instruction passed via/goal, loopsuntil it declares itself unachievable.
None of the above describes the specific pattern in this report: unchanged re-fire that persists
across an explicit in-transcript evidentiary correction, and across a deliberate hold state such
as waiting on a scheduled compaction.