Stop hook: option to suppress blocked response and show only regeneration
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:
- Claude streams response to terminal (user sees it)
- Stop hook fires, detects violation, returns block
- Claude regenerates clean response
- User has seen both versions
Desired flow:
- Claude generates response (buffered, not yet visible)
- Stop hook fires, detects violation, returns block
- Claude regenerates clean response
- User sees only the clean version
Proposed Solutions (any would work)
hideBlockedOutput: truein the Stop hook JSON return — suppresses the blocked response from displaystreamAfterHooks: truein settings — buffers response until all Stop hooks clear before streaming to terminal--buffer-stop-hooksCLI 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