[Bug] /goal stop check rejects a user-ordered handoff repeatedly (about 30 times in a row), with no bound and no way to pause

What happened

A /goal was set whose text named only an end state, of the form "build <project> as written in <goal file>". The work is long (days), so the session had natural pauses.

The user then told the session to hand over to a fresh session and not start anything new (a handoff the user ordered, with a written resume file). The session tried to stop. The goal's stop check rejected the stop, because the end state was not reached. The session answered, tried to stop again, was rejected again: about 30 times in a row, each time spending a full turn, until the user typed /goal clear.

Why this happens (as far as we can see from outside)

• The stop check judges only the goal text against the transcript. It cannot see that the pause was ordered by the user, or that the session is waiting on a decision only the user can make.
• With an end-state-only goal, every pause before the end is "not done", so the check can never pass during a legitimate wait.
• Nothing bounds the loop: there is no "after N rejections, ask the user".

Impact

• About 30 wasted turns (tokens and wall time) with no work done.
• The user has to notice and type /goal clear, which also drops the goal they wanted to keep for the next session.
• The same shape will hit anyone who sets a long, end-state goal and then needs to pause: waiting for an approval, a usage reset, a CI run, or a handoff.

Reproduce

1. /goal finish <something that takes many sessions> (end state only, no stopping points).
2. Work a few turns.
3. Tell the model: "hand over now; write the resume file; start nothing new".
4. Watch the stop check reject the stop on every turn.

Asks

1. Treat a user message that orders a pause or a handoff as a valid stop for the stop check (or let the model cite the user's message as the reason, and accept it).
2. After N consecutive rejections (3 is plenty), ask the user instead of looping.
3. Allow a goal to declare valid pauses, and document it, for example: "valid stops: waiting on the user's decision, a usage stop, a committed handoff".
4. Optionally a /goal pause that keeps the goal for the next session without clearing it.

Workaround we use

Goal text that names the finish line as checkable boxes and its valid stopping points (waiting on the user, a usage stop, a committed handoff). Since then the loop has not recurred, but the goal text now carries harness knowledge that a user should not need.

Environment and evidence

• Windows 11, Claude Code CLI. The incident was on 5 Oct 2026; the exact version that day was not recorded (2.1.290 at the time of filing). Count of ~30 is from the session transcript.
• One incident; the shape is deterministic given an end-state-only goal and a user-ordered pause.
• Related: #97797 (state across compaction) for why handoffs to a fresh session are common in long projects.