Summary

Claude Code 2.1.143 appears to apply a generic consecutive Stop/SubagentStop hook blocking cap to /goal: /goal is implemented as a session-scoped Stop prompt hook, and the main loop defaults CLAUDE_CODE_STOP_HOOK_BLOCK_CAP to 8 consecutive hook blocks before overriding and ending the turn.

Qwen Code's /goal implementation currently uses a much larger goal-specific iteration budget (MAX_GOAL_ITERATIONS = 50) plus the broader main-loop turn budget. It may be worth adding a smaller configurable Stop-hook blocking cap (or aligning /goal with such a cap) to prevent runaway goal loops and improve user recovery.

Motivation

A /goal condition that is not yet satisfied causes the Stop hook to block the assistant from ending and continue the session. Without a low consecutive-blocking cap, an impossible/poorly specified goal can keep the agent looping for many turns before it aborts.

Claude Code seems to guard this at the Stop-hook system layer rather than only in /goal itself:

• /goal registers a session-scoped prompt hook on the Stop event and stores activeGoal state.
• When the Stop hook returns a blocking result repeatedly, the main loop increments stopHookBlockingCount.
• Default cap is 8 unless CLAUDE_CODE_STOP_HOOK_BLOCK_CAP is set.
• When the cap is exceeded, it emits a warning like: A hook blocked the turn from ending ... consecutive times — overriding and ending turn.

This design has two useful properties:

1. It protects every Stop/SubagentStop hook, not just /goal.
2. It gives advanced users/policies an escape hatch via configuration/env var.

Proposed direction

Consider adding a configurable consecutive Stop-hook blocking cap in Qwen Code, for example:

• Add a generic Stop/SubagentStop hook blocking counter in the main continuation path.
• Default to a conservative cap (Claude's observed default is 8) or choose a Qwen-specific default.
• Allow configuration via settings/env, e.g. QWEN_CODE_STOP_HOOK_BLOCK_CAP or a settings key.
• When exceeded, clear or bypass the active goal/hook continuation and surface a concise warning in the UI/history.
• Keep the existing broader /goal max-iteration guard as a secondary safety net.

Expected behavior

For an unsatisfied /goal:

1. /goal continues while the Stop hook judge returns not met.
2. Consecutive Stop-hook blocks increment a counter.
3. After the configured cap, Qwen Code stops auto-continuing and reports that the Stop hook blocked too many consecutive times.
4. Users can adjust the cap if they intentionally want longer autonomous goal loops.

Related context

This is related to the previous /goal implementation discussion in #4074, but focuses specifically on a Stop-hook-level runaway-loop safety cap rather than the base /goal feature itself.