Transcript scroll locks during agent runs; view rubber-bands back to sent message

[arepodotbtc]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release.
• This is one bug, not several bundled together.

Closest existing issue

none found; nearest are merged PRs #72 and #46 (transcript anchoring)

What's broken

While an agent turn is running, the transcript cannot be scrolled: manual scrolling rubber-bands back to the sent message until the entire run (including silent tool activity) finishes.

Steps to reproduce

1. Launch Berd 0.6.2 on macOS
2. Open a chat on the Claude Code (claude-acp) harness, model Claude Fable 5 [1m]; chat had prior history (observed across multiple chats, ~100+ messages in the main one)
3. Send a message that triggers a long agent turn with tool calls
4. While the run indicator is active, scroll down with trackpad or wheel
5. The view snaps back to the top of the sent message on each new content chunk; scrolling past it is impossible until the whole turn completes
   Note: this persists after the reply text looks finished, as long as the session is still running. Verified via berdctl session get showing chat_state "streaming" / is_running true while the reply appeared complete and scrolling was still locked.

What you expected to happen

Manual scroll input cancels auto-follow immediately; auto-follow resumes only if I return to the bottom.

What actually happened

Scroll position is re-anchored to my sent message on every content resize for the entire agent run, including while tools run silently after the reply text appears finished. In agentic chats a single turn can run for minutes, leaving the transcript unscrollable the whole time.

How often does it happen?

Every time — reliably reproducible

Berd version

0.6.2

Operating system

macOS (Apple Silicon)

Model and provider

Claude Fable 5 [1m] via claude-acp (Claude Code harness)

Relevant log output

[2026-08-19][04:07:09][berd_lib::services::diagnostic_log][ERROR] [diagnostic] category=renderer event=window_error app_version=0.6.2 platform=macos columnNumber=0 errorName=Error filename=tauri://localhost/ lineNumber=0 message="ResizeObserver loop completed with undelivered notifications." stack="" windowKind=main
[2026-08-19][04:07:27][... identical ...]
[2026-08-19][04:07:29][... identical ...]
These repeat at exactly the moments the rubber-banding occurs, consistent with scroll anchoring re-firing on every content resize instead of yielding to user scroll.

Screenshots, recordings, or other context

Possibly related: PR #72 and PR #46 both touched auto-follow / row anchoring in VirtualMessageTimeline.tsx; this looks like the inverse case, where the anchor set at send time keeps overriding user scroll while the session is running. Im unable to upload a video of the issue. It keeps saying upload failed. That said, it is easy to reproduce.

[paul-reich]

I experience similar behaviour, but even after the agent run has completed. I cannot scroll to last session message, whether user input or agent response.

Workaround is to submit a new message to be able to view the prior response in full.

[dplusplus1024]

This is driving me crazy too, and @paul-reich's tip about submitting a new message to see the prior response is a useful workaround. I had some agents dig into it. Findings below, with a fix and a regression test for one of the two problems here.

Scope: what follows explains the OP's case (scroll locked during a run). It does not explain @paul-reich's — being unable to reach the last message after the turn completes is a separate code path, covered at the end. Still present on main as of 183542e9.

Root cause (during a run)

handleWheel in src/features/chat/ui/VirtualMessageTimeline.tsx handles three cases, and one is missing:

• Scroll up (deltaY < 0) → detachFromBottomFollow(), which sets userDetached. Correct.
• Scroll down and reach the bottom (deltaY > 0 + isTimelinePinnedToLatest) → re-attaches to follow. Correct.
• Scroll down and stop partway → falls through to handleStreamingUserScrollIntent(), which only calls stopStreamingBottomFollow() and clears sticky. It never sets userDetached.

That third case is exactly what you do when you scroll into the middle of streaming output to read it. Because userDetached stays false:

• shouldPreserveVirtualScrollPosition (userDetached && !isNearBottom) stays false, so preserveScrollPosition never reaches the controller, and
• shouldRestoreProgrammaticFollow (!hasScrollDetachIntent && !userDetachedRef.current && scrollIntent === "following-latest") becomes true once the one-frame wheel-ownership flag expires.

The app still believes you are following, so it puts the viewport back — on every chunk, for as long as the turn runs. That matches the OP's note that it persists while chat_state is streaming even after the reply text looks finished.

Fix

Make the downward case symmetric with the upward one:

if (streamingMessageId) {
  // Scrolling toward the latest output but stopping short of the bottom is
  // still the user taking the viewport: they are reading the live tail, not
  // asking to follow it.
  detachFromBottomFollow();
  return;
}

Scrolling all the way to the bottom still re-attaches, so opt-in follow is unchanged.

Regression test

Two tests in VirtualMessageTimeline.test.tsx covering the ordering of the scroll event relative to the one-frame wheel-ownership expiry. (Two separate it() blocks, not parameterised, and the setups are not quite symmetric: the after-expiry case deliberately omits a priming scroll event that would otherwise legitimately restore follow and mask the bug.)

Setup: substantial history plus a live streaming tail, scrollTop parked at the history/live-tail boundary, browser bottom far below, intent still following-latest. Fire wheel({ deltaY: 120 }), land at an intermediate scrollTop well outside the 180px near-bottom threshold, then grow the stream and re-render the same streaming message id.

Against pristine main: before-expiry passes, after-expiry fails with expected 4700 to be 1200 — the reader's position is discarded and the viewport forced to the bottom. With the fix, both pass.

Full timeline suites 110/110 (VirtualMessageTimeline, .layoutScroll, .search, Gate, MessageTimeline, MessageTimelineScrollContainer, timelineScrollIntent); tsc --noEmit clean.

Ruled out

Recorded so nobody re-derives them:

• Anchoring to the sent message. splitLiveStreamingTail() removes the latest user turn and the streaming rows from virtualRows, so the controller never owns them. A correction can land visually near that boundary, but the anchor is not that row.
• Scroll-intent lifetime. Extending the one-frame ownership flag does not help; syncScrollState() clears it per scroll event anyway.
• geometryChanged forcing the strict path. It covers viewport height, footer height and width scope only — not browserScrollHeight — so ordinary stream growth does not set it.
• Controller bottom collapsing to the history end. getBottomScrollTop() is Math.max(virtualBottom, browserBottom) against the real container scrollHeight, which includes the live tail.

The second problem (@paul-reich's case) — not fixed, not diagnosed

Offered only as a starting point. The live-tail → history handoff at VirtualMessageTimeline.tsx:3846-3900 releases liveTailScrollHeightFloorPx back to 0 and then restores scrollTop against getBottomScrollTop(container). If the completed assistant row's measured height is stale when the floor is released, the virtualised total under-counts and the end of the transcript becomes unreachable — which would explain why sending a new message, forcing a re-render and re-measure, restores access. This is a hypothesis, not a finding; confirming it needs a reproduction against the real renderer rather than code reading.

Relatedly unproven: a transient live-tail shrink could lower the real browser scroll maximum and cause native upward clamping that controller reconciliation then ratifies. liveTailScrollHeightFloorPx is zero while streaming and streamingHeightFloors only protects controller-owned rows, so nothing obviously prevents it — but we could not show such a shrink happens per chunk. Neither would be fixed by the change above.