Repository navigation
Expose TUI question prompts ("Implement this plan?", reasoning scope, etc.) to the external hook system #19328
Description
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:
-
Add a
PermissionRequestvariant for TUI questions — withtool_name: "request_user_input"or similar, carrying the title + option labels intool_input. External hooks could respond with the picked option, same pattern as shell approvals. -
Add a new hook event —
TuiQuestionOpened/TuiQuestionClosed, dispatched via the engine hooks alongsidePreToolUseetc. Could be observability-only (no decision), which at least lets external UIs show the user "Codex needs you". -
Extend
legacy_notifyto fire forPlanModePromptandExecApprovalRequestedtoo. 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
- Add PermissionRequest hooks support #17563 (PermissionRequest hooks) — this is a natural extension, already listed as a follow-up item in that PR's description.
- Add blocking PermissionRequest hook for external approval UIs #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.
Activity
github-actions commentedon Apr 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ma08 commentedon May 5, 2026
+1 badly need hook support for internal questions like plan approval and
request_user_inputetc.the usecase i have is to receive whatsapp/email messages via hooks when working on a remote workspace
this picture has an overview of my remote workspace setup to use codex in a VM be pinged on whatsapp/email when it needs user input: https://github.com/ma08/botfiles/blob/main/docs/assets/readme/remote-development-stack.jpg
explained in this article: https://x.com/curious_queue/status/2049660997993152855?s=20
oxysoft commentedon May 8, 2026
Indexed this hook ticket in the umbrella tracker: #21753
Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.
ma08 commentedon May 11, 2026
i was able to temporarily circumvent this using the app server approach to track
request_user_inputevent and do necessary actions (like sending message to update user about need for input etc): ma08/botfiles#25sharing in case this helps others
would still appreciate native hook support for events like this!
microHoffman commentedon May 15, 2026
+1 to implement this feature, it would be very much helpful also for detecting the session status for agent-of-empires/agent-of-empires#1126
brennanb2025 commentedon May 17, 2026
+1 This is a real integration blocker for us at Orca.
For external UIs/orchestrators, the lack of a hook for Codex sessions requesting user input leaves them incorrectly marked as
workingwhile they are actually blocked on the user. As it is now, the state contract is incomplete, as we can't distinguish "agent is actively working" from "agent is idle and waiting for human input."This matters for:
Any TUI prompt that blocks progress should emit a hook event, even if it's observability-only. A
RequestUserInputevent with title/options would be enough for integrations to mark the session as waiting and route attention correctly.khughitt commentedon Aug 3, 2026
A cross-agent terminal status integration encounters this exact observability gap on
codex-cli 0.146.0.It can map
UserPromptSubmitto working,PermissionRequestto needs approval, andStopto done. However, no hook fires whenrequest_user_inputopens, even though Codex’s native terminal pet correctly enters its Waiting / Needs input state. External status renderers therefore continue showing working while Codex is blocked on the user.An observation-only opened/resolved event would be sufficient. Both transitions are important so integrations can enter needs-input and later return to working without inspecting question contents or scraping the transcript.