Skip to content

Add notification support for plan mode questions #11097

@sqdshguy

Description

@sqdshguy

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayenhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions