Add managed hook suppression

[abhinav-oai]

Why

Managed hooks from requirements can be intentionally noisy when they run every turn, and the current runtime always surfaces their lifecycle notifications to clients. We want admins to be able to suppress only those managed hook notifications without giving user config a way to hide local/plugin hooks.

What

• add a managed-requirements-only suppress field for command hooks
• fail open when suppress appears in user hook config by ignoring it and emitting a warning
• carry suppression through hook dispatch and omit hook/started + hook/completed notifications for suppressed runs while still recording metrics/analytics
• keep the app-server requirements API shape unchanged for now; Codex app inherits suppression automatically because it renders from lifecycle notifications

[eternal-openai]

Hey I know I'm reviewing this too early since it's still a draft, but there are some issues:

• the mechanism of just dropping the notifications doesn't really work, as elegant as that would be. consider the case where the hooks still blocks or crashes - the UI would need to then make what happened visible, rather than just stopping the thread without explanation. there's probably other things that still need visual treatment, like stop-block continuation prompts originating from hidden hooks
• so we actually do need to thread hook visibility through the notifications, and just have the UIs decide to hide them more intelligently
• some of the renames here feel like a bit more churn than is necessary
• i think the naming could be better. How about something like visibility_hint: "default" | "hidden" ? my concern is that the current naming overlaps too much with the spec's suppressOutput which means something different

[abhinav-oai]

Hey I know I'm reviewing this too early since it's still a draft, but there are some issues:

• the mechanism of just dropping the notifications doesn't really work, as elegant as that would be. consider the case where the hooks still blocks or crashes - the UI would need to then make what happened visible, rather than just stopping the thread without explanation. there's probably other things that still need visual treatment, like stop-block continuation prompts originating from hidden hooks
• so we actually do need to thread hook visibility through the notifications, and just have the UIs decide to hide them more intelligently
• some of the renames here feel like a bit more churn than is necessary
• i think the naming could be better. How about something like visibility_hint: "default" | "hidden" ? my concern is that the current naming overlaps too much with the spec's suppressOutput which means something different

hmm that's a great point

visibility_hint is good, I like the enumerated settings as well so we can expand in the future too.

another idea that could be interesting is exposing as part of normal config but still have requirements clamp the value. I think normal users would also like this config as I've seen a few related issuesL

• Allow hook additionalContext to be model-visible but hidden from TUI #21696
• Add an option to collapse hook-injected context in the CLI transcript #20766
• Allow Codex hooks to run silently without rendering completed hook entries #19383

will also take a pass and clean it up overall!