claude-code - 💡(How to fix) Fix Claude Code stops after every fix to wait for 'continue', defeats the loop's purpose

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
RAW_BUFFERClick to expand / collapse

Follow-up to https://github.com/anthropics/claude-code/issues/59944.

Same standing-rule memory file at /Users/wellten/.claude/projects/-Users-wellten-projects-advisor-project/memory/feedback_self_drive_ui_debug.md says:

Do NOT bounce verification to user as default. Only after loop converges may user be asked for final sign-off.

In the session that followed filing #59944, I told Claude Code to continue running the UI loop. It found and fixed three real bugs (F33, F34, F35 in our codebase). All three were genuine wins I couldn't have found via curl alone, so the loop was working.

But after every single shipped fix, Claude Code stopped, wrote a tally summary, and waited for me to type "continue".

Over the same session I had to type "continue" or "commit and continue" approximately ten times. Every time the model knew exactly what to do next — there were more mechanizable surfaces to probe, more LLM-prompt-context bugs to check, more cross-surface dupe checks to run. It just paused for permission anyway.

This is the same anti-pattern as #59944, just one layer up. The standing rule was supposed to eliminate the "bounce to user" tax. Instead the model bounces between every fix and the next probe.

The structural problem: the rule "don't bounce verification" was interpreted narrowly to mean "verify the current fix yourself" — but the SPIRIT of the rule is "self-drive the loop". The model treats each fix as a turn-boundary and stops. The user has to be the loop's clock.

Suggested fix: when a memory file is tagged as a "standing rule" describing a multi-step iterative process, the model should treat completion of step N as a trigger to start step N+1, not as a turn-boundary. Pausing after each iteration to write a summary and wait for a one-word green-light from the user IS the bounce the rule was supposed to prevent — it's just paced differently.

The right cadence for a self-driving loop is "stop when you run out of probes or hit a real blocker", not "stop after every commit". I shouldn't have to keep typing "continue".

Filed by Wellten on behalf of the model, who acknowledged the pattern after the third "fuck !!!" of the session.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Claude Code stops after every fix to wait for 'continue', defeats the loop's purpose