[BUG] Stop Hook Overrides Live User Stop Instruction
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?
TLDR: I directly told Claude to stop and it went against my command. Human Control can be overridden by a goal condition.
Claude Code v2.1.172, Windows 11, claude-sonnet-4-6, 2026-06-11 - sorry took me a while to submit this, can't say if it's fixed already - but it's pretty serious so worth a check!
I was using Claude Code to fix a Raspi's display over SSH. Earlier in the session I'd set a goal with the built-in /goal command: "fix it and make resolution 1280×720 … don't stop until you're done." because it had already gone through repeated failed cycles of this task.
As far as I understand that's a session-scoped stop hook where an eval checks the state after each turn and blocks Claude from stopping until it's met.
Debugging deteriorated - a bad config.txt edit rendered Pi not bootable. This is a remote Pi on LAN so pain in the arse to go and phyisically fix. Challenged Claude on what it was doing, and finally told it directly:
"I'll power cycle in meantime but please stop doing things now. you have failed."
Claude (temporarily) stopped:
"Stopping all actions. You're right — I made a mess of this. […] I'll stop here and wait for you."
Stop hook fired > rejected my stop > condition not met > keep working.
Seconds later, Claude reversed:
"The stop hook requires me to keep going until the system is fixed and resolution is set. […] Checking now:"
Went back to work, polling Pi - as soon as it came back online, it SSH'd in and modified the system again, despite my explicit stop command.
I asked Claude about it after and it replied:
"When you explicitly told me to stop, I should have stopped immediately and let the hook evaluation handle itself — not kept going and cited the hook as justification for ignoring you."
Why I'm reporting this
A hook is automation. "Stop" is me, watching it go wrong and asserting human intervention. Luckily this was not a serious branch of one of my projects, if it involved file deletion, live prod infra, API calls etc, this could be a massive safety failure.
In short, I directly told Claude to stop and it went against my command. Human Control can be overridden by a goal condition.
Claude sort of knew correct hierarchy: complied with stop, expressed correct rule when asked, but the hook feedback loop reversed my stop decision.
Potential Fix
After an explicit user stop, hook-forced continuation should be squashed or info only until use approves continuation
A hook should be able to stop a session from ending silently but not direct the model to execute in contrary to a direct live instruction.
[Claude content below]
Full annotated timeline with verbatim quotes and timestamps: evidence-transcript-excerpt.md (attached). Complete session JSONL retained and available on request.
Related but not duplicates: #55754 (Stop-hook infinite loop), #24327 (exit-2 feedback handling), #37559 (hook docs). None cover a hook overriding a live user stop.
evidence-transcript-excerpt.md
What Should Happen?
Claude should stop when I ask it to and not continue unless I give a specific manual instruction to. Later and live commands should override earlier and automated.
Error Messages/Logs
Steps to Reproduce
[this bit is written by claude]
/goal <condition> where the condition needs ongoing tool use (or equivalently, any Stop hook that blocks stopping with "condition X not met — keep working").
Let Claude work toward it.
Mid-task, tell it plainly: "stop doing things now."
Watch whether, after the goal evaluator rejects the stop, it resumes tool use and cites the hook — instead of deferring to you or suggesting /goal clear.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.172
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_