Feature Request: Hook for assistant text output (PreResponse / PostResponse)

+1. A PreResponse hook would complete the hook lifecycle — currently we can intercept actions but not text output.

Current partial workaround using PostToolUse on the last tool call:

The closest we have today is a PostToolUse hook that checks the model's output after tool execution and provides feedback via stderr:

#!/bin/bash
# quality-gate.sh — Flag low-quality patterns in tool output
INPUT=$(cat)
OUTPUT=$(echo "$INPUT" | jq -r '.tool_output // empty' 2>/dev/null)

# Check for filler patterns
if echo "$OUTPUT" | grep -qiE 'I will now|Let me|I am going to|Here is what I'; then
    echo "WARNING: Filler text detected in tool output. Be direct." >&2
fi
exit 0

But this only catches text within tool outputs, not the final response text. A true PreResponse hook would enable:

• Enforcing word count limits
• Blocking speculative answers
• Filtering out apology/filler patterns
• Enforcing CLAUDE.md tone rules mechanically instead of relying on prompt compliance

For now, CLAUDE.md instructions like "don't write filler" work ~90% of the time with Opus, but can't be enforced with exit code 2 the way tool hooks can.

+1 — concrete use case that illustrates why prompt instructions aren't enough.

I run Claude Code as a personal assistant hub (Obsidian vault + MCP integrations). One of my standing rules is "every reference must be a clickable link" — file paths should be wrapped in obsidian:// URIs, domains should be https:// links, task IDs should have context. The instruction is in CLAUDE.md, in memory, and has been reinforced through feedback multiple times.

It still doesn't work reliably. The model follows it ~70% of the time. The other 30% I get bare somefile.md references styled as code but not linked, bare pro.portland.gov without a URL wrapper, or "I found this email" with no actionable link. Instruction-following degrades under competing priorities (long context, complex tasks, multiple agents).

A PreResponse hook would let me run a regex scan for un-linked references and inject a correction message before the response renders — rather than after, which just adds noise. The Stop hook doesn't solve this because by the time it fires, the user has already read 4 paragraphs of un-linked text.

This is fundamentally a formatting enforcement problem that can't be solved with stronger prompting. It needs a hook.

+1 on this. Concrete use case from a developer workflow:

I run a UserPromptSubmit hook that injects absolute current time into every message (e.g. [NOW: 2026-04-20 16:54 Mon]). The agent reads it, acknowledges the correct time, and still emits relative phrasings like "tonight" at 16:54 on a Monday afternoon. Substrate is correct; language at emission overrides.

I've captured this as an agent learning that auto-surfaces on feedback. correction moments, but by definition that fires AFTER the
slip has already reached me, so it only teaches across sessions, not within the one where the slip happened. Same-class slip repeated in the very next session after being captured.

A PreResponse hook would close the gap: scan draft text for relative adverbs against the injected NOW, inject an additionalContext rewrite instruction, never emit the broken phrasing.

Broader pattern: any last-mile rule where substrate knows the correct answer but pre-training overrides at emission banned vocabulary, stale-state claims, name collisions. None of the existing hooks (PreToolUse / UserPromptSubmit / PreCompact / Stop) cover the decision-to-delivery window.

+1 on this, ideally so that it fires on "chunks" of output too, not only before or after the whole output.

+1 on the underlying request. The thread already has strong
articulation of the gap — particularly @havnwright's
"decision-to-delivery window" framing, @yurukusa's analysis of why
the current PostToolUse workaround only catches text inside tool
outputs, @epechuzal's concrete demonstration that Stop fires
after the user has already read the broken text, and @lightrow's
ask for chunk-level firing. Rather than restating those, this
comment adds two design points that haven't come up yet, plus a
brief engagement with @lightrow's chunking suggestion.

1. Hook output convention — mirror PreToolUse's permissionDecision

Following the established PreToolUse shape, adapted for response
gating:

{
  "hookSpecificOutput": {
    "hookEventName": "PreResponse",
    "permissionDecision": "allow" | "deny" | "modify",
    "permissionDecisionReason": "<surfaced when deny>",
    "modifiedResponse": "<replacement text when modify>"
  }
}

• allow (default) — deliver as drafted.
• deny with reason — block delivery; surface the reason to the

user (or back to the model for retry, depending on configuration).

• modify with replacement text — substitute the drafted text

before delivery. This handles the formatting-enforcement use
cases (e.g., @epechuzal's linkification, @havnwright's
NOW-timestamp rewriting) without bouncing the response and asking
the model to redraft from scratch.

Reusing the PreToolUse output shape keeps hook contracts
consistent across event types and lets existing integrations carry
over their output-parsing logic.

2. Lifecycle symmetry — every model output channel becomes hookable

Picking up @havnwright's "decision-to-delivery window" diagnosis,
the proposed event would complete the lifecycle:

| Lifecycle stage | Hook |
|---|---|
| User message arriving | UserPromptSubmit |
| Tool call about to fire | PreToolUse |
| Tool call completed | PostToolUse |
| Response drafted, not yet delivered | PreResponse (missing) |
| Turn ended | Stop |

Today the prose channel is the only model output without a hook
attached, which is exactly the asymmetry producing the
rule-enforcement gap the OP describes. With PreResponse, every
output channel the model produces — tool calls AND prose —
becomes observable and gateable.

Engaging @lightrow's chunking suggestion

A streaming variant — call it PreResponseChunk — could fire on
each chunk as it's produced rather than only on the full draft.
Trade-offs:

• Pro: catches issues earlier (don't wait for full draft); lower

per-fire latency; enables progressive enforcement for very long
responses.

• Con: hook fires N times per response (cost / observability

noise); chunk-level rules are harder to write than whole-response
rules (a banned phrase can span chunk boundaries); modify
semantics are harder (replacing already-streamed bytes vs
truncating the rest).

Could ship as a follow-on with a separate event name if the basic
PreResponse lands first. Doesn't need to block the core design.

Compatibility / payload-size note

• Additive — no existing hook configurations affected.
• For long responses, options include a configurable max-bytes

truncation parameter, a separate response_text_path field
pointing to a temp file, or both.

---

🤖 Generated with Claude Code

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

MessageDisplay hook is probably it?

This gap is still open. (I can't reopen the issue from my account — no triage permission on this repo — so treat this as a correction on the record, not a reopen.) I want to correct the one post-close suggestion so the thread doesn't leave a misleading pointer.

MessageDisplay hook is probably it?

Not quite. MessageDisplay does exist now — it was added in v2.1.152 (changelog: "Added a MessageDisplay hook event that lets hooks transform or hide assistant message text as it is displayed") — but it's a display-layer filter, not the response-gating hook this issue asks for. That distinction is exactly the one that matters here.

Per the current hooks reference:

• It can't block. The exit-code-2 table lists MessageDisplay → Can block? No → "The original text is displayed". There is no pre-delivery gate.
• Its rewrite is cosmetic only. The decision-control table: "displayContent replaces the displayed text on screen. Display-only: the transcript and what Claude sees keep the original." You can change what is painted on the terminal, but the original text still lands in the transcript and in the model's own context.

That breaks every enforcement use case in this thread:

• @yurukusa / OP — "block speculative answers", "enforce word limits": can't block; exit 2 is a no-op.
• @epechuzal — linkify un-linked references: displayContent would only mask them on screen; the transcript keeps the bare somefile.md, so downstream tooling (and the model) still see the unenforced text.
• @havnwright — rewrite relative-time phrasing against an injected NOW: same problem — the broken phrasing persists in transcript/model state; only the screen is patched.

What is still missing is a hook in the decision-to-delivery window (@havnwright's framing) that can deny/modify the actual response — not just its rendering. There is no PreResponse or PostResponse hook in the current docs, and Stop still fires too late to rewrite. MessageDisplay is a genuinely useful display filter, but it does not close this gap.

(Sources: hooks reference and changelog at code.claude.com, v2.1.152 entry, verified 2026-06-10.)

🤖 Generated with Claude Code

Re-filed as #66749 with the current hook landscape (notably: MessageDisplay shipped in v2.1.152 but is display-layer only and doesn't close this gap). Continuing the discussion there.

+2000, seriously similar issues are being closed as "not planned"? Claude is PAINFULLY verbose and bloated of jargon, we need a way to stop this nonsense