›_ Codex Issues
Codex Issues / #19921

Expose plan-mode-prompt and approval-requested through top-level notify

Open 💬 5 comments Opened Apr 28, 2026 by ryan6416
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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-prompt
  • approval-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

  1. Configure Codex TUI notifications.
  2. In plan mode, prompt Codex to call request_user_input.
  3. Codex emits the plan-mode questionnaire and terminal notification.
  4. The external notify command does not run because the event is not agent-turn-complete.

Related

  • #17252 reported that plan-mode questionnaire notifications did not fire.
  • #17417 fixed that by mapping request_user_input to plan-mode-prompt.
  • This request is separate: expose that now-working event through the top-level external notify primitive.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #19328

Powered by Codex Action

etraut-openai contributor · 4 months ago

The top-level notify will 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 · 4 months ago

@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-prompt
  • approval-requested
  • blocked/error states
  • agent turn complete

Is 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 · 3 months ago

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 · 19 days ago

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 waiting notification kind for questions and permission prompts. In Codex sessions, however, its activity integration currently sees turn boundaries but cannot receive plan-mode-prompt, so a request_user_input prompt can remain in progress without producing either a finished or waiting alert, even when both notification kinds are enabled.

Exposing plan-mode-prompt and approval-requested through the top-level notify command 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.