Skip to content

[FEATURE]: open a session at the start of the last message instead of scrolled to the bottom #54572

Open

Description

@Y15BeTa

Problem

Every time a session is opened or switched to, the transcript is scrolled to the very bottom. When the last message is long — a detailed answer, a plan, a walkthrough — the reader has to scroll back roughly a full screen just to start reading the newest message.

I would like a session to open positioned at the start of the last message instead of the end of it.

Why the existing commands don't cover it

The only message-navigation commands are:

Command Description (source string)
message.previous "Go to the previous user message"
message.next "Go to the next user message"

Both are scoped to user messages, so from the bottom they land on the second-to-last item (the user's own prompt) and cannot reach the start of the last message. There is no command for "jump to the last message" or "jump to the start of the current message".

There is also no setting for the initial scroll position — the session.* settings (sidebar, scrollbar, thinking, grouping, image_preview, tps, markdown, new_location, permissions) have no scroll-related key — and the app manages scrolling itself (window.history.scrollRestoration = "manual", with #message-<id> used only for permalinks).

Possible approaches

  1. When opening a session, scroll the last message to the top of the viewport (only when it is taller than the viewport).
  2. Persist the last read scroll position per session and restore it.
  3. Add a command such as message.last.start ("jump to the last message") so users can bind it themselves — useful even if the default stays as-is.

Environment

  • macOS 26.6, OpenCode Desktop 2.0.26

Workarounds today

  • Cmd+F (session search) to jump to a known point.
  • message.previous gets you just above the last message, then scroll down a little.
  • session.compact on very long sessions.

Activity

  1. opencode-agent commented on Oct 11, 2026

    @opencode-agent
    Contributor

    Thanks for the detailed write-up! To restate the request: when you open or switch to a session in the desktop app, it should open at the start of the last message, at least when that message is taller than the window, instead of at the very bottom. Alternatives would be restoring each session's last reading position, or adding a bindable "jump to start of last message" command. I checked, and message.previous/message.next really do only move between user messages, and no setting controls where a session opens.

    Maintainers will consider this. Related issues and PRs:

    This can't be done as a plugin today, because plugins can't control the app's timeline scrolling or add app commands.

  2. Dante-dan commented on Oct 12, 2026

    @Dante-dan
    Contributor

    I propose a narrow first step: when opening or switching to a completed session, align the latest assistant response to the top of the transcript viewport only if that response is taller than the viewport. Short responses would keep the existing bottom placement.

    The current session-change effect calls scrollToEnd() in timeline/interaction.ts, and timeline/virtualizer.tsx also initializes/follows at the end while pinned. The change would need to coordinate those paths so initial measurement cannot immediately override the selected position.

    Proposed acceptance boundaries:

    • Apply once after the target response is loaded and measured; do not override scrolling the reader has already started.
    • Preserve explicit message/hash navigation and bottom-follow behavior in running sessions, including when streaming finishes. The latter is the separate scope of [FEATURE]: Auto-scroll to top of new assistant response instead of bottom #40870.
    • Keep short responses and sessions whose latest message is a user message at their current initial position.
    • Verify initial open, switching away/back, delayed layout, and viewport resize, with a long response and a short-response control.

    This deliberately starts with assistant responses. Per-session reading-position restoration remains a separate option, and #54088's turn navigator provides explicit turn navigation rather than this initial-placement behavior.

    Could a maintainer approve this scope, or indicate whether you prefer restoring the previous reading position instead? I can take the approved approach forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions