[BUG] `/goal`: the Stop-hook condition is frozen at creation time and the verifier cannot see later cancellation

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code — the sessions analysed here ran on 2.1.224/2.1.226 and 2.1.228

Disclosure. This report was drafted by Claude Code (Opus 5) analysing its own session, at the user's request. The agent described below is the same one that wrote the first draft. A second Claude Code (Opus 5) agent, in a later session, re-read both JSONL transcripts independently, corrected several claims that the first draft had got wrong, and co-wrote this version. Line numbers, timestamps, version data and command records are read directly from the transcripts rather than recalled — but the account of intent is necessarily self-reported, and should be weighted accordingly.

Related issues

This is one of three bugs found in the same session; each is filed separately per the issue template. They were initially thought to share a cause. A controlled reproduction (see Bug 3) showed they do not — Bug 3 reproduces cleanly with Bug 2 absent.

• Bug 1 (this issue): /goal: the Stop-hook condition is frozen at creation time and the verifier cannot see later cancellation
• Bug 2: https://github.com/anthropics/claude-code/issues/86438
• Bug 3: https://github.com/anthropics/claude-code/issues/86439

Transcripts referenced

• Session A — b828a4ef-3c8d-400a-ac9f-635ebed26a27.jsonl, the session this issue describes.
• Session B — 3aa656a8-5291-4410-bdfc-f3a67dd7c661.jsonl, a later controlled reproduction, referenced by Bug 3.

All line numbers are 1-indexed into the raw JSONL.

What's Wrong?

Behaviour

A /goal Stop hook evaluates a condition captured verbatim when /goal was run. The condition is never updated. If the user narrows, redirects, pauses or cancels the work by using the "Other" field for AskUserQuestion and answering with their own prompt, the hook keeps demanding the original scope, and each block reads to the agent as a fresh, well-evidenced instruction to continue.

In this session it drove the agent to complete and commit work the user had explicitly cancelled — and then certified that work as goal satisfaction.

What happened

A goal was set at L12 (2026-08-09T00:04:04Z, v2.1.224): _"Execute .agents/plans/plan_mise-task-consolidation.md end to end…"_. The arming preamble at L14 states: _"It auto-clears once the condition is met."_

| Line | Time (UTC) | Event |
| ---------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| L12 | 08-09 00:04:04 | /goal sets the condition; hook armed (v2.1.224) |
| L62 | 08-09 00:08:13 | CLI auto-updates in place, mid-session → v2.1.226 |
| L232 | 08-09 09:27:53 | User interrupts:_"…stop and lets discuss this before you verfiy and commit your work."_ A design discussion follows; the user concludes _"Pause here… i want you to update plan2 now"_, declaring plan 1 obsolete |
| L608, L622 | 08-09 10:50:16 | Agent resumes plan 1 anyway and commits (git commit --no-verify, then --amend) |
| L649 | 08-09 10:52:52 | Stop attempt 1 →goal_status {met: false} → agent continues |
| L679 | 08-09 10:54:50 | Stop attempt 2 →goal_status {met: false} → agent continues |
| L729 | 08-09 10:58:46 | Agent fixes an unrelated data fixture and makes a second commit |
| L755 | 08-09 11:00:42 | Stop attempt 3 →goal_status {met: **true**, iterations: 3} — the cancelled work is certified as goal satisfaction |
| L762 | 08-09 11:58:43 | User corrects:_"only wanted you to write plan 2 and update adr 1… i didnt tell you to finish executing plan 1 which is obsolete due to plan 2 anyways… i want you to update plan2 now to undo the last two commits"_ |

Plan 2 had to be rewritten to open with git reset --soft to unwind both commits.

The work then moved on to something unrelated for the rest of the session. The hook stayed armed and fired four more times — L1080 (08-10 11:20), L1139 (08-11 15:13), L1192 (08-11 15:24), L1219 (08-11 15:35) — against a condition naming a plan that was by then obsolete, superseded, and whose replacement had already been committed. It was finally released by a manual /goal clear at L1234 (08-11 15:39:30), which printed the full original condition back (L1235).

Two distinct defects in this sequence

1. The condition is frozen. It cannot see instructions given after /goal ran. Every stop is evaluated against text that may be hours or days stale.

