Add notification support for plan mode questions

Resolved 💬 2 comments Opened Feb 8, 2026 by sqdshguy Closed Jul 21, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Darwin 25.2.0 arm64 arm (macOS 26.2, build 25C56)

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.0-main+6c0e02d11 (channel: tip)

What issue are you seeing?

When Codex asks for request_user_input while I am unfocused, I do not get a desktop notification.
The session then waits for my answer and can appear stalled with no alert.

I have seen this in Codex CLI TUI, and I have noticed similar behavior in Codex app.
I am not sure if this is intentional, so I wanted to confirm and report it.

In codex-rs/tui/src/chatwidget.rs:

  • self.notify(...) is called for:
  • turn completion (AgentTurnComplete)
  • exec approval (ExecApprovalRequested)
  • edit approval (EditApprovalRequested)
  • MCP elicitation (ElicitationRequested)
  • handle_request_user_input_now(...) does not call self.notify(...)

In codex-rs/core/src/codex.rs:

  • request_user_input(...) sends EventMsg::RequestUserInput(...)
  • then waits on rx_response.await

So the turn remains in progress while waiting for user input, and turn complete notification has not happened yet.

What steps can reproduce the bug?

  1. Start Codex CLI TUI in a mode where request_user_input can be triggered.
  2. Start an agent turn that reaches request_user_input.
  3. Move focus away from the terminal.
  4. Observe that no desktop notification is emitted for the user input request.
  5. Return to terminal and see the turn waiting for user response.

What is the expected behavior?

When request_user_input is emitted and the terminal or app is unfocused, a notification should fire, similar to other attention requiring events.

Additional information

Suggested fix direction:

  • Add a notification path for request_user_input in TUI.
  • Possibly map it to existing approval-requested notification type, or add a dedicated type.
  • If current behavior is intentional, document it explicitly so users know what to expect across CLI and app.

Context:

  • Repo: openai/codex
  • Area: codex-rs/tui and codex-rs/core
  • Observed on latest main as of 2026-02-08

View original on GitHub ↗

2 Comments

alexcstark · 4 months ago

+1 — Also on Ghostty + macOS. I have Claude Code's Stop hook wired to send an OSC 777 desktop notification when it finishes a turn, which works great. Would love parity in Codex CLI for request_user_input so I get the same "needs attention" notification across both tools.

The fix path identified in the issue description (adding a self.notify(...) call in handle_request_user_input_now) seems straightforward.

etraut-openai contributor · 1 month ago

Merged PR #17417 maps request_user_input questionnaires to the plan-mode-prompt notification.