[BUG] Desktop app: chat window auto-scrolls to bottom during streaming even when user has scrolled up

[mvgx]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

This affects the Claude Code Desktop app on Windows (not the CLI / terminal version).

While Claude is streaming a response (token-by-token / phrase-by-phrase), the
chat window force-scrolls to the bottom on every update. This happens even when
I have explicitly scrolled up to read earlier content — including scrolling all
the way to the top of the conversation. The viewport is yanked back down on
every new chunk, making it impossible to read previous messages while a
response is being generated.

This started in recent versions; older builds of the desktop app did not behave
this way.

What Should Happen?

Standard "sticky bottom" behavior used in terminals, chat apps and IDE chat
panels:

• If the user is at the bottom of the scroll
  container, auto-scroll to follow new streaming content.
• If the user has scrolled up beyond that threshold, do NOT auto-scroll. Leave
  the viewport exactly where the user put it.
• Optional: show a "jump to bottom" button / new-message indicator so the user
  can opt back in with a single click.

This is the same UX that was already shipped for the VSCode extension via
issue #11092 ("Auto-scroll should pause when user scrolls up in chat",
closed completed on 2025-11-12). The desktop app appears to be missing that
fix (or has regressed it).

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code Desktop app on Windows.
2. Send a prompt that produces a long streamed response (e.g. ask for a
   detailed explanation, or run an agent task that emits a lot of streaming
   output).
3. While the response is still streaming, scroll up to read an earlier part
   of the conversation — even all the way to the top.
4. Observe: the viewport jumps back toward the bottom on every new chunk the
   model emits. There is no way to keep the viewport stationary until
   streaming finishes.

Expected: viewport stays where the user put it.
Actual: viewport is yanked down on every streaming update.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

app-1.3561.0

Claude Code Version

app-1.4758.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] Terminal auto-scrolls to bottom while Claude Code is working, preventing manual scroll #37627
2. [Feature Request] autoScrollEnabled should work in desktop app (non-fullscreen mode) #49183
3. [FEATURE] scroll lock / pause auto-scroll while Claude is streaming #38411

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[mvgx]

Not a duplicate of any of the three. Quick triage:

• [Bug] Terminal auto-scrolls to bottom while Claude Code is working, preventing manual scroll #37627 — area:tui, macOS terminal. Different surface (TUI, not desktop app).
• [FEATURE] scroll lock / pause auto-scroll while Claude is streaming #38411 — area:tui, terminal scroll-lock feature request. Different surface.
• [Feature Request] autoScrollEnabled should work in desktop app (non-fullscreen mode) #49183 — closest, but different trigger: that issue is about the viewport
  jumping when the user submits a message (despite autoScrollEnabled: false).
  This issue is about the viewport being yanked down while the assistant is
  streaming a response. Different code path, different trigger, different
  fix. Possibly related, but not a duplicate.

Please keep open — this is a desktop-app streaming-time autoscroll regression
between 1.3561.0 and 1.4758.0, not covered by the three issues above.

[LoicLac]

+1, can reproduce this on macOS as well, so this isn't Windows-specific — the platform:windows label should probably be extended to platform:macos too (likely all platforms).

Environment

• OS: macOS 15.7.3 (24G419)
• Claude Code Desktop version: 1.5354.0 (9a9e3d), built 2026-04-29 — i.e. newer than the version in the original report (app-1.4758.0), so the regression is still present in the latest builds.
• Last known working version: matches @mvgx's report (somewhere before app-1.4758.0).

Reproduction

Identical to the original report. Specifically:

1. Send any prompt that produces a long streamed response (detailed explanation, refactor over several files, anything that streams for more than a few seconds).
2. Start scrolling up to read earlier content while the response is still streaming.
3. The viewport is yanked back down on every chunk. There is no threshold detection — even being scrolled to the very top of the conversation does not pause the auto-scroll.

Impact on workflow

This breaks a core reading pattern: starting to read the response from the top while it continues generating below. On long responses (code reviews, multi-file diffs, agent traces), it is effectively impossible to read anything until streaming finishes, which can take minutes. Constant friction for any non-trivial task.

Why this should be cheap to fix

The exact same UX was already implemented for the VSCode extension via #11092 (opened 2025-11-06, closed completed 2025-11-12 — 6 days). The sticky-bottom logic + threshold detection already exists somewhere in the codebase; this looks more like a port / re-enable than a from-scratch implementation.

Suggested acceptance criteria

• If user is within ~50px of the bottom → follow stream (current behavior).
• If user has scrolled up beyond that threshold → freeze viewport, do not auto-scroll on new chunks.
• Show a "jump to bottom" pill / new-message indicator when the user is detached, clickable to re-attach.
• Re-attach automatically when the user manually scrolls back to the bottom.

Happy to test a nightly / canary build if one is available.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.