Support PreToolUse permissionDecision: ask for native approval prompts

Summary

Please add native support for PreToolUse hooks returning permissionDecision: "ask", so a hook can escalate a specific tool call into a human approval prompt.

This was already explored in closed PR #20702: https://github.com/openai/codex/pull/20702

Current behavior

Codex currently parses permissionDecision: "ask", but treats it as unsupported. A PreToolUse hook that returns:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask",
    "permissionDecisionReason": "This command needs explicit approval."
  }
}

fails with:

PreToolUse hook returned unsupported permissionDecision:ask

The same applies to some Claude-compatible fields such as continue: false, stopReason, and suppressOutput: they are parsed, reported as unsupported, and the tool call continues depending on the hook failure behavior.

Desired behavior

PreToolUse permissionDecision: "ask" should route that specific tool call to the native Codex human approval flow.

Suggested precedence:

• PreToolUse: ask should force a user approval prompt for that tool call.
• PreToolUse: deny should continue to block the tool call.
• PreToolUse: allow should not bypass core policy, sandbox checks, network checks, or later concrete approval boundaries.
• Core policy should remain authoritative; a hook should be able to tighten approval requirements, not weaken them.

Why this matters

Hooks are useful as durable safety policy. Today a hook can deny a tool call, but it cannot say “this is allowed only after explicit user approval.” That forces users to either globally tighten approval policy, which is noisy, or deny commands that would be safe with per-call approval.

This is especially useful for Codex App/CLI setups where teams use PreToolUse hooks to guard high-risk commands, writes, network access, production operations, or organization-specific workflows.

Related work

PR #20702 already implemented a design in this direction and described the intended safety property: ask can tighten a decision into explicit approval, while allow must not waive core policy or later checks.

It was closed for inactivity, not because the feature was rejected. Reopening that PR or landing an equivalent focused implementation would solve this request.