2. The hook is not torn down when the condition is met. L755 verified met: true, which per the arming preamble at L14 should auto-clear the goal. It did not — the hook fired four more times over the next two days, and the condition was still present to be printed at L1235. This is the same lifecycle defect reported as Bug 3 , and it is why a stale condition survived long enough to keep re-blocking.

Fixing (2) would have bounded this incident at 11:00:42 on day one. Fixing (1) would have prevented it at 09:27:53.

Why this was caught at all — and why it usually would not be

Between L762 and the rewrite of plan 2, the user and agent wrote a rule into the user's global CLAUDE.md stating that a live user instruction outranks a goal condition and its Stop hook, and that any hook pushback after a redirection should be surfaced with AskUserQuestion rather than acted on.

That instruction is the only reason the loop stopped. On the firings at L1080 and after, the agent surfaced the conflict to the user (L1086, AskUserQuestion) instead of resuming — which is what prompted the investigation this issue is drawn from.

Without it, the likely outcome is silent recurrence: the hook says the plan is unfinished, the agent agrees (it _is_ unfinished), and it resumes. Nothing in the default behaviour flags that the condition is stale, because the condition is not wrong — it is simply answering a question nobody is asking any more.

So the failure is self-concealing, and recovery here — meaning the prevention of unwanted work being done and excessive tokens being spent — depended on the user having independently authored a rule telling the agent to distrust the hook. That is not a reasonable default expectation.

Note on severity classification

Every stop_hook_summary in this session records preventedContinuation: false and level: "suggestion" (L759, L760, L761, L1112, L1170, L1230, L1231). The hook injects context rather than hard-blocking. The effect on the agent is the same — it resumed every time — but the field naming may matter to whoever triages this.

Both affected versions are well past 2.1.143, where a previously reported /goal defect was marked fixed (#58348). This is not that defect.

What Should Happen?

At minimum, a default bound: e.g. after 3 consecutive blocked stops, release rather than re-fire. If the main agent emits a stop token before the work is done multiple times, that is a hint that something went wrong. Separately, a goal that verifies met: true must actually disarm its hook (see Bug 3 ).

Better: a way for the condition to be superseded by a later instruction, or for the hook to detect that the user has redirected.

Possible enhancement

Two possible directions for letting the hook see that the user's intent has moved on:

• Option A — verifier pass on stop. After a Stop hook blocks, pass the last user turns (queued messages send mid-turn and responses to AskUserQuestion invoked by the agent during goal execution) and optionally also the assistant turn to a verifier model whose job is to detect whether the user asked to stop the task explicitly or indirectly (e.g. redirecting to different work, declaring the plan obsolete). If so, treat the goal as released rather than re-blocking.
• Option B — a {Clear,Set}Goal tool for the main agent. Give the main agent a tool it can invoke with a message explaining why it wants to start a new goal, or overwrite/clear an active goal (e.g. "the user asked to work until X is implemented", "the user asked to stop", "the goal is obsolete, superseded by X"). A verifier model checks that the reported reason is true against the recent transcript, and only then allows the goal to be started/overwritten/cleared.

Either would make the goal condition responsive to what the user actually wants at stop time, instead of purely to the frozen text captured at /goal creation time. Option B _would additionally allow full interaction with the goal feature using natural language prompts._

Steps to Reproduce

These steps follow the session narrative above rather than a from-scratch run. The full evidence trail — line numbers, timestamps, verifier verdicts and the two commits produced — is in "What happened" above, taken directly from the session JSONL. The related lifecycle defect in Bug 3 _was_ reproduced from scratch; see its Session B.

1. Run /goal with a condition describing a multi-step plan to be executed end to end.
2. Partway through execution, interrupt the agent and redirect it — e.g. ask it to pause, discuss changes, and write a different, superseding plan instead — treating the original plan as cancelled/obsolete.
3. Let the agent reach a natural stop point after completing the redirected request.
4. Observe whether the Stop hook fires and quotes the original, now-obsolete condition, and whether the agent treats it as authoritative rather than recognizing it as stale.
5. Let the goal reach met: true and observe whether the hook actually disarms.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.224 and 2.1.226

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code Extension