Repository navigation
[FEATURE]: Keyboard jump-to-message list in the desktop/web session view #55672
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Scope note: the open requests in this area are all about a mouse-driven rail. #52500 and PR #54088 add a left-edge MessageNav rail with click-to-jump, #49147 / #47993 / #48292 ask for the same navigation and its previews, closed: #32165 (TUI sidebar), #42210, #48979, #42523. None of them asks for a keyboard-invoked jump list, which is what this issue is about — it is the same data with a different entry point, and it composes with those issues instead of competing with them.
Describe the enhancement you want to request
The TUI already has a keyboard-first way to move around a long session: session.timeline (leader Ctrl+X then G, packages/tui/src/routes/session/dialog-timeline.tsx) opens a filterable dialog of the session's messages and Enter jumps to the selection.
The desktop app and opencode web have no equivalent. What exists today in the session view:
message.previous / message.next (mod+alt+[ / mod+alt+]) — one message at a time, which is useless in a 60-turn session, and currently unreliable on long turns (#49747).
session.search (mod+f) — requires already knowing what text the target message contains, so it does not help for "what did I ask three turns ago".
Command palette (mod+k / mod+shift+p, DEFAULT_PALETTE_KEYBIND in packages/app/src/shell/commands/command.tsx) — searches commands, files and sessions, but not messages inside the current session.
Proposal
Register a session-view command (working name session.jump_to_message) that opens a filterable dialog of the session's user messages: one entry per turn, titled with the existing message summary or a truncated first line, current turn preselected, Enter scrolls the timeline to that message and highlights it.
Because it is a registered command it shows up in the command palette and can be rebound in Settings -> Keybindings like every other command. A default such as mod+g would mirror the TUI leader binding well, but I am happy to defer to maintainers on the key.
Reuse what is already there instead of adding new UI primitives: visibleUserMessages() for the entry list, the pendingMessage / use-session-hash-scroll.ts reveal mechanism for the jump, and the preview data already behind MessageNav (packages/session-ui/src/components/message-nav.tsx, today only used by the enterprise share page). Jumping into not-yet-loaded virtualized history needs the same handling that PR #54088 introduces.
Benefits: keyboard-only navigation of long sessions with no permanent chrome, feature parity with the TUI, and one shared source of truth for turn entries that a future rail can reuse.
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed proposal and for scoping it so carefully against the rail work!
To restate it: you're asking for a keyboard-opened, filterable jump-to-message dialog in the desktop app and
opencode web, like the TUI'ssession.timeline. It would list one entry per user turn with the current turn preselected, Enter would scroll to that message, and as a registered command it would show up in the command palette and be rebindable in Settings → Keybindings.Maintainers will consider it. Related issues:
MessageNavrail with click-to-jump. Same data, mouse entry point; the PR's virtualized-history loading would be needed here tooMessageNavhover previewsmessage.previous/message.nextunreliable on long turnsThis can't be built as a plugin today. Plugins don't have an API for adding commands or dialogs to the desktop/web app.
Nine-Days06 commentedon Oct 20, 2026
Adding a real-world data point from the 1.19.3 desktop build (Windows, latest release as of 2026-10-16).
The pain is exactly as described:
mod+alt+[/mod+alt+]is the only way to move around, one message at a time. On sessions that run 60+ turns this is unusable, and I've also seen it land on the wrong message on long tool-heavy turns (#49747).Two things I verified directly in the shipped
app.asarthat may help scope the work:1. The jump mechanism already exists in 1.19.3.
useSessionHashScroll/messageIdFromHash/scrollToMessage/applyHashare all present in the renderer bundle, and the router accepts#message-<messageID>. What's missing is any UI that generates that hash. So a jump list could reuse the existing reveal path without new scroll primitives.2. The helpers referenced in the proposal are not in this build.
Grepping the 1.19.3 renderer bundle:
visibleUserMessages,session.search,mod+f,MessageNav/message-nav,session.timeline,jump_to_message— 0 hits for every one of them. So if this ships againstpackages/session-ui/ the v2 app only, users on the current stable desktop shell get nothing.Question for maintainers: is this scoped to the new app, or should the command also be registered in the 1.19.x desktop shell? If the latter,
mod+greads like a good default — it mirrors the TUI'ssession.timeline(leader+g), assuming it's still free in the current command table.Related, same shape of problem: per-message reasoning collapse. #31825 was closed as completed on 2026-10-01, but 1.19.3 still renders reasoning as a plain block with no collapse — the only control is the global
showReasoningSummariestoggle, which forces all-or-nothing.