fix(opencode): restore Home/End prompt navigation in TUI

[AnttiJalomaki]

Issue for this PR

Closes #14899

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

In the TUI, Home and End keys were mistakenly assigned to session navigation, so pressing them in the prompt jumped to the first or last message instead of moving within the text being edited. Corrected Home and End keys to work the normal defacto habit, like it works in normal text editor softwares everywhere else in the world.

Session jump behavior is still available on Ctrl+G and Ctrl+Home for the first message, and on Ctrl+Alt+G and Ctrl+End for the last message. I also updated the TUI hint text so it matches the correct normal behaviour.

How did you verify your code works?

I tested the local TUI in Fedora KDE Konsole with bun run dev and confirmed that Home and End move the prompt caret normally, while Ctrl+Home and Ctrl+End still jump through the conversation. I also checked the browser client in Chrome, and I ran bun typecheck in packages/opencode.

Screenshots / recordings

None.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR
• This PR was authored manually and follows standard English conventions for capitalization, punctuation, and readability.

[github-actions]

Hey! Your PR title Fix: Restore Home/End prompt navigation in TUI 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]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[ariane-emory]

Whoah, sounds undesirable to me! I rely heavily upon these keys navigating the session and use the existing control+A and control+E keys for navigating the prompt.

[AnttiJalomaki]

E2E failure on Windows (session model restore across workspaces) is a pre-existing flaky test — the dropdown select item gets detached mid-click due to animation timing. Our changes don't touch any of the affected app/E2E code. Linux E2E passes clean.

Attached is video recording of Home, End, Shift+Home, Shift+End, Ctrl+Home, Ctrl+End, Pg Up, and Pg Down tests locally.
Screencast_20260325_191919.webm

[AnttiJalomaki]

Whoah, sounds undesirable to me! I rely heavily upon these keys navigating the session and use the existing control+A and control+E keys for navigating the prompt.

Current issue

The welcome screen (input field centered) already uses standard Home/End behavior for line navigation, but the main session view (input field at bottom) uses Home/End to jump through conversation history instead. This PR synchronizes both to use
the welcome screen's behavior.

Why this should be the default

Home/End for line navigation is the universal standard across:

• CLI colleagues: Claude Code, Codex CLI, Gemini CLI
• Text editors: VS Code, Vim, Emacs, Nano, Sublime Text
• Office suites: MS Word, LibreOffice Writer, Google Docs
• Terminals: bash, zsh, Windows Terminal
• Browsers: Chrome, Firefox and text fields

Users expect Home/End to move the cursor within the current line. Using these keys for conversation navigation breaks muscle memory from every other text input they use.
That is the reason why I wrote this PR, so that OpenCode would be more accessible and more "The Default Keybindings" -feeling to new users.

Keybinding overrides

OpenCode already supports user-configurable keybindings, so both preferences are covered regardless of which default is chosen.

If this PR is merged, users who prefer the current behavior (Home/End for conversation navigation) can restore it:

~/.config/opencode/tui.json
{
"keybinds": {
"messages_first": "ctrl+g,home",
"messages_last": "ctrl+alt+g,end",
"input_line_home": "ctrl+a",
"input_line_end": "ctrl+e",
"input_buffer_home": "none",
"input_buffer_end": "none"
}
}

Without this PR, users who want standard Home/End behavior can already apply this override today:

{
"keybinds": {
"messages_first": "ctrl+g,ctrl+home",
"messages_last": "ctrl+alt+g,ctrl+end",
"input_line_home": "ctrl+a,home",
"input_line_end": "ctrl+e,end",
"input_buffer_home": "ctrl+home",
"input_buffer_end": "ctrl+end"
}
}

The question is which default serves most users best out of the box. Given the universal convention, this PR aligns the defaults with what new users already expect.

[crowne]

This seems like a sensible default to me, it is a very normal idiom and is widely implemented in many editors for the home and end buttons to move the cursor to the front and end of the current line being edited.
Furthermore the idiom extends to using the ctrl+home and ctrl+end key chords to move the cursor to the beginning and end of the document or page.
And the idiom extends further by adding the shift button to the chord to select the corresponding text.
Many users would expect this to be default behavior, and I can actually perform these actions right here in this github textbox.
In this textbox context ctrl+a selects all text and ctrl+e quotes the selection in grave accent characters

