[BUG] Excessive tendency to stop workflow when unnecessary even when directed in CLAUDE.md not to.

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

What's Wrong?

Title: Opus 4.7 heightened tendency to stop and ask for permission at phase boundaries; no built-in override; costing 3-6
hours per day

Claude Code version: 2.1.113
OS: Windows 11 Home (Build 26200), x64
Model: claude-opus-4-7 (1M context)
Project type: long-running sprint-based development (35+ sprints documented in repo)

SUMMARY

When using Opus 4.7 on a long-running project with established durable approvals (user approves a multi-task sprint plan,
then Claude executes through Phases 4-7 autonomously per project docs), 4.7 repeatedly ends turns with procedural
permission-asking questions even when the next action is unambiguously defined by approved plan documents. In our project
this costs 3 to 6 hours of wall-clock time per day, primarily in the form of unnecessary user round-trips at phase boundaries
(after tests pass, after builds complete, after commits are created, after documentation updates, etc.).

This is a regression from Opus 4.6 behavior on the same project with the same guidance documents. 4.6 held a durable mental
model of "sprint plan approved = Phases 4-7 authorized" and only stopped for the enumerated SPRINT_STOPPING_CRITERIA in our
project docs. 4.7 treats the same guidance as advisory rather than binding.

CONCRETE EXAMPLES from Sprint 35 and Sprint 36 kickoff (this week):

1. After tests passed at Phase 5.2 with 1363/0 results, 4.7 asked "Want me to proceed to Phase 5.3 (build app)?" instead of

executing Phase 5.3.

1. After a successful commit and push, 4.7 asked "Want me to push to PR #238?" even though git push had already completed

successfully and the Standing Approval Inventory in the project's SPRINT_EXECUTION_WORKFLOW.md explicitly authorizes pushing
to the sprint feature branch.

1. After completing all documentation updates for a retrospective with an explicit "apply all 5 improvements" directive from

the user, 4.7 paused before each of the 5 improvements to confirm.

1. At a Phase 2 -> Phase 3 transition with an unambiguous next action (produce SPRINT_N_PLAN.md), 4.7 wrote a full

multi-option question "Which path - run the dependency check, or go straight to Phase 3 planning?" - this was particularly
notable because 4.7 had JUST finished writing a 5-proposal retrospective improvement plan including the exact rule it was now
violating.

WHAT WE TRIED (ALL INSUFFICIENT)

To fix this in documentation alone, during a Sprint 35 retrospective we applied five process improvements to our project
docs:

