fix(tui): prune messages on prompt submit instead of during streaming

[malventano]

Update May 27, 2026: The upstream sticky-scroll fix referenced below was merged as opentui PR #1088 on May 26 and included in opentui 0.2.16 (released in v1.15.11). This PR handles message pruning mid-stream; the upstream fix handles scroll behavior during content growth. Both are needed for full stability when scrolled up during long sessions. Rebuilt with opentui 0.2.16/1.15.11 and reconfirmed this PR corrects the jumping issue alongside opentui main.

I've been on a quest to fix the scrollback not staying in place while output and tool calls are happening below. I have a PR against opentui PR #1088 that addresses the core sticky-scroll reset in recalculateBarProps, but it only fully corrects the issue so long as the session has fewer than 100 messages. Before that PR, when scrolled up while streaming output the pane would continue to scroll as lines were added to the bottom. With that PR the pane stays put, but once the session reaches 100 or more messages, while scrolled up, the pane will once again start jumping as older sections are pruned to maintain the 100-message limit.

After trying a few dozen ways to work around pruning while new tool blocks are being added below (including renderable-level scroll compensation tracking anchor child positions, which proved unreliable due to timing between Solid effects, Yoga layout, and \_translateY propagation, and a scrollHeight delta approach that failed because scrollHeight changes from content below mask the shrink from above), I got tired of fighting with workarounds and compounded assumptions. Compensating for messages pruned from the top while new content is added below is chasing a moving target.

This fix delays pruning until the user enters the next prompt. Messages are allowed to grow beyond 100 during the response, but are batch-pruned back to 100 when the next prompt is submitted. Since the user is likely at the bottom when hitting Enter (though not guaranteed), there's minimal risk of scrolling disruption. Opening other sessions still only loads the last 100 messages, so no memory concerns there, and I don't expect so much scrollbox growth during a single reply that would cause an issue.

Issue for this PR

Closes #7648
Addresses #7659

Type of change

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

What does this PR do?

• Removes continuous one-by-one message pruning from message.updated event handler in sync.tsx
• Adds prune() method to session store that batch-prunes to 100 messages and cleans up associated parts
• Calls prune() in prompt submitInner() before sending the user message

How did you verify your code works?

Tested on local build with sequential file edits over streaming output, combined with opentui PR #1088 applied. Without that PR the pane would still scroll up during streaming, just not as quickly. Both fixes are needed for the pane to stay completely put while scrolled up. With both applied, scrolling up during a long streaming session shows no viewport jumps. Without this PR, jumps occur as messages are pruned mid-stream.

Screenshots / recordings

N/A -- terminal behavior

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

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

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

[Lauri-Nomme]

could this be resurrected? unexpected scrolling bug is still present in latest opencode

[malventano]

could this be resurrected? unexpected scrolling bug is still present in latest opencode

Yup, this bug is absolutely still present, and this PR corrects the issue. It is also an extremely annoying issue for those who trip over it (>100 messages in the session and user scrolls up while model outputs). Fighting the scroll just to keep the viewport on the same paragraph is a bad experience to say the least. Several other PR's connected with this one have been accepted, but this PR is the one that makes the fix 'complete'.

[malventano]

@kommander this is related to anomalyco/opentui#1088 which was merged a while back. Can you please resurrect this issue (and possibly help merge it) so folks can have their scrollback behave properly?