[AnttiJalomaki]

Updated: Home/End keybindings now match VS Code conventions

I updated the bindings commit to match closer VS Code. VS Code holds ~76% developer market share (Stack Overflow 2025), making its keybinding conventions the de facto standard.

Key	Action
Home	Line start
End	Line end
Shift+Home	Select to line start
Shift+End	Select to line end
Ctrl+Home	Buffer start
Ctrl+End	Buffer end
Ctrl+Shift+Home	Select to buffer start
Ctrl+Shift+End	Select to buffer end

If this commit is merged, users who prefer the previous behavior (Home/End for buffer start/end, Shift+Home/End for select-to-buffer) can restore it:

~/.config/opencode/tui.json

{
  "keybinds": {
    "input_line_home": "ctrl+a",
    "input_line_end": "ctrl+e",
    "input_select_line_home": "ctrl+shift+a",
    "input_select_line_end": "ctrl+shift+e",
    "input_buffer_home": "home",
    "input_buffer_end": "end",
    "input_select_buffer_home": "shift+home",
    "input_select_buffer_end": "shift+end"
  }
}

Without this commit, users who want the VS Code–style Home/End behavior today can apply this override:

{
  "keybinds": {
    "input_line_home": "ctrl+a,home",
    "input_line_end": "ctrl+e,end",
    "input_select_line_home": "ctrl+shift+a,shift+home",
    "input_select_line_end": "ctrl+shift+e,shift+end",
    "input_buffer_home": "ctrl+home",
    "input_buffer_end": "ctrl+end",
    "input_select_buffer_home": "ctrl+shift+home",
    "input_select_buffer_end": "ctrl+shift+end"
  }
}

[FichteFoll]

I was about to mention the line vs buffer discrepancy with the current default bindings for home and end on the initial prompt screen (and also in the session view), but it seems you figured that out on your own already. 👍

I'm not sure about the current behavior with input_line_{home,end} where using this binding on the beginning or the end of the line respecticely causes the previous line to be selected. This seems unprecedented to me? But that is probably a separate issue to discuss.

[FichteFoll]

Another berhavior that I understand but find annoying nonetheless is that using input_line_home goes to the technical start of the line as in "the position after a line break", not the physical beginning of the currently rendered line that was subject to line wrapping. The behavior I expected here is the one used in browser input fields (like this one here on GitHub) or inside Sublime Text. In ST, pressing the same key again while on the visual beginning of a wrappe line then navigates to the technical beginning of the line.

That, too, may be out of scope for this change, however.

[ariane-emory]

@FichteFoll Yes, both out of scope and IMO undesirable.

[ariane-emory]

@AnttiJalomaki This actually does not align with the behaviour of the keys in Emacs at all, where home / end go to the start/end of the entire buffer and C-a / C-e go to the start/end of the (possibly visual) line. I remain not in favour of this inconsistency-creating change in the key bindings' behaviour.

[crowne]

@ariane-emory Emacs was most popular in 1985, today it's VS Code.
When you press home while typing a response here in the github comments, notice how the the entire page doesn't scroll to the top.

[AnttiJalomaki]

Per Stack Overflow Developer Survey 2025, three keymap families dominate developer muscle memory: VS Code-family ~76%, Vim ~38%, and Emacs ~4%. A keybinding theme switcher (similar to Claude Code's) covering these three would match ~95% of developers. JetBrains/IntelliJ keymap (~27% usage) would be the most defensible 4th option.

I am not here trying to undermine your keybinding preferences @ariane-emory, but to cater to a wider userbase with a simple mechanism rather than picking one default that locks out the others. A theme switcher keeps Emacs bindings as-is, with no regression for current users. It would give VS Code and Vim bindings users a path in without forking config.

My proposal would grow muscle memory catering from ~4% to ~95%.

I could have a go at the implementation if people feel it would be reasonable.