/loop exit doesn't terminate loop — Stop hook condition persists across exit invocation

Summary

Two overlapping issues prevent users from cleanly stopping a /loop or /goal directive once it's been set:

1. /goal (or the goal embedded in a /loop prompt) is locked to its original phrasing. When the user changes their mind mid-flight and cancels some of the work, the assistant correctly marks those tasks status=deleted. But the Stop hook keeps evaluating against the original goal wording and treats deleted ≠ completed literally, so the condition can never be satisfied.
2. /loop exit doesn't terminate the loop. The Stop hook condition installed by the original /loop <prompt> invocation persists across /loop exit. There is no documented escape hatch.

Reproduction

1. Start /loop <multi-task goal> (or set a /goal with multiple sub-tasks) — Stop hook is installed evaluating against that goal
2. Mid-session, redirect work so one or more sub-tasks are explicitly cancelled by the user (legitimate reason — e.g. discovered cost, deprioritised, blocker can't be resolved). Assistant marks them status=deleted rather than falsely flipping to completed
3. Try to end the loop with /loop exit
4. Expected: Stop hook condition clears, no further hook firings
5. Actual: Stop hook continues firing the same [<original goal>]: … condition on every turn, citing the deleted tasks as proof the condition isn't met. Loop is unrecoverable without closing the session

Impact

• No way to amend a goal once set — if user redirects mid-flight, the hook stays anchored to the original phrasing forever
• No working escape hatch — /loop exit is documented as the way out but doesn't unregister the Stop hook
• Hundreds of identical Stop hook firings per session burn tokens against an impossible condition (deleted ≠ completed, work explicitly cancelled by user)
• Assistant is reduced to replying with literal . messages for dozens of hook firings before user can force-quit
• The failure mode is symmetric: any user who runs /loop or /goal and then changes their mind hits this

Suggested fixes (pick one or combine)

1. /loop exit should explicitly unregister the Stop hook condition it installed. Currently the exit subcommand is a no-op for the hook side of the loop.
2. /goal should support mid-flight amendment. When the user redirects, allow the assistant (or user) to update the goal text so the hook re-evaluates against the new scope.
3. Stop hook should treat status=deleted as terminal (equivalent to completed) when evaluating "all tasks finished" — deletion-by-user-redirect is a legitimate stop signal, not an unmet condition.
4. Surface a clearer force-exit — e.g. /loop force-exit or a setting that drops any active Stop hook conditions.

Environment

• Claude Code (Opus 4.7, fullscreen TUI)
• Skill: /loop (dynamic mode, rule 3 — no fixed interval) and/or /goal
• Stop hook configured by the skill at invocation time

🤖 Generated with Claude Code