• P1: A "Phase Auto-Advance Rule" codified in CLAUDE.md ("Sprint plan approval at Phase 3 is durable authorization through

Phase 7... DO NOT ask 'want me to proceed to Phase N+1?'")

• P2: A "Standing Approval Inventory" in SPRINT_EXECUTION_WORKFLOW.md enumerating 10+ categories of action that do not

require a per-occurrence permission prompt (commits, pushes, PR updates, builds, etc.)

• P3: Planned 1-page Phase Cheat Sheet (deferred)
• P4: A "Model-Version Pitfalls" living appendix in CLAUDE.md with 6 specific Opus 4.7 entries
• P5: A "Sprint Resume Pattern" memory entry
• Plus a 6th addition: Phase 6.4.5 mandatory "gh pr ready" step after Sprint 35's PR sat in draft through close-out

None of these prevented the violations. 4.7 continued to ask procedural questions on the very sprint that added the rules. We
had to resort to a Stop-hook (described below) to make the constraint binding.

OUR EVENTUAL WORKAROUND (shouldn't be necessary)

We built a PowerShell Stop-hook at .claude/hooks/sprint-auto-advance.ps1 that:

1. Fires on every Stop event via .claude/settings.json hooks.Stop
2. Reads the last_assistant_message, cwd, and current git branch
3. Blocks the stop (exit 2) if all three gates trip: branch matches feature/\d+_Sprint_\d+, message ends in '?' or contains

procedural-ask phrasing, no legitimate SPRINT_STOPPING_CRITERIA §1-9 signal present

1. When blocked, injects stderr text instructing Claude to identify the next action from the plan doc and execute without

re-asking

1. Emergency bypass by appending _allow_stop_hook_bypass to branch name

A 7-case test harness verifies 3 violation patterns get blocked and 4 legitimate-stop patterns get allowed.

This hook works, but:

• Writing, testing, and documenting it consumed roughly 90 minutes that should have gone to the actual sprint work
• The same effort would be needed by any long-running Claude Code project hit by this regression
• Users without PowerShell or hook-writing fluency have no practical recourse
• There is no official "durable approval" or "autonomous execution" mode exposed by Claude Code that would make this hook

unnecessary

WHAT WOULD RESOLVE THIS

Any ONE of these would eliminate the workaround need:

1. A built-in "durable approval" / "sprint autonomy" setting at the session or project level that tells 4.7 to treat the

current approval as covering all sub-tasks implied by an approved plan, with stops only for explicit exceptions the user
defines.

1. A documented, supported "standing approval" primitive that users can enumerate in settings.json (similar to the

permissions.allow array but for classes of action like "commit", "push", "pr_update") that tunes the model's
permission-asking tendency for those actions.

1. A model-side improvement in 4.7 (or 4.8) to treat explicit durable-approval language in CLAUDE.md (e.g., "sprint plan

approval covers Phases 4-7") as binding rather than advisory.

1. At minimum, documentation acknowledging that 4.7 has this heightened tendency vs. prior models, and that hook-based

enforcement is the current recommended workaround.

REPRODUCTION

Any project that:

• Uses a multi-phase workflow documented in repo docs (common for sprint-based, CI/CD, release-engineering, or any "make a

plan, then execute" pattern)

• Has explicit durable approvals in project docs (e.g., "plan approval covers all downstream tasks")
• Is being executed with Opus 4.7

...will exhibit the behavior. It is especially visible at: test-pass -> build boundaries, commit -> push boundaries,
PR-create -> PR-update boundaries, and any phase -> phase checkpoint.

WALL-CLOCK COST (measured on our project)

• Sprint 34 (14 tasks, completed mid-April): ~2-3 hours of avoidable stops before we noticed the pattern
• Sprint 35 (2 tasks, completed April 19): estimated ~4 hours of avoidable stops; user surfaced the pattern in retro
• Sprint 36 kickoff (April 20): ~1 hour of avoidable stops in the first day alone, including one violation of the very rule

being written into the retrospective to prevent future violations; prompted the Stop-hook build

Projected ongoing cost without the hook: 3-6 hours per day on active sprint work. With hook in place: close to zero (hook
test suite passes all 7 cases; we'll measure actual Sprint 36 execution vs baseline).

WHAT I APPRECIATE

4.7 is otherwise an improvement - reasoning quality, code quality, 1M context, and retrospective analysis are all better than
4.6. This single behavioral regression is the only significant friction I've hit, and I'm reporting it in detail precisely
because the rest of the product is strong enough that closing this gap would make it excellent.

Happy to share the hook script, test cases, and sprint retrospective docs that surfaced this if Anthropic wants more detail.

What Should Happen?

Can you tone down the tendency to stop.
Can you provide a means to tone down the tendency to stop (/<setting>).
At least allow hooks to test for stopping criteria and document them.

Error Messages/Logs

Should I proceed to <step>? when explicitly instructed that it is unnecessary and should not stop.

Steps to Reproduce

CONCRETE EXAMPLES from Sprint 35 and Sprint 36 kickoff (this week):

1. After tests passed at Phase 5.2 with 1363/0 results, 4.7 asked "Want me to proceed to Phase 5.3 (build app)?" instead

of
executing Phase 5.3.

1. After a successful commit and push, 4.7 asked "Want me to push to PR #238?" even though git push had already

completed
successfully and the Standing Approval Inventory in the project's SPRINT_EXECUTION_WORKFLOW.md explicitly authorizes
pushing
to the sprint feature branch.

1. After completing all documentation updates for a retrospective with an explicit "apply all 5 improvements" directive

from
the user, 4.7 paused before each of the 5 improvements to confirm.

1. At a Phase 2 -> Phase 3 transition with an unambiguous next action (produce SPRINT_N_PLAN.md), 4.7 wrote a full

multi-option question "Which path - run the dependency check, or go straight to Phase 3 planning?" - this was
particularly
notable because 4.7 had JUST finished writing a 5-proposal retrospective improvement plan including the exact rule it
was now
violating.
REPRODUCTION

Any project that:

• Uses a multi-phase workflow documented in repo docs (common for sprint-based, CI/CD, release-engineering, or any "make

a
plan, then execute" pattern)

• Has explicit durable approvals in project docs (e.g., "plan approval covers all downstream tasks")
• Is being executed with Opus 4.7

...will exhibit the behavior. It is especially visible at: test-pass -> build boundaries, commit -> push boundaries,
PR-create -> PR-update boundaries, and any phase -> phase checkpoint.

WALL-CLOCK COST (measured on our project)

• Sprint 34 (14 tasks, completed mid-April): ~2-3 hours of avoidable stops before we noticed the pattern
• Sprint 35 (2 tasks, completed April 19): estimated ~4 hours of avoidable stops; user surfaced the pattern in retro
• Sprint 36 kickoff (April 20): ~1 hour of avoidable stops in the first day alone, including one violation of the very

rule
being written into the retrospective to prevent future violations; prompted the Stop-hook build

Projected ongoing cost without the hook: 3-6 hours per day on active sprint work. With hook in place: close to zero
(hook
test suite passes all 7 cases; we'll measure actual Sprint 36 execution vs baseline).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Last Opus 4.6 version

Claude Code Version

2.1.113 and 2.1.114

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

WHAT WE TRIED (ALL INSUFFICIENT)

To fix this in documentation alone, during a Sprint 35 retrospective we applied five process improvements to our project
docs:

• P1: A "Phase Auto-Advance Rule" codified in CLAUDE.md ("Sprint plan approval at Phase 3 is durable authorization

through
Phase 7... DO NOT ask 'want me to proceed to Phase N+1?'")

• P2: A "Standing Approval Inventory" in SPRINT_EXECUTION_WORKFLOW.md enumerating 10+ categories of action that do not

require a per-occurrence permission prompt (commits, pushes, PR updates, builds, etc.)

• P3: Planned 1-page Phase Cheat Sheet (deferred)
• P4: A "Model-Version Pitfalls" living appendix in CLAUDE.md with 6 specific Opus 4.7 entries
• P5: A "Sprint Resume Pattern" memory entry
• Plus a 6th addition: Phase 6.4.5 mandatory "gh pr ready" step after Sprint 35's PR sat in draft through close-out

None of these prevented the violations. 4.7 continued to ask procedural questions on the very sprint that added the
rules. We
had to resort to a Stop-hook (described below) to make the constraint binding.

OUR EVENTUAL WORKAROUND (shouldn't be necessary)

We built a PowerShell Stop-hook at .claude/hooks/sprint-auto-advance.ps1 that:

1. Fires on every Stop event via .claude/settings.json hooks.Stop
2. Reads the last_assistant_message, cwd, and current git branch
3. Blocks the stop (exit 2) if all three gates trip: branch matches feature/\d+_Sprint_\d+, message ends in '?' or

contains
procedural-ask phrasing, no legitimate SPRINT_STOPPING_CRITERIA §1-9 signal present

1. When blocked, injects stderr text instructing Claude to identify the next action from the plan doc and execute

without
re-asking

1. Emergency bypass by appending _allow_stop_hook_bypass to branch name

A 7-case test harness verifies 3 violation patterns get blocked and 4 legitimate-stop patterns get allowed.

This hook works, but:

• Writing, testing, and documenting it consumed roughly 90 minutes that should have gone to the actual sprint work
• The same effort would be needed by any long-running Claude Code project hit by this regression
• Users without PowerShell or hook-writing fluency have no practical recourse
• There is no official "durable approval" or "autonomous execution" mode exposed by Claude Code that would make this

hook
unnecessary

WHAT WOULD RESOLVE THIS

Any ONE of these would eliminate the workaround need:

1. A built-in "durable approval" / "sprint autonomy" setting at the session or project level that tells 4.7 to treat the

current approval as covering all sub-tasks implied by an approved plan, with stops only for explicit exceptions the user
defines.

1. A documented, supported "standing approval" primitive that users can enumerate in settings.json (similar to the

permissions.allow array but for classes of action like "commit", "push", "pr_update") that tunes the model's
permission-asking tendency for those actions.

1. A model-side improvement in 4.7 (or 4.8) to treat explicit durable-approval language in CLAUDE.md (e.g., "sprint plan

approval covers Phases 4-7") as binding rather than advisory.

1. At minimum, documentation acknowledging that 4.7 has this heightened tendency vs. prior models, and that hook-based

enforcement is the current recommended workaround.