What variant of Codex are you using?
CLI / TUI
What feature would you like to see?
Add separate configurable editor commands for the two common Ctrl+U line-editing semantics:
kill_line_start: kill from the beginning of the current line to the cursorkill_whole_line: kill the current line regardless of cursor position
The TUI currently binds Ctrl+U to kill_line_start, which matches Bash/Readline. That should remain configurable.
However, zsh's default emacs keymap binds ^U to kill-whole-line, and macOS uses zsh as its default shell. For the common macOS/zsh case, Ctrl+U should clear the current line by default, while Bash/Readline users should be able to restore the existing behavior through [tui.keymap.editor].
The simple approach is probably best:
- Add
kill_whole_line.
- Default
Ctrl+U to kill_whole_line, following zsh/macOS.
- Keep
kill_line_start available as a configurable action for users who prefer Bash/Readline behavior.
This was also the primary papercut I had in mind when I originally started working on configurable keymaps: Ctrl+U is a small shortcut, but it is frequent enough that the wrong line-editing semantic becomes noticeable quickly.
Additional information
Relevant upstream behavior:
This builds on #18593 by @fcoury-oai, which introduced configurable TUI keymaps.
A more user-adaptive version could choose the default from the user's shell configuration. For zsh, this is easy to inspect:
zsh -fc 'bindkey -e; bindkey "^U"'
On a stock zsh setup this reports:
For Bash/Readline, the current binding can be inspected with:
bash -ic 'bind -P | grep -E "^(unix-line-discard|backward-kill-line|kill-whole-line)"'
On a typical Bash/Readline setup this reports:
backward-kill-line can be found on "\C-x\C-?".
kill-whole-line is not bound to any keys
unix-line-discard can be found on "\C-u".
unix-line-discard corresponds to the existing Codex behavior: kill backward from the cursor to the beginning of the current line.
That said, shell probing is probably gold plating. It is more customer-friendly in principle, but it adds startup/runtime complexity and edge cases:
- probes may source user startup files
- probes may emit job-control warnings without a real TTY
- shell configs can be slow or have side effects
$SHELL may not match the terminal/editor behavior the user expects inside Codex- Windows behavior has not been considered here
A simple static default plus explicit configuration is likely easier to implement, document, test, and reason about. The adaptive heuristic can be treated as a future enhancement if maintainers think it is worth the extra complexity.
Existing implementation notes:
- The TUI currently has
editor.kill_line_start and editor.kill_line_end.
Ctrl+U currently defaults to editor.kill_line_start.- The textarea handler maps that action to
kill_to_beginning_of_line().
Relevant local files:
codex-rs/tui/src/keymap.rscodex-rs/tui/src/bottom_pane/textarea.rs
Related issues and PRs:
What variant of Codex are you using?
CLI / TUI
What feature would you like to see?
Add separate configurable editor commands for the two common
Ctrl+Uline-editing semantics:kill_line_start: kill from the beginning of the current line to the cursorkill_whole_line: kill the current line regardless of cursor positionThe TUI currently binds
Ctrl+Utokill_line_start, which matches Bash/Readline. That should remain configurable.However, zsh's default emacs keymap binds
^Utokill-whole-line, and macOS uses zsh as its default shell. For the common macOS/zsh case,Ctrl+Ushould clear the current line by default, while Bash/Readline users should be able to restore the existing behavior through[tui.keymap.editor].The simple approach is probably best:
kill_whole_line.Ctrl+Utokill_whole_line, following zsh/macOS.kill_line_startavailable as a configurable action for users who prefer Bash/Readline behavior.This was also the primary papercut I had in mind when I originally started working on configurable keymaps:
Ctrl+Uis a small shortcut, but it is frequent enough that the wrong line-editing semantic becomes noticeable quickly.Additional information
Relevant upstream behavior:
zsh:
kill-whole-line (^U)means "Kill the current line."https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html
zsh also has
backward-kill-line, meaning "Kill from the beginning of the line to the cursor position."https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html
Bash/Readline:
unix-line-discard (C-u)means "Kill backward from the cursor to the beginning of the current line."https://www.gnu.org/software/bash/manual/html_node/Commands-For-Killing.html
Apple documents zsh as the default shell on macOS:
https://support.apple.com/guide/terminal/change-the-default-shell-trml113/mac
This builds on #18593 by @fcoury-oai, which introduced configurable TUI keymaps.
A more user-adaptive version could choose the default from the user's shell configuration. For zsh, this is easy to inspect:
zsh -fc 'bindkey -e; bindkey "^U"'On a stock zsh setup this reports:
For Bash/Readline, the current binding can be inspected with:
bash -ic 'bind -P | grep -E "^(unix-line-discard|backward-kill-line|kill-whole-line)"'On a typical Bash/Readline setup this reports:
unix-line-discardcorresponds to the existing Codex behavior: kill backward from the cursor to the beginning of the current line.That said, shell probing is probably gold plating. It is more customer-friendly in principle, but it adds startup/runtime complexity and edge cases:
$SHELLmay not match the terminal/editor behavior the user expects inside CodexA simple static default plus explicit configuration is likely easier to implement, document, test, and reason about. The adaptive heuristic can be treated as a future enhancement if maintainers think it is worth the extra complexity.
Existing implementation notes:
editor.kill_line_startandeditor.kill_line_end.Ctrl+Ucurrently defaults toeditor.kill_line_start.kill_to_beginning_of_line().Relevant local files:
codex-rs/tui/src/keymap.rscodex-rs/tui/src/bottom_pane/textarea.rsRelated issues and PRs: