[Bug]: Chat does not auto-scroll to most recent message

[samanthamsong]

Description

When new messages arrive in chat, the view does not automatically scroll to the most recent message. The user has to manually scroll down to see new responses, which is disruptive during active conversations.

Expected Behavior

The chat view should auto-scroll to the bottom when:

• A new assistant message arrives or streams in
• The user sends a message
• The user is already at or near the bottom of the conversation

If the user has scrolled up to read earlier messages, auto-scroll should be suppressed (standard chat UX pattern). A "scroll to bottom" button should appear when new messages arrive while scrolled up.

Actual Behavior

Chat stays at the current scroll position when new messages arrive. The user must manually scroll down every time to see the latest response.

Impact

This is a core chat UX expectation. Every major chat app (Teams, Slack, iMessage, ChatGPT) auto-scrolls on new messages. Missing this makes the app feel broken during normal use.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 11, 2026, 1:11 AM ET / 05:11 UTC.

Summary
Keep open for explicit collaborator review. Current v2026.7.1 source and UI proof tests implement and exercise the central auto-follow behavior, but the report needs a native runtime confirmation and its requested return-to-bottom control is not present in the reviewed timeline UI.

Reproducibility: no. Current source and focused WinUI tests cover the stated follow and scroll-up behaviors, but no current native runtime reproduction accompanies this collaborator report.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Can the report be reproduced in the current native v2026.7.1 chat flow, including an incoming streamed response while the view is near the bottom?	Confirm native behavior first: Run the reported send, stream, and scroll-up scenarios on v2026.7.1 before deciding whether a code fix is needed.

Why: Current source and focused WinUI tests cover auto-follow and reader-position preservation, while the collaborator report asserts an observed mismatch that cannot be resolved from source alone.

Next step
A collaborator-authored report stays open for maintainer confirmation because current source and focused UI tests already cover the central behavior, while the requested button needs separate scope judgment.

Review details

Best possible solution:

Verify the reported flow on v2026.7.1 first; retain the existing follow behavior if it works, and separately approve and implement an accessible return-to-bottom affordance only if that added UX is desired.

Do we have a high-confidence way to reproduce the issue?

No. Current source and focused WinUI tests cover the stated follow and scroll-up behaviors, but no current native runtime reproduction accompanies this collaborator report.

Is this the best way to solve the issue?

Unclear. The central behavior is already implemented and tested, so native confirmation should precede a repair; the requested return-to-bottom button is additional UX scope.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The current UI has no identified return-to-bottom control, so expanding this bug report to include that affordance changes it into a user-facing UX scope decision.
• Source and existing UI proof contradict the reported central failure, but this read-only review did not run the native tray against the reporter’s scenario.

Codex review notes: model internal, reasoning high; reviewed against 4206611f2b2e.

Label changes

Label changes:

• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The report describes a disruptive but non-blocking chat usability problem with no verified current-runtime regression yet.
• impact:ux-friction: Missing visibility of new chat responses would force users to repeatedly manually scroll during conversations.

Evidence reviewed

What I checked:

• Incoming-message follow implementation: The timeline queues a scroll to the true bottom when entries are appended while the view is following the latest message. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:2853, 4206611f2b2e)
• Sent-message follow implementation: Sending a chat message increments the timeline scroll token, which the timeline consumes as an explicit scroll-to-bottom request. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs:813, 4206611f2b2e)
• Current UI proof coverage: The WinUI proof test appends a row and asserts the scroll view is at the newest row; a companion test asserts streaming does not move a reader who has scrolled up. (tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs:143, 4206611f2b2e)
• Regression contract: The shared tray contract test guards bottom anchoring, bounded settling, and user-scroll preservation in the production timeline. (tests/OpenClaw.Tray.Tests/ChatTimelineVirtualizationContractTests.cs:23, 4206611f2b2e)
• Current release provenance: The reviewed current-main SHA is the latest release tag v2026.7.1; the local source history is shallow and attributes these files to that snapshot commit. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:77, 4206611f2b2e)

Likely related people:

• Scott Hanselman: The available current-main blame and single retained history snapshot attribute the central timeline and root files to this commit; deeper feature provenance is unavailable locally. (role: current-main source provenance; confidence: low; commits: 4206611f2b2e; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.