Hooks: expose tool-call correlation in `PermissionRequest`

Start with codex-rs/hooks/src/schema.rs, then trace the ordinary, retry, MCP, Unix approval, and managed-network paths mentioned in the issue to see where originating call IDs are retained or unavailable. Done means attributable PermissionRequest events correlate with the matching PreToolUse and PostToolUse IDs, while retry and approval identifiers remain distinct and ambiguous cases have documented behavior.

What variant of Codex are you using?

Codex CLI 0.145.0 on Linux.

What feature would you like to see?

PermissionRequest command hooks cannot currently be correlated reliably with
the PreToolUse and PostToolUse events for the same tool call. Those events
include tool_use_id; PermissionRequest only includes the tool name and
input.

Matching by tool name and input is ambiguous when identical calls overlap,
repeat, or retry. This prevents external approval interfaces, control rooms,
and policy integrations from maintaining one reliable lifecycle record per
tool call.

When a permission request is uniquely attributable to a tool call, please
include a correlation field whose value matches that call's PreToolUse and
PostToolUse tool_use_id:

{
  "hook_event_name": "PermissionRequest",
  "tool_use_id": "call-id"
}

Please also document the behavior for permission requests that cannot be
attributed unambiguously to one tool call, such as coalesced managed-network
approvals. An optional tool_use_id that is omitted in those cases would
satisfy this use case, but the exact representation is open to maintainer
preference.

This field would correlate the hook invocation with the surrounding tool
lifecycle. It need not uniquely identify separate permission attempts for that
tool call; per-attempt identity is an orthogonal concern.

Additional information

The current hook schemas
define tool_use_id on the adjacent pre- and post-tool inputs but not on
PermissionRequest. The ordinary, retry, MCP, and Unix approval paths retain
an originating call ID, while managed-network approval may use coalesced
target-based identity. Existing retry suffixes, approval UUIDs, and synthetic
network keys should not be exposed as though they were originating tool-call
IDs.

Expected behavior:

• Attributable permission requests can be joined to the corresponding
  PreToolUse and PostToolUse events.
• Retry bookkeeping and approval UUIDs are not exposed as originating
  tool-call IDs.
• Cases without unambiguous attribution have explicit, documented behavior.

I searched the tracker before filing. Exact searches for PermissionRequest tool_use_id and PermissionRequest call_id returned no dedicated issue. The
closest related issues are:

• #21753, the broader hook-parity
  tracker, which notes that PermissionRequest still needs a complete payload
  contract.
• #28117, which concerns
  structured escalation metadata and mentions correlation IDs as part of a
  broader permission-transition contract.
• #15311, the completed request
  for the blocking PermissionRequest hook itself.

This request is narrower: it asks only for a stable join between an attributable
PermissionRequest invocation and the existing tool lifecycle events.