Add full text selection support to the CLI composer

[2014Alexander]

What variant of Codex are you using?

CLI

What feature would you like to see?

Please add a full text selection model to the Codex CLI composer.

Right now the inline composer supports cursor movement and kill/yank-style editing well enough for short prompts, but it falls short once prompts
become multi-line and need normal text selection behavior.

Examples of expected editor behavior that appear to be missing or inconsistent:

• Shift+Left / Shift+Right
• Shift+Up / Shift+Down
• Shift+Home / Shift+End
• Ctrl+Shift+Left / Ctrl+Shift+Right
• Ctrl+Shift+Home / Ctrl+Shift+End

In particular, selecting to the beginning/end of the current line is important for editing multi-line prompts inline.

Why this matters

The external editor (Ctrl+G) is a useful fallback, but it is much heavier than doing quick inline edits in the composer.

When editing prompts directly in the TUI, the lack of normal selection behavior makes common tasks harder than they should be, for example:

• replacing part of a line
• selecting a whole line segment
• selecting across wrapped or multiple lines
• making small edits without jumping out to the external editor

Expected behavior

The composer should behave more like a normal terminal text editor / textarea:

• cursor movement should have selection-extending equivalents
• typing should replace the active selection
• backspace/delete should remove the active selection
• selection should work consistently for character, word, and line-oriented motions

Additional information

This looks like a feature gap rather than a single broken shortcut.

From the current code structure:

• EditorKeymap exposes movement, deletion, kill, and yank actions, but no select_* actions
• the composer TextArea appears to track text, cursor position, wrapping, elements, and kill buffer state, but not an explicit selection anchor/
  range
• Home / End are wired as movement actions, not selection-extending actions

Relevant files:

• codex-rs/tui/src/keymap.rs
• codex-rs/tui/src/bottom_pane/textarea.rs

A reasonable implementation path would likely be:

1. add selection state to the composer textarea
2. add selection-aware editor actions / keybindings
3. render highlighted selected ranges
4. make insert/delete operations replace an active selection
5. preserve correct behavior with atomic elements and vim mode

[github-actions]

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

• Mouse drag selection + copy in the TUI #19820

Powered by Codex Action

[etraut-openai]

Text selection in a terminal is handled by the terminal itself, not the app running in the terminal. Depending on which terminal emulator you're using, you may find configuration settings to control this.

[2014Alexander]

I think there may be a terminology mismatch here.

I agree that terminal screen/scrollback selection is normally handled by the terminal emulator.

The request in this issue is different: it is about selection inside the editable composer input buffer before submitting a prompt.

Example:

1. Type a multi-line prompt in the Codex CLI composer.
2. Move the caret inside the composer text.
3. Press Shift+Home, Shift+End, or Shift+Arrow.

Expected:

The range inside the editable prompt textarea should become selected. Typing should replace that selected range, and Backspace/Delete should remove it.

Actual:

No editable selection range is created/highlighted.

This cannot be implemented by the terminal emulator alone, because the terminal does not own the Codex composer buffer, cursor position, wrapping, atomic text elements, or insert/delete behavior.

So the request is not about copying rendered terminal output from scrollback. It is about standard editor selection semantics inside the Codex CLI composer.

[etraut-openai]

Thanks for the clarification. Reopening.