Repository navigation
Expose plan-mode-prompt and approval-requested through top-level notify #19921
Description
What version of Codex CLI is running?
codex-cli 0.125.0
What platform is your computer?
macOS
What terminal emulator and version are you using?
Ghostty 1.3.0-HEAD+9fa3ab0 and cmux 0.63.2 (79) [179b16ce6]
Summary
Codex now emits native TUI notifications for plan-mode request_user_input prompts via plan-mode-prompt after #17417. That works when terminal notifications are enabled.
However, the top-level notify external command still only supports agent-turn-complete. This means users cannot use the native Codex external notification primitive for the most important "needs response" states: plan-mode questions and approval requests.
Current behavior
This works for terminal-native notifications:
[tui]
notifications = ["plan-mode-prompt", "approval-requested"]
notification_method = "bel" # or "osc9"
notification_condition = "always"This works only for completion:
notify = ["python3", "/path/to/notify.py"]Per the docs, notify currently receives supported events, currently only agent-turn-complete.
Expected behavior
notify should also be able to receive the same high-value TUI notification event types, especially:
plan-mode-promptapproval-requested- any future blocked / needs-response state
This would allow users to implement one external alert command for "never miss needs response" workflows without relying on terminal-specific OSC/BEL behavior or custom transcript monitoring.
Repro / motivation
- Configure Codex TUI notifications.
- In plan mode, prompt Codex to call
request_user_input. - Codex emits the plan-mode questionnaire and terminal notification.
- The external
notifycommand does not run because the event is notagent-turn-complete.
Related
- plan-mode-prompt TUI notification does not fire for plan-mode clarification questions in codex-cli 0.118.0 #17252 reported that plan-mode questionnaire notifications did not fire.
- Emit plan-mode prompt notifications for questionnaires #17417 fixed that by mapping
request_user_inputtoplan-mode-prompt. - This request is separate: expose that now-working event through the top-level external
notifyprimitive.
Activity
github-actions commentedon Apr 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Apr 28, 2026
The top-level
notifywill soon be deprecated in favor of our new hooks implementation, so it's unlikely that we will extend it to cover more cases. I'll leave the feature request open as a reminder that we should have some hook mechanism in place for this.ryan6416 commentedon Apr 28, 2026
@etraut-openai thanks, that makes sense.
What is the recommended hooks-based path for this today or soon?
Specifically, I’m trying to trigger an external command for these “needs response” states:
plan-mode-promptapproval-requestedIs there currently a hook event that fires for
request_user_input/plan-mode-prompt? If not, should this issue track adding a hook event for those TUI notification types?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.
Gouldian commentedon Aug 9, 2026
Adding a concrete downstream integration impact:
I use Codex CLI through MulmoTerminal 4.7.4 on macOS (Codex CLI 0.147.0-alpha.6.5). MulmoTerminal can notify on completed turns and has a separate
waitingnotification kind for questions and permission prompts. In Codex sessions, however, its activity integration currently sees turn boundaries but cannot receiveplan-mode-prompt, so arequest_user_inputprompt can remain in progress without producing either afinishedorwaitingalert, even when both notification kinds are enabled.Exposing
plan-mode-promptandapproval-requestedthrough the top-levelnotifycommand would give terminal managers a supported, event-driven integration surface instead of requiring transcript polling. This matters especially for parallel-session supervisors, where an unnoticed input prompt can leave one session stalled indefinitely.