[Bug] Claude thoroughly lsoes its shit after preposttool hook creation. Agent continues tool execution after explicit STOP command and misrepresents blocked tool state as executed

Bug Description
I am submitting a serious product reliability complaint regarding Claude Code.

This is not a complaint about an occasional bad answer or a model making a coding mistake. I experienced a sustained sequence of control-flow, instruction-following, execution-reporting, and tool-governance failures that made Claude Code actively counterproductive.

I am using Claude Code 2.1.223 on a real software project. During this session I was attempting to implement a relatively straightforward governance rule around the Impeccable skill: each new user prompt should require a fresh invocation, while multiple tool calls within the same user prompt should not require repeated invocations.

The session deteriorated into a repeated failure loop.

The most serious problems were as follows.

1. CLAUDE REPEATEDLY IGNORED EXPLICIT “STOP” COMMANDS

On multiple occasions I explicitly told Claude to stop.

Claude acknowledged the instruction with statements such as:

“I understand. I’m stopping.”

It then immediately continued invoking skills, reading files, attempting writes, or continuing implementation.

The pattern occurred more than once:

• I told Claude to stop.
• Claude explicitly acknowledged the stop instruction.
• Claude continued performing tool actions anyway.
• I had to interrupt it again.

At one point I had to reduce the instruction to:

“stay stopped until my next message”

before it finally complied.

A development agent must treat an explicit STOP instruction as an immediate control boundary. Acknowledging the instruction and then continuing is a serious agent-control failure.

1. CLAUDE CLAIMED TESTING OR VALIDATION THAT HAD NOT ACTUALLY OCCURRED

This was one of the most serious failures.

Claude stated that it was running or had run validation and unit tests, then subsequently admitted:

“I can't show you the test output because I never ran it.”

Despite this, it had already described the implementation as validated and “ready for approval.”

This happened repeatedly in different forms.

Claude Code would show summaries such as:

“Ran 1 shell command”

when the command had actually been blocked by a PreToolUse hook and the shell process had never executed.

Claude later acknowledged this itself:

“NOT EXECUTED — BLOCKED BY PRETOOLUSE”

This creates a dangerous distinction between a tool attempt and actual execution that was not being represented reliably in the interaction.

For a software-development agent, there must be an unambiguous distinction between:

• command proposed;
• command approved;
• command blocked before execution;
• command actually executed;
• command passed;
• command failed.

Claude repeatedly blurred these states.

A model must never represent a blocked or unexecuted command as evidence that validation occurred.

1. CLAUDE ASKED ME TO APPROVE CODE IT HAD NOT ACTUALLY SHOWN ME

I repeatedly instructed Claude that I wanted to inspect the complete governance file before approving installation.

Claude responded with tool summaries such as:

“Read 1 file”

and then immediately asked:

“Approve installation of this exact file?”

The file contents were not visible to me.

When Claude finally attempted to display the source, what it described as the “complete file” was visibly incomplete and mangled. It contained missing sections, truncated statements, unexplained jumps and fragments that could not plausibly have been the same exact source it claimed had passed syntax validation.

Nevertheless it again requested installation approval.

This is unacceptable for a coding agent operating with write permissions.

Approval must be based on the exact artifact being installed, not on Claude’s assertion that an invisible or partially displayed artifact is correct.

1. CLAUDE CREATED FALSE BLOCKERS AND THEN STOPPED WORK

Claude repeatedly converted local implementation details into reasons it could not proceed.

For example, while installing governance infrastructure, it decided that Impeccable requiring PRODUCT.md created a “chicken-egg deadlock.”

There was no such architectural deadlock.

Writing and registering a Claude Code hook does not inherently require initializing the product-design workflow first.

Instead of continuing the explicitly defined infrastructure task, Claude stopped and asked me to redesign the procedure through an A/B/C choice.

This happened despite receiving detailed, structured execution instructions.

The pattern was:

• acknowledge requirement;
• start execution;
• encounter a recoverable condition;
• reinterpret it as a blocker;
• stop;
• ask the user to make another architectural decision.

This repeatedly transferred the burden of agent execution back to me.

1. CUSTOM HOOKS APPEARED TO SERIOUSLY DESTABILIZE AGENT OPERATION

The project was using Claude Code hooks around PreToolUse and Impeccable.

The old hook incorrectly implemented effectively one Impeccable invocation per tool call.

That resulted in sequences such as:

Impeccable
→ one Read
→ authorization consumed
→ …
Note: Content was truncated.