[BUG] /goal stalls indefinitely when the model enters plan mode — the Stop hook cannot fire on a plan-approval prompt

Preflight

• Searched existing issues. The "/goal silently stalls" family exists (#82546, #83266, #75476) but none of them covers the plan-mode interaction described here.
• Single bug report.
• Version: 2.1.220 (latest at time of writing: 2.1.226). The mechanism below looks structural rather than a recent regression.

What's Wrong?

/goal installs a session-scoped Stop hook. A Stop hook can only block stopping. It cannot do anything about a turn that ends in an approval prompt — and ExitPlanMode is exactly that.

So if the model decides to enter plan mode while a goal is active, the goal is dead in the water:

1. Goal set. Permission mode was bypassPermissions.
2. 71 seconds later the model called EnterPlanMode on its own. Nothing asked it to. The tool description strongly recommends plan mode for any non-trivial implementation task, and a /goal condition is non-trivial by nature. bypassPermissions does not prevent this.
3. It did read-only research for 15 minutes, then called ExitPlanMode.
4. The session then sat idle for 8 h 47 min waiting for a human to approve the plan. The indicator still read /goal active the entire time.
5. On approval it resumed and did the work correctly.

Timeline from the session JSONL:

18:57:35Z  goal set              mode: bypassPermissions
18:58:46Z  EnterPlanMode      -> mode: plan
19:13:58Z  ExitPlanMode       -> waiting for human approval
    ...    8h47m of nothing, indicator shows "/goal active"
04:01:07Z  user approves      -> mode: bypassPermissions, work finally begins

The goal prompt does include "do not pause to ask the user what to do", but that is a soft instruction, and the model can reasonably read ExitPlanMode as "I'm not asking what to do, I'm just showing you the plan first". It loses against the tool description.

There is no user-side workaround on the approval side: per #74256, a PermissionRequest hook returning allow for ExitPlanMode has been ignored since v2.1.199. The only thing that works today is a PreToolUse hook that denies EnterPlanMode outright — which also kills plan mode for normal interactive use, since hooks are not goal-scoped.

What Should Happen?

While a /goal is active, one of:

1. EnterPlanMode is unavailable — cleanest, since a goal is an explicit "go do it" directive; or
2. ExitPlanMode auto-approves; or
3. the goal evaluator also runs when a turn ends in a pending approval, so it can surface "goal blocked on approval" instead of reporting active.

At absolute minimum, the indicator should not read /goal active when the session is blocked on a human and cannot advance.

This is the same shape as #82546 / #83266 / #75476: the goal reports active while nothing can move it forward.

Steps to Reproduce

1. Start a session and Shift+Tab to bypassPermissions.
2. /goal <any non-trivial multi-file implementation task>
3. Walk away.
4. The model will likely call EnterPlanMode, research read-only for a while, call ExitPlanMode, and stop there indefinitely.

Environment

• Claude Code 2.1.220
• Anthropic API
• macOS (Darwin 25.2.0)
• No defaultMode in settings; the session was in bypassPermissions when the goal was set.