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.

Start by reproducing the deny behavior with the minimal hooks.json probe in both the interactive TUI and codex exec entry points. Check the apply_patch sandbox-failure retry flow and the Hooks need review dialog, including the t keybinding. Done means bash denies are enforced, apply_patch denial cannot be bypassed by the default retry prompt, and the dialog's displayed controls match their keybindings.