feat(tui): vim motions in prompt input

[leohenon]

What does this PR do?

Closes#1764
Closes#11111

Adds optional Vim motions to the prompt input. Enable with tui.vim: true or toggle from the menu. Disabled by default.

Supported:

• Mode switching: i I a A o O S, cc, cw, Esc
• Motions: h j k l, w b e, W B E, 0 ^ $
• Deletes: x, dd, dw
• Session navigation: gg/G
• Scrolling: Ctrl+e/y/d/u/f/b
• Enter in normal mode submits

Implementation: Vim state isolated in /vim module. Handler owns mode + pending operator state. Mode resets to insert after submit. Visual mode intentionally excluded.

I saw thdxr's concern in #1764 about partial Vim feeling incomplete. This PR covers only the core motions needed for prompt editing and is intentionally kept small to make review manageable. I have a fuller implementation with yank/paste, visual mode and other motions that I can split into follow-up PRs if this direction looks good or keep it at this core subset as it seems many people are satisfied with a minimal vim mode.

How did you verify your code works?

I use the fuller implementation daily. Reimplemented the core subset for this PR and verified manually (editing, scrolling, session switching, edge cases with pending operators, empty buffers, multiline). Added targeted tests for mode transitions, motions, deletes, pending state, and submit reset.

Not knowing when this will be reviewed - If you would like to use this now with a more complete vim mode, use opencode-vim.

[github-actions]

Hey! Your PR title vim motions in prompt input box doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[Copilot]

Pull request overview

Adds an optional Vim-style keybinding layer for the TUI prompt input (configurable via tui.vim or a settings toggle), including a mode indicator, motion/operator handling, and related documentation/tests.

Changes:

• Introduces a /vim module (state, handler, motions, scroll/jump mapping, indicator) and wires it into the prompt input flow.
• Adds a command-palette setting to toggle Vim input, plus config schema + docs updates.
• Adds a targeted test suite covering mode transitions, motions, operators, scrolling, and jumps.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/web/src/content/docs/tui.mdx	Documents Vim mode and supported keys for the TUI prompt.
packages/web/src/content/docs/config.mdx	Documents tui.vim config flag.
packages/opencode/src/config/config.ts	Adds tui.vim boolean to config schema.
packages/opencode/src/cli/cmd/tui/component/vim/vim-state.ts	New Vim mode/pending state container.
packages/opencode/src/cli/cmd/tui/component/vim/vim-scroll.ts	Maps Ctrl+key combos to scroll actions.
packages/opencode/src/cli/cmd/tui/component/vim/vim-motions.ts	Implements cursor motions + delete/edit primitives on the textarea.
packages/opencode/src/cli/cmd/tui/component/vim/vim-motion-jump.ts	Implements gg/G jump behavior.
packages/opencode/src/cli/cmd/tui/component/vim/vim-indicator.ts	Computes INSERT/NORMAL indicator text.
packages/opencode/src/cli/cmd/tui/component/vim/vim-handler.ts	Key-event interpreter coordinating state + motions + submit/scroll/jump.
packages/opencode/src/cli/cmd/tui/component/vim/index.ts	Provides useVimEnabled() integration with KV + config.
packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx	Integrates Vim handler/state into prompt input, cursor styling, submit behavior, and indicator rendering.
packages/opencode/src/cli/cmd/tui/app.tsx	Adds command-palette toggle to enable/disable Vim input.
packages/opencode/test/cli/tui/vim-motions.test.ts	Adds tests for handler behavior, operators, and scroll mapping.

Comments suppressed due to low confidence (1)

packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:918

• The inline comment says "Don't preventDefault" but the code immediately calls e.preventDefault(). Either update the comment to match the behavior or adjust the behavior if the intent really is to let the textarea handle the event.

 await exit()
// Don't preventDefault - let textarea potentially handle the event
e.preventDefault()
return

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

wordEnd() currently increments pos before checking whether the cursor is already on a word character. This makes e/E behave incorrectly for 1-character words or when the cursor is on the last character of a word followed by whitespace (e.g., in "a b", e from a will jump to b, and in "a" it can return text.length, which then breaks normal-mode assumptions like l clamping). Consider rewriting wordEnd to first find the end of the current word when on a word char, and ensure it never returns an offset past the last character when used for normal-mode motions; add a regression test for the 1-character word case.

Suggested change

	letpos=offset
	if(pos<text.length)pos++
	while(pos<text.length&&!match(text[pos]))pos++
	while(pos<text.length&&match(text[pos]))pos++
	if(pos>offset+1)pos--
	// If the buffer is empty, stay at 0.
	if(text.length===0)return0
	// Clamp starting position to the last valid character index.
	letpos=offset
	if(pos>=text.length)pos=text.length-1
	// If we're on a word character, move to the end of the *current* word.
	if(match(text[pos])){
	while(pos+1<text.length&&match(text[pos+1]))pos++
	returnpos
	}
	// Otherwise, skip forward to the start of the next word (if any)...
	while(pos<text.length&&!match(text[pos]))pos++
	if(pos>=text.length)returntext.length-1
	// ...then move to the end of that word.
	while(pos+1<text.length&&match(text[pos+1]))pos++

[leohenon]

fixed

[Copilot]

createVimState requires an active accessor in its input but never reads it. Either remove active from the API (to avoid misleading callers) or use it to reset mode/pending when the prompt becomes inactive (e.g., hidden/disabled), since callers are already computing that signal.

[leohenon]

fixed

[broskees]

This would be so good.

[kaich]

Good, This is exactly what I wanted.

[s-yakubovskiy]

Waiting for this as well <3

[Alimedhat000]

Exactly what i wanted

[broskees]

This is big!

[hamidzr]

thanks for the work, this is great and I need it! Not knowing how long it'll take the team to get to merging this I put up a branch on my fork that will track the latest stable release + this + some additions I had around vim motion + a simple install script. I'll be using it and I thought I'd share in case you also can't wait to use it!

[ppiwko]

@leohenon, could you please rebase this on the latest OpenCode version? Alternatively, would you consider releasing your own Vim-based version of OpenCode? I’m currently using your fork as my primary coding agent, and it’s been great! 👍

[leohenon]

@leohenon, could you please rebase this on the latest OpenCode version? Alternatively, would you consider releasing your own Vim-based version of OpenCode? I’m currently using your fork as my primary coding agent, and it’s been great! 👍

Released a vim build that tracks upstream - ocv.

[claytonweaver]

Get this merged!!!

[leohenon]

Update: I ended up building the plugin opencode-vim-plugin:

 opencode plugin @leohenon/opencode-vim-plugin --global

It covers everything in this PR and more.

With the plugin available I'm closing this, it covers everything here without core changes. opencode-vim remains for what plugins can't reach yet.

[augustocdias]

@leohenon what your version has that the plugin doesn't? I'm considering if I should use the plugin or your fork

[leohenon]

@augustocdias The fork adds copy mode, including subagent and tool navigation. The plugin has essentially everything else for prompt editing, apart from a few configuration options that may be added later. If you only need vim prompt editing, then the plugin is sufficient.

Discussion #183