openai / openai/codex

Support mouse-click selection in CLI command approval prompts

Open
#43,729 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

CLI enhancement sandbox TUI
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What variant of Codex are you using?

Codex CLI (codex-cli 0.153.4)

What feature would you like to see?

Please allow users to select command approval options by clicking their number or label in terminals that support mouse input.

When Codex displays “Would you like to run the following command?”, it presents options such as:

  1. Yes, proceed (y)
  2. Yes, and don't ask again for commands that start with … (p)
  3. No, and tell Codex what to do differently (esc)

In my current workflow, clicking these options does not select them, so I have to use the keyboard to respond. When I am already using the mouse to review a proposed command, switching back to the keyboard for each approval adds friction. In my experience, Claude Code allows mouse-click selection in similar prompts, and I would like a comparable interaction in Codex CLI.

Suggested behavior
  • Allow clicking an option's number or label to select it.
  • Clearly highlight the selected option and make it unambiguous whether a click selects or also confirms it.
  • Preserve existing keyboard navigation and shortcuts.
  • Preserve the distinction between one-time approval, persistent command-prefix approval, and rejection.
  • Support this across macOS and Windows terminals where mouse input is available, while retaining a keyboard fallback.
  • Preserve native terminal text selection and scrolling where possible; an opt-in mode would be acceptable if mouse capture requires a tradeoff.

This request is specifically about the CLI command approval menu, rather than ordinary numbered lists in assistant responses, prompt-editor cursor positioning, or desktop-app approval buttons.

Additional information
Version and platform scope

My confirmed CLI version is codex-cli 0.153.4. I understand this limitation also affects macOS and Windows; this is not a claim that every terminal or OS version has been tested.

Source inspection

Source inspection during preparation of this issue found:

  • In 0.153.4's terminal event mapping, mouse events fall through to _ => None.
  • The approval overlay handles keyboard events and applies the selected list option.
  • The same lack of mouse-event forwarding was present in main when checked on September 8, 2026.
Related work

Existing open and closed issues and PRs were searched; no exact duplicate or implemented fix for clicking command approval options was found in that search.

  • #36439 concerns clicking to reposition the prompt-editor cursor.
  • #14315 concerns cursor movement and was closed as not planned, rather than implemented.
  • #641, #971, and #2686 concern mouse scrolling or mouse-mode behavior, rather than clicking approval options.

This issue was prepared with AI assistance; the reported approval-menu interaction and CLI version were supplied by me.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in codex-rs/tui/src/tui/event_stream.rs at the terminal event mapping, then trace how codex-rs/tui/src/bottom_pane/approval_overlay.rs handles keyboard events and applies the selected option. Determine how mouse events can reach the approval overlay without losing keyboard behavior or terminal selection where possible. Done means clicking an approval option selects it clearly while preserving one-time approval, persistent approval, rejection, and keyboard fallback across supported macOS and Windows terminals.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.