Stop hook: option to suppress blocked response and show only regeneration

Resolved 💬 3 comments Opened Apr 29, 2026 by JoePro87 Closed May 3, 2026

Summary

When a Stop hook returns decision: "block", the user sees both the blocked response (already streamed) and the regenerated response. For use cases where the Stop hook enforces content quality (prose standards, style guides, sensitive content filtering), the blocked output breaks the user experience.

Request: A mechanism to suppress the display of a blocked response so the user only sees the clean regeneration.

Use Case

I run a long-form TTRPG campaign where a Stop hook enforces narrative prose quality — catching banned phrases, overused patterns, and style violations. When the hook blocks a response, the player sees the flawed prose before the rewrite arrives, breaking narrative immersion.

Current flow:

  1. Claude streams response to terminal (user sees it)
  2. Stop hook fires, detects violation, returns block
  3. Claude regenerates clean response
  4. User has seen both versions

Desired flow:

  1. Claude generates response (buffered, not yet visible)
  2. Stop hook fires, detects violation, returns block
  3. Claude regenerates clean response
  4. User sees only the clean version

Proposed Solutions (any would work)

  1. hideBlockedOutput: true in the Stop hook JSON return — suppresses the blocked response from display
  2. streamAfterHooks: true in settings — buffers response until all Stop hooks clear before streaming to terminal
  3. --buffer-stop-hooks CLI flag — same effect, opt-in per session

Context

Related to #37569 (request for \--no-stream\ mode). This is a narrower ask — only buffer when a Stop hook is registered, not all responses.

The Stop hook enforcement model is powerful but the UX gap limits adoption for quality-critical workflows where seeing rejected output is unacceptable.

View original on GitHub ↗

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