Security: define UserPromptSubmit hook ordering and deny short-circuit across plugins

Security impact

Codex supports both user/root hooks (~/.codex/hooks.json) and plugin-provided hooks for the same lifecycle event. The configuration schema documents both surfaces but does not define their execution order or the behaviour after a blocking result.

For UserPromptSubmit, this creates a data-boundary ambiguity: a root policy hook can deny obvious secret pastes, while an independently installed context-capture plugin may persist the raw prompt before the deny decision is observed.

Minimal non-secret reproduction

1. Enable a root UserPromptSubmit hook that returns { "decision": "block", "reason": "test" } for a sentinel prompt.
2. Enable a plugin UserPromptSubmit hook that appends the received prompt to a local test file and returns a neutral result.
3. Submit the sentinel prompt.
4. Observe which hook ran first, whether the second hook ran after a block, and the final decision surfaced to the host.

Requested host-level contract

For every hook event, especially UserPromptSubmit:

• define a deterministic order across root and plugin hook sources, and expose it in diagnostics;
• evaluate blocking policy hooks before capture/side-effect hooks, or provide explicit priority classes;
• short-circuit subsequent side-effect hooks after a deny decision;
• aggregate outcomes deterministically when all hooks must run;
• distinguish timeout/nonzero-exit/invalid-JSON from a policy deny.

Plugins should not need to know about each other or duplicate each other's secret-detection rules. This is related to #32295's request for host-level aggregation, but applies to pre-prompt policy and privacy boundaries.

Environment

• Codex CLI 0.146.0
• Windows 11
• root hooks plus an installed plugin both registering UserPromptSubmit