Prompt textarea does not support Shift+Arrow text selection

This issue feels like it should probably be interpreted as the broader baseline selection/editing parity gap in the composer, not only plain Shift+Arrow.

The concrete set that feels missing:

• Shift+Left/Right to extend/shrink selection by character
• word-jump selection (Ctrl+Shift+Left/Right on Win/Linux, platform-appropriate equivalent on macOS)
• Ctrl+X / cut on the selected range

Once selection exists, word-wise selection really wants to share the same boundary logic as cursor word navigation, so this also seems related to #12339.

And at the broader control-surface level, this is another reason #3049 matters: these baseline editing keys should not stay hardcoded forever if Codex wants serious TUI/editor parity.

I inspected the current TUI composer implementation and this looks like missing functionality rather than a one-off regression.

Current state on main:

• TextArea tracks text, cursor_pos, placeholder elements, wrap state, and a single-entry kill buffer, but no selection anchor/range.
• key handling covers cursor movement, word movement, delete, kill/yank, Home/End, Up/Down, etc., but there is no selection-aware path for Shift+Arrow.
• because the model only has a single cursor today, there is no way for Backspace / Delete / typed input to operate on a highlighted range.

A minimal first patch that seems tractable and reviewable would be:

• add selection state to the composer TextArea
• support Shift+Left/Right/Up/Down and Shift+Home/End
• make Backspace / Delete remove the active selection when present
• make normal typing replace the active selection
• add focused tests around selection extension, collapse rules, and replacement/deletion behavior

I’m intentionally not bundling mouse selection or transcript-wide copy behavior into this, since those look like separate design problems.

If this scope aligns with maintainer intent, I can prepare a patch on that basis.

I implemented the first scoped slice for this on my fork and pushed it to branch composer-shift-selection.

Current scope:

• Shift+Left / Shift+Right selection in the composer textarea
• Shift+Up / Shift+Down selection across visual lines
• Shift+Home / Shift+End selection to line boundaries
• Backspace / Delete remove the active selection
• typing replaces the active selection
• focused textarea tests and composer docs updated for the new behavior

I kept this intentionally limited to keyboard selection/editing in the prompt textarea and did not bundle mouse-selection or transcript-wide copy behavior into the same change.

If that scope aligns with maintainer intent, I can open a PR from the branch.

Additionally in any text input in Windows I often use combinations like

• Shift+Left/Right to select text
• Ctrl+Shift+Left/Right to select text quickly by word
• Ctrl+Backspace to delete word to the left of the caret. Currently Alt+Backspace works instead which if frustrating.
• Ctrl+Del to delete word to the right of the caret. Also, Alt+Del works instead.

There is actually no way to select and quickly edit text using keyboard (tested only in Windows).

I can reproduce the same class of issue with keyboard selection in the Codex CLI composer.

Environment:

• Codex CLI 0.128.0
• Windows
• Reproducible in a regular PowerShell terminal session

Reproduction:

1. Start Codex CLI.
2. Type a multi-line prompt in the composer.
3. Place the caret in the middle or at the end of a line.
4. Press Shift+Home, Shift+End, or Shift+Arrow.

Expected:

The editable range inside the composer should become selected.

Then:

• typing should replace the active selection;
• Backspace/Delete should remove the active selection;
• line-oriented selection should work consistently with character/word-oriented selection.

Actual:

The caret moves or no selection-like behavior happens, but no editable selection range is created/highlighted inside the prompt textarea.

Important distinction:

This is not terminal screen/scrollback selection for copying rendered output. I agree that terminal screen selection is normally handled by the terminal emulator.

This request is about editor selection inside the Codex composer input buffer before submitting the prompt.

That behavior requires application/editor state: a selection anchor/range, selection-aware movement actions, rendering of the selected range, and insert/delete behavior that operates on the active selection.

Related issue: #20645

Bumping this.

This feels like pretty important functionality despite how many upvotes this issue gets, unless someone has figured out an elegant workaround...