hooks: emit Bash PostToolUse when exec_command completes via write_stdin

[eternal-openai]

Fixes #16246.

Why

exec_command already emits PreToolUse, but long-running unified exec commands that finish on a later write_stdin poll could miss the matching PostToolUse. That left the Bash hook lifecycle inconsistent, broke expectations around tool_use_id and tool_input.command, and meant PostToolUse block/replacement feedback could fail to replace the final session output before it reached model context.

This keeps the fix scoped to the exec_command / write_stdin lifecycle. Broader non-Bash hook expansion is still out of scope here and remains tracked separately in #16732.

What changed

• Compute and store PostToolUsePayload while handlers still have access to their concrete output type, and carry tool_use_id through that payload.
• Preserve the original hook-facing exec_command string through unified exec state (ExecCommandRequest, ProcessEntry, PreparedProcessHandles, and ExecCommandToolOutput) via hook_command, and remove the now-unused session_command output metadata.
• Emit exactly one Bash PostToolUse for long-running exec_command sessions when a later write_stdin poll observes final completion, using the original exec_command call id and hook-facing command.
• Keep one-shot exec_command behavior aligned with the same payload construction, including interactive completions that return a final result directly.
• Apply PostToolUse block/replacement feedback before the final write_stdin completion output is sent back to the model.
• Keep write_stdin itself out of PreToolUse matching so it continues to act as transport/polling for the original Bash tool call.
• Restore plain matcher behavior for tool-name matchers such as Bash and Edit|Write, while still treating patterns with regex characters (for example mcp__.*) as regexes.
• Add unit coverage for unified exec payload construction and parallel session separation, plus a core integration regression that verifies a blocked PostToolUse replaces the final write_stdin output in model context.

Testing

• cargo test -p codex-hooks
• cargo test -p codex-core post_tool_use_payload
• cargo test -p codex-core post_tool_use_blocks_when_exec_session_completes_via_write_stdin

[abhinav-oai]

[question] when would this be empty?

and isn't it the same as call_id?

[eternal-openai]

Yeah, good ask - I think you're right that this should never happen. It’s only there as a defensive fallback because ExecCommandToolOutput has one synthetic constructor path (intercept_apply_patch) that doesn’t participate in the normal unified-exec lifecycle and leaves event_call_id empty. That path also never produces a PostToolUse payload, but I'll leave it in just in case

[abhinav-oai]

LGTM 🚢