[Bug]: Chat snaps back to the bottom while a turn is running when scrolled up (regression of #4668 in 0.1.0)#20366

We can't reproduce this from the code yet, so we need a few details before we accept it as a regression of #4668.

This isn't #17056. That one only happens when the pointer is over an inline html_render frame. We also looked at #19334 (live reasoning stays scrolled to the newest text), which shipped in 0.1.0. It only scrolls the reasoning box itself, and it doesn't move the main timeline. The live-follow escape added in #5566 (wheel, touch, scrollbar drag, PageUp/Home/ArrowUp) is still on main.

Can you tell us:

1. How you scroll when it snaps back: trackpad or mouse wheel, dragging the scrollbar, or the keyboard?
2. Was a thinking/reasoning section or tool-call row open and streaming at the time? Which provider and model were you using?
3. Does it still happen on the latest nightly (0.1.1-nightly.20261016.3218 or newer)? A short screen recording would help a lot.

If we don't hear back in 14 days, this will close automatically. You can comment at any time to reopen it.

It's intermittent. It doesn't happen every time I scroll up during a running turn, but it has happened a handful of times since I updated to 0.1.0.

1. Magic Trackpad, two-finger scroll, on the desktop app. No mouse is attached.
2. I didn't notice whether a reasoning section or tool-call row was open at the time. I believe it was Claude Agent with Opus 5.5, but I don't remember which thread it was in.
3. I'm not on the nightly, so I can't say yet. Next time it happens I'll try to capture a recording.

I too have found this issue in v0.1.0 (81493efb71e8)

When scrolling on MacBook Air M2 trackpad, the viewport constantly snaps back to the bottom, making real-time reading of earlier data impossible.

The only reliable fix is to click on or arrow-navigate the chat window via the left-side thread selector (horizontal dashes that represent interaction timestamps inside the chat window).

Clicking there allows the viewport to recognize scroll, and "Scroll to end" appears at the bottom as a button, confirming you've disengaged auto-scroll. Normal scroll actions do not disengage auto-scroll, and "Scroll to end" never appears.

I'm using a Mouse with a normal scroll wheel on a M2 Pro MacMini with MacOS latest and got this, too. Weirdly enough, I encountered it all the time 2 days ago and not at all today, now that I'm trying to reproduce it. I'll try to record if/when it happens the next time, for now it seems good.

It happened again in this command chain. Every time one of the commands triggered or finished (not sure, it was very quick), the view auto-scrolled down, even if I scrolled up in between. Screenshot cropped for privacy reasons.

Same here on Windows, desktop app 0.1.0 (stable), connected to t3 serve v0.1.0. Adding my data point since the reports so far are all macOS.

Frequent rather than intermittent for me: during a long running turn, nearly every tool call that starts or finishes pulls the viewport back to the bottom, even after scrolling up over plain chat text. Reading earlier messages mid-turn is effectively impossible until the turn finishes.

Triage answers:

1. Trackpad, two-finger scroll, Windows laptop, no mouse attached.
2. Tool-call rows were streaming at the time; running the Claude Code agent.
3. Haven't tried the nightly yet. The timing is consistent enough (fires on tool-call start/finish boundaries) that a recording should be easy to capture if it would help.

It does seem to be intermittent. It just happened to me on macos using the scroll wheel on a bluetooth mouse, t3 version: Version 0.1.1-nightly.20261019.3360 (1451e7cb2303)

Still reproduces on the latest nightly: 0.1.2-nightly.20261021.3473, macOS 26.6.2, T3 Code (Nightly) desktop app.

• Scroll method: built-in MacBook trackpad, two-finger scroll. No external mouse.
• Behavior: while a turn is running, the timeline snaps back to the bottom even after scrolling up over ordinary chat text — cannot read earlier messages until the turn finishes.

Happy to capture a recording next time it happens if that helps.

This was generated by AI during triage.

Adding a reproducible late-history-load / missing-listener path on the source matching 0.1.2-nightly.20261021.3499. This establishes one mechanism that leaves live-follow enabled after upward navigation; it does not establish that every report here has the same cause.

Before submitting

• Searched existing reports; adding evidence here instead of creating a duplicate.
• Reproduced the failure with neutral data and ran a distinguishing control.

Area

apps/web

Steps to reproduce

1. Run an isolated dev checkout at b5a226e, using vp run dev --no-seed. Prepare a long neutral transcript.
2. Emulate slow history delivery by adding yield* Effect.sleep("3 seconds"); at the start of the server's threadBoundedSnapshot handler. The real snapshot payload is unchanged.
3. Clear only the isolated dev origin's cached thread snapshots, then reload the transcript and wait for history.
4. Focus the main timeline and press native Page Up. For automation, the existing .messages-timeline-scroll element was given tabIndex = 0 and focused with preventScroll:true; no scrollTop assignment was used.
5. Resize the viewport from 1240×800 to 1240×780.

Expected behavior

Upward navigation disables follow, shows “Scroll to end,” and preserves the reader's position across the resize.

Actual behavior

The button stays absent and the resize returns the timeline to its end.

Both trials used the same transcript, 3-second delay, keyboard input, content height of 22,197 px, and viewport change. The delayed-load baseline snapped in three trials; the extended-retry control held in one.

Verified mechanism: the follow effect exhausts its finite animation-frame retries before a scroll node exists. Later list availability does not rerun that effect. Its wheel/touch/pointer/key/upward-scroll listeners therefore remain unattached. The empty/loading branch can render without a list. The at-end callback then suppresses the away-from-end transition while the live-follow generation is still current.

Extending the retry window was a diagnostic experiment, not a proposed durable fix. Attachment should track the actual scroll-node lifecycle.

Impact

Major degradation or frequent failure when this loading condition occurs.

Version or commit

Dev checkout b5a226e, matching the installed nightly 0.1.2-nightly.20261021.3499 source. This was not a test of the packaged server bundle.

Environment

Windows x64; T3 Code native Browser panel; Chromium 152.0.7977.167 / Electron 44.9.3. Synthetic transcript only.

Logs or stack traces

Timing probes recorded performance.now() at retry exhaustion, first list availability, and successful listener attachment. Measurements and full reproduction procedure include the raw trace.

Screenshots, recordings, or supporting files

• Baseline recording: upward navigation followed by snap to end
• Diagnostic control recording: position retained

The reproduced input was on ordinary main-timeline text, not in an HTML frame. This measured snap occurred on an idle transcript after resizing. I have not directly reproduced the active tool-start/finish trigger or a physical mouse-wheel gesture. T3's preview_scroll uses scrollBy, so its results were not counted as wheel evidence. A separate healthy-load streaming trial retained its chosen position.

Workaround

No end-user workaround verified for the delayed-load case. All probes, artificial latency, and the diagnostic retry change were removed afterward; no T3 fix or PR was created.