Hooks: expose tool-call correlation in `PermissionRequest`

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.