Chat transcript stops following after large tool output #6096

Prerequisites

• I searched open and closed issues, open pull requests, and discussions for chat auto-scroll, large tool output, file commands, post-tool activity, and transcript/composer alignment. Bug Report: Chat does not auto-scroll on message send #5611 covers scrolling after a sent user bubble is inserted; closed PR fix(ui): Auto scroll not consistent #5972 also explored large tool-output following, but no open child issue owns the broader current-dev transcript-growth contract.
• This is not a security vulnerability. It is a frontend interaction bug.
• I reproduced the controlling source paths on current dev at 032967af and exercised the failure boundary with a deterministic frame-clock regression harness.

Odysseus Revision

032967a (2026-08-17)

Install Method

Manual Python install (pip / venv)

Operating System

Linux

Steps to Reproduce

1. Open an Agent chat with enough transcript content to make #chat-history scrollable and remain at the bottom.
2. Ask the agent to create or inspect files so a tool card or command result expands the transcript by more than 300 px.
3. Let the tool complete and the next assistant round begin without manually touching the scrollbar.
4. Observe that the viewport can remain on the completed command while the continuation/activity node is appended below it.
5. At a desktop width, compare the centered transcript content track with the 800 px composer track.

Expected Behaviour

While auto-follow is enabled, the transcript should keep tracking the current bottom even when a tool card grows substantially or later content arrives during an existing animation. Tool completion should immediately leave a normal assistant activity indicator above the composer, the scroll-bottom control should follow later height growth, and the transcript/composer tracks should align. Manually scrolling up must still opt out.

Actual Behaviour

The shared smooth scroller drops requests for 500 ms and aborts whenever the distance to the current bottom exceeds 300 px. Programmatic animation frames can also make the shared scroll listener disable auto-follow before reaching the bottom. After tool_output, the next activity node waits on a fixed 400 ms timer, so a finished command can remain the last visible element. The transcript also adds an extra 12 px of right padding beyond its centered left track.

Logs / Screenshots

Current dev source boundaries:
- static/js/ui.js: scroll calls are throttled for 500 ms
- static/js/ui.js: _smoothScrollStep returns when diff > 300
- static/app.js: every scroll event rewrites auto-scroll state
- static/js/chat.js: tool completion schedules the next activity state after 400 ms
- static/style.css: history right padding adds 12 px beyond the centered track

Closed PR #5972 contains a prior running-app clip of the large-tool-output symptom and expected pinned behavior: https://github.com/user-attachments/assets/1392c952-e173-4371-8033-0a970e76c180

Model / Backend (if relevant)

Any agent-capable backend that produces tool or file-operation output.

Are you willing to submit a fix?

Yes — I can open a focused PR.

Additional Information

Parent tracker: #6094.

A focused candidate should use one shared transcript-following controller, recalculate the live bottom while content grows, cancel only on real user opt-out, and keep new browser modules in the PWA app-shell cache. Focused controller and chat regressions should accompany running-app desktop/mobile evidence. This issue is related to #5611 but does not replace its sent-user-bubble timing acceptance criterion.