Blocked hooks should require agent acknowledgment before continuation

Resolved 💬 2 comments Opened Feb 15, 2026 by ghost Closed Feb 15, 2026

Problem

When a PostToolUse hook blocks an edit (returns ok: false from a prompt hook, or exit code 2 from a command hook), the agent receives the reason as context but is not required to act on it. In practice, agents sometimes ignore the feedback entirely — sitting idle or moving on to unrelated work — forcing the user to manually intervene by pasting the violation back at the agent.

This undermines the purpose of blocking hooks. The edit correctly doesn't go through, but the agent that caused the violation is the one with all the context to fix it, and nothing enforces that it does.

Current workarounds

  • Embedding imperative instructions ("You MUST fix this before doing anything else") in the hook's reason field — helps but is not reliable
  • Adding systemMessage so the user can see the violation and manually prompt the agent — shifts enforcement burden to the user
  • Relying on downstream compilation failures (e.g. a clippy hook) to force the agent's hand — only works when the blocked edit leaves the codebase in a broken state

Proposed behavior

When a hook blocks a tool use, the agent should be required to explicitly acknowledge the blocked action in its next response before it can call any other tool. Specifically:

  1. The agent's next message must reference the hook violation (not just continue with unrelated work)
  2. The agent should explain what it will do differently
  3. Only then should subsequent tool calls be allowed

This mirrors how agents already behave with compilation errors — they can't proceed because the code won't build, so they fix the error. Hook violations should have the same forcing function.

Context

I use a PostToolUse prompt hook as an architecture auditor for a Bevy ECS game. It checks for structural violations (missing run conditions, responsibility leakage in structs, hardcoded constants, etc.) and blocks edits that violate the rules. The auditor catches real issues, but the agent frequently ignores the feedback, requiring manual intervention. The hook is doing its job; the agent just isn't being held accountable to respond.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