Expose TUI question prompts ("Implement this plan?", reasoning scope, etc.) to the external hook system

Context

PR #17563 shipped PermissionRequest hooks for shell, unified exec, and network approvals. Thank you! We built a desktop overlay (Masko, related to #15311) that uses those hooks to show Allow/Deny cards outside the TUI.

There's one remaining class of prompt that we can't surface: TUI-internal question popups like "Implement this plan?", "Reasoning scope", and the request_user_input dialog chain.

The gap

Looking at codex-rs/tui/src/chatwidget.rs:

enum Notification {
    AgentTurnComplete { response: String },
    ExecApprovalRequested { command: String },
    EditApprovalRequested { cwd: PathBuf, changes: Vec<PathBuf> },
    ElicitationRequested { server_name: String },
    PlanModePrompt { title: String },   // ← invisible externally
}

PlanModePrompt fires on these TUI flows:

• open_plan_implementation_prompt — "Implement this plan?"
• Reasoning scope selection
• A few other plan-mode dialogs

It dispatches through tui.notify() → OSC9/BEL escape sequences only. The legacy notify = ["..."] config in ~/.codex/config.toml (codex-rs/hooks/src/legacy_notify.rs) handles AgentTurnComplete but not PlanModePrompt. There's no external signal.

The preceding update_plan tool call does fire PostToolUse hooks, but it's an inference — there's no guarantee the popup will actually appear (other conditions like has_queued_follow_up_messages can suppress it).

Proposal

Any of these would unblock external UIs:

1. Add a PermissionRequest variant for TUI questions — with tool_name: "request_user_input" or similar, carrying the title + option labels in tool_input. External hooks could respond with the picked option, same pattern as shell approvals.

1. Add a new hook event — TuiQuestionOpened / TuiQuestionClosed, dispatched via the engine hooks alongside PreToolUse etc. Could be observability-only (no decision), which at least lets external UIs show the user "Codex needs you".

1. Extend legacy_notify to fire for PlanModePrompt and ExecApprovalRequested too. Cheap, already-documented mechanism.

Option 1 is the most complete (matches the existing PermissionRequest contract). Option 2 is the smallest change that gives us visibility. Option 3 is the absolute minimum and keeps backward compat.

Related

• #17563 (PermissionRequest hooks) — this is a natural extension, already listed as a follow-up item in that PR's description.
• #15311 (original blocking-hook request from Masko).

Use case

Desktop overlays, remote observability, multi-agent orchestrators. Anything that wants to surface "Codex is waiting on the user" outside the TUI currently goes dark during plan-mode dialogs.