Skip to content

Add notification support for plan mode questions #11097

Closed

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

Activity

  1. added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal display
    on Feb 8, 2026
  2. changed the title [-]TUI does not notify on request_user_input, so unfocused sessions can silently block[/-] [+]Add notification support for plan mode questions[/+] on Feb 8, 2026
  3. added
    enhancementNew feature or request
    and removed
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    on Feb 8, 2026
  4. alexcstark commented on Apr 6, 2026

    @alexcstark

    +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.

  5. etraut-openai commented on Jul 21, 2026

    @etraut-openai
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions