Vim composer mode: support inner-word text objects (`ciw`, `diw`, `yiw`)
Resolved 💬 6 comments Opened May 6, 2026 by lucidash Closed May 27, 2026
What variant of Codex are you using?
CLI / TUI
What feature would you like to see?
Now that Vim composer mode has landed, it would be useful to support common inner-word text objects in the composer:
diw: delete inner wordciw: change inner word and enter insert modeyiw: yank inner word
These are common Vim muscle-memory commands and fill a small gap in the existing composer Vim mode rather than adding a new mode.
Additional information
The existing Vim composer mode supports normal/insert mode and d/y operator flows. Inner-word text objects make those flows feel much closer to expected Vim behavior for prompt editing.
I have a small focused patch with tests that adds these commands in codex-rs/tui/src/bottom_pane/textarea.rs. If this is something maintainers would be open to, I would be happy to open a PR.
Related:
- Follow-up to #18595
- Related to #9184
- Similar behavior was discussed in #3044
6 Comments
If useful, I have a small tested patch here:
https://github.com/openai/codex/compare/main...lucidash:codex:fix/vim-inner-word
this is a issue is actually a great example of how great community driven projects are
sorry for my bad english once again
Pretty much your offer is pending chars
without over complexing thing, like how does vim does it
but vim does right.. its seems like reciepie for a lot of issues
like having keys sync , if keys act in the same specification as vim itself -- if anything can glitch?
If you are typing diw, normal.c hits a line of code where it literally says: "I have a 'd', now I need a motion. Hey getchar.c, give me the next thing?
speaking of there is a need for a more mature behavior? (as per your commit https://github.com/openai/codex/compare/main...lucidash:codex:fix/vim-inner-word)
https://github.com/vim/vim/blob/master/src/normal.c#L182C3-L198C1
https://github.com/vim/vim/blob/master/src/getchar.c
https://github.com/vim/vim/blob/master/src/getchar.c
@Mahkhmood9
Thanks, I think I understand your point. To be honest, this started as a quick
patch because I wanted to use
ciw/diw/yiwmyself right away, so I kept itdeliberately small instead of trying to model Vim's full getchar/typeahead
machinery.
I agree that if this grows beyond a few common text objects, a more general
operator-pending / pending-key state machine would be the cleaner direction.
For this patch, I was mainly trying to fill the immediate gap with tests and
check whether maintainers are open to the behavior.
I just fear it been something that going to cause issue, text insertion is very sensetive , and there is also the TUI aspect , which seems complex.... its very sensetive all of those keystores
I tried your commit it seems to be solid 👍
Here is a new patch: https://github.com/openai/codex/compare/main...lucidash:codex:codex/fix/vim-pending-text-objects
Unrelated by I want to refrence https://github.com/openai/codex/issues/21562
For example VIM is one of those software that works anywhere (yes including a native built for windows, and cmd and powershell) and vim for example is very harden for TUI or whatever
again I actually praise Codex CLI for how stable it is , considering the alternatives (in terms of TUI)