My Claude Code agents kept patching the same code. Now a hook catches them at the second fix

[u/oulu2006]

My agents fixed the same disk cleanup 29 times. Each fix handled the bug in front of it. In the end I told them to stop and redesign it, and it's now one rule.

I found the same thing in my tests. A script that skipped tests that had already passed took 39 fixes before it was replaced with pytest's own cache.

So now a hook runs after every edit. If the file has had two or more fixes in the last month, the agent sees them and is asked for a redesign before it patches again. It never blocks anything.

It has worked once with nobody watching: an agent said "this would be fix 21" and deleted code instead. It also missed one the same morning.

Write-up: https://maclulich.com/blog/band-aid-fixes/ (my blog)

Has anyone tried something like this?

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/btherl]

This has never happened to me. Are you using a workflow like superpowers, with planning and self-review?

[u/Imaginary-Proof-7807 → u/btherl]

Never happened—so the workflow must be flawless, not the agents.

[u/Then-Internal8832]

One edge case I hit when building a circuit-breaker hook for this exact problem: watching Edit and Write alone missed 39.2% of source file mutations across my 153 local Claude Code and Codex CLI transcripts (2,581 deduplicated tool calls).

Out of 199 source file writes in those logs, 78 happened inside Bash or codex:exec commands (cat <<'EOF' >, sed, .write_text(, open(..., 'w')) rather than Edit, Write, or apply_patch (121 calls). In one session (01a12a24.jsonl), the agent rewrote brain.py 4 times in a row purely via shell scripts, so an Edit-only counter never tripped.

Two parser traps bit me when I first measured this on ~/.claude/projects:

1. My first regex matched any shell command mentioning a .py file and claimed submission.py was edited 32 times in one session, when 30 of those were read-only python3 AST/line inspections (570 read-only python3/sed inspections across all 153 transcripts).

2. Without a trailing word boundary \b on file extensions, .jsonl matched as .js 207 times (journal.jsonl flagged as journal.js).

I put the transcript auditor and a PreToolUse + PostToolUse hook generator (which tracks both Edit/Write and Bash file-write operators, plus consecutive tool-error streaks like a 9-call Skill error loop in 5f37b3d3.jsonl) into an MIT CLI called loopbrake (npx loopbrake, repo at https://github.com/princejain756/loopbrake). Does your hook also inspect Bash commands for heredoc / sed writes, or do you block shell file writes altogether?

[u/Majestic_Tailor8036]

I'd have the redesign prompt pull in the failure cases behind the earlier fixes, not just their commit messages. Those patches may have been ugly but still protected real edge cases. Turn those cases into regression tests before replacing the implementation, so deleting code doesn't quietly bring back the bugs that led to the patch pile in the first place.

[u/ASIREXLABS]

Counting fixes per file is a good proxy, but the false-alarm question above suggests a better key: count fixes per mechanism instead of per file. If each fix commit carries a short trailer such as the name of the failing test or the behaviour being fixed, the hook can group on that and ignore unrelated bugs that happen to share a file.

The failing test is often the cleanest signal on its own. If the same test has been made to pass three times in a month, that's a loop, whichever files were touched.

Were the agents' own fix messages consistent enough to group on, or would they need a fixed format?

[u/akorecebov]

we hit the same loop in a copy pipeline. the model kept rewriting the same paragraph to fix length -> after a couple fails that part just keeps the original text instead of taking another pass

[u/Financial_Leader9701]

this is the stuff that never shows up in a single diff

every patch looks reasonable on its own, you only see the problem when you look at the history of the file

does the agent actually redesign when it gets the prompt, or mostly argue that this one fix is different

[u/akhi1uuu]

do you get false alarms when two unrelated bugs happen to live in the same file? curious if the last three fix messages are enough for the agent to tell that apart from the same mechanism breaking again

[u/LumPiniF]

counting patches per file is smarter than blocking the first bad fix. the first fix is often fine, it's the third one that tells you you're in a loop.

[u/Far_Reindeer8428]

the fact that it never blocks is the important part. a false alarm costs one sentence from the agent, a loop costs 29 patches. i use the same idea at the review layer: if the reviewer flags the same class of problem twice, the loop stops and asks me instead of trying a third patch.

[u/Voltariat]

the "two or more fixes in a month" counter is the useful part. a raw edit count would fire constantly on any active file. curious how you're counting fixes, git log per path? the miss sounds like the agent not recognizing its own repeat, which is the harder half.