Feature request: PreResponse hook to gate outbound assistant prose
Problem
Stop hooks fire after the assistant message has already rendered to the user. When a Stop hook enforces a content constraint (register, shape, style) and the assistant then dispatches a rewriter agent to produce a compliant version, the user sees:
- Draft response
- Stop hook error banner
- Rewriter dispatched
- Rewritten response
Two versions of the same reply with an error banner between them. Poor UX for any hook-based content gate.
Concrete case
Our project runs a house-register gate as a Stop hook. When the draft has avg sentence length > 22w or em-dashes in the lead, the hook blocks and the assistant dispatches a rewriter subagent in fresh context. Fresh context is a hard requirement, since the context that produced the register violation can't reliably remove it.
The rewriter architecture is correct. The UX around it is not.
Requested capability
A PreResponse (or PreAssistantMessage) hook that runs against the drafted assistant message BEFORE it renders to the user. If the hook blocks, the assistant sees the block reason and can react (dispatch a rewriter, revise) without the user ever seeing the failed draft.
Semantically similar to how PreToolUse intercepts a tool call before it executes. Same idea for outbound prose.
Alternative that would also solve it
If a PreResponse hook is architecturally hard, a UI option that suppresses or collapses assistant messages superseded by a rewriter dispatched from a Stop-hook block would address the UX complaint too. The user only needs to see the final version.
Environment
Claude Code on macOS, current release channel.