Group hook review by plugin source and allow source-scoped trust

What variant of Codex are you using?

Codex CLI 0.149 on macOS.

What feature would you like to see?

Please group hook review by owning plugin/source and provide an explicit action such as Trust all hooks from MemHub. The action should approve only the exact current hashes contributed by that source, leaving every unrelated pending hook untrusted.

This is not a request for plugins to auto-approve their own hooks. The human approval boundary should remain. The missing piece is a safe, source-scoped batch review in the TUI.

Current behavior

An integration can contribute several related commands across PreToolUse, PostToolUse, and Stop. Codex currently offers:

• Review hooks
• Trust all and continue
• Continue without trusting

In a real profile with 19 new or changed hooks, only 3 belonged to the integration being installed. Trust all was too broad, while locating and approving the 3 related handlers among the other 16 required users to identify them by source path and command text. Most users will not know that this manual step is required or which commands belong to the plugin.

On Codex 0.149, plugin-bundled hook declarations were not mounted in this test, so the integration uses an idempotent compatibility installer in ~/.codex/hooks.json. /hooks consequently attributes them to User config - ~/.codex/hooks.json, not to the plugin that installed them. A durable solution likely needs hook provenance to survive either native plugin mounting or a declared compatibility source/namespace.

Requested behavior

1. Preserve and display the owning plugin/marketplace/source for every hook.
2. Group pending hooks by that source in startup review and /hooks.
3. Offer Trust all hooks from after showing the exact commands and count.
4. Persist trust per exact command hash as today.
5. Leave pending hooks from every other source untouched.
6. Invalidate only changed hook hashes after a plugin update.

Acceptance case

1. A profile already has 16 unrelated untrusted hooks.
2. Installing a plugin contributes one PreToolUse, one PostToolUse, and one Stop hook.
3. Startup says 19 hooks are new or changed, grouped by source.
4. The user reviews the plugin group and chooses Trust all 3 hooks from .
5. Exactly those 3 hashes become trusted; the other 16 remain pending.
6. Updating one plugin command makes only that changed command require review again.

This would make multi-hook plugins approachable without weakening Codex hook trust.

Start with the startup hook review and the /hooks interface, then trace how hook provenance and exact command-hash trust are currently represented. Implement source grouping and review without changing unrelated pending hooks, and verify the acceptance case: three plugin hooks become trusted while 16 other hooks remain pending and only a changed command is reviewed again.