Feature: Allow hooks to suppress user-visible output on block (silent re-prompt)

Resolved 💬 4 comments Opened Mar 26, 2026 by jimovonz Closed May 2, 2026

Description

When a Stop hook blocks a response (exit 2) and re-prompts the LLM, the user sees:

  • "Ran 1 stop hook (ctrl+o to expand)"
  • The block reason in an expandable section

For enforcement hooks that block frequently (quality gates, context checks), this creates noise. The user sees the hook fire, then sees the LLM's re-prompted response — they don't need to see the intermediate enforcement step.

Requested

A mechanism for hooks to indicate their output should be silent/suppressed. For example:

  • A "silent": true field in the hook's JSON output
  • Or a separate exit code (e.g. exit 3 = block silently)

This would allow the re-prompt to happen transparently — the LLM gets the block reason and adjusts, but the user only sees the final corrected response.

Use case

Memory systems (like Cairn) that enforce context retrieval, completeness, and quality gates via stop hooks. These fire on ~30% of responses but are internal LLM guidance, not user-facing errors. Examples:

  • Completeness enforcement — response marked complete: false, hook re-prompts to continue
  • Context retrieval — LLM declares it needs context, hook injects memories and re-prompts
  • Quality gates — missing required metadata fields, hook asks for correction

In all cases the user doesn't benefit from seeing the enforcement step — they just want the final, corrected response.

Related

  • #35086 — Hook output display doesn't distinguish between blocking (exit 2) and failure (exit 1). That issue covers the _label_ shown; this request is about suppressing the output _entirely_.

Environment

  • Claude Code version: latest
  • OS: Linux
  • Using Stop hooks with decision: block JSON output

View original on GitHub ↗

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