Interactive TUI: PreToolUse-equivalent bash deny is not enforced (matches exec mode); apply_patch deny has a UX bypass via generic sandbox-failure retry prompt

Summary

While testing third-party hook integration against Codex CLI v0.144.6
(Windows, real ConPTY via node-pty), I found two issues in the
interactive TUI that don't match documented hook behavior.

1. bash deny is not enforced in interactive mode either

codex exec is documented (and previously reported) to fire hooks
but not actually block bash commands on deny. I confirmed the same
holds in interactive TUI mode: the hook fires and is recorded, but
the command executes regardless. permission_mode was "default"
(not "bypassPermissions" as in exec), same result.

2. apply_patch deny has a UX bypass

By default, a hook denying apply_patch correctly blocks the write —
confirmed across 5+ retries with no file created. However, in
interactive mode, the denial resurfaces to the user as a generic
"sandbox failure" prompt:

"Would you like to make the following edits? Reason: command
failed; retry without sandbox?"

This prompt does not indicate the block came from a hook, and the
default-highlighted option is "1. Yes, proceed" — a single Enter
keypress writes the file, silently bypassing the original deny.

3. Minor UX note

The "Hooks need review" dialog's actual keybinding is t (trust
all) — the on-screen numbered options did not respond to number-key
input during testing.

Environment

• Codex CLI 0.144.6, Windows, interactive TUI (real ConPTY)
• Minimal hooks.json with a deny-returning probe script

Happy to share the exact repro script if useful.