Scroll position resets to top of session while processing

[ilganeli]

Description

During active processing (while Claude is generating a response), the terminal scroll position resets to the top of the session. This forces the user to scroll back down to see the current output, disrupting the workflow.

Steps to Reproduce

1. Start a Claude Code session
2. Have a conversation with enough content that the session is scrollable
3. Scroll up to review earlier context while Claude is processing a response
4. Observe: scroll position jumps back to the top of the session

Expected Behavior

Scroll position should remain stable while Claude is processing. If auto-scroll is intended, it should scroll to the bottom (current output), not the top.

Actual Behavior

Scroll position resets to the top of the session during processing.

Environment

• Claude Code version: 2.1.76
• Terminal: iTerm2 3.6.6
• OS: macOS 26.0.1 (Tahoe, build 25A362)
• Shell: zsh
• Platform: darwin (Apple Silicon)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Console scrolling top of history when claude add text to the console #826
2. [Bug] Scroll position resets to top during agent execution #34400
3. [Bug] Scroll position jumps when Claude streams output during upward scrolling #33367

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

[cruzlauroiii]

Same issue on Windows Terminal + PowerShell. See #34794. At least 6 open issues report this across different platforms.

[cruzlauroiii]

Root cause traced in cli.js v2.1.76 source: Ink's rendering uses \ on every re-render. When output is large, the cursor moves far up in the buffer and Windows Terminal (and iTerm) follows the cursor, snapping the viewport to the top. Full analysis in #34794.

[cruzlauroiii]

Updated PR #34798 with v2 fix: stateful stdout.write interceptor that clamps cursor-up across ALL writes (not just sync blocks). Catches Ink renderer, prompt renderer, and all other cursor-up sources. Patch + PowerShell script included.

[cruzlauroiii]

Updated PR #34798 with 3 combined patches: (1) stateful stdout.write interceptor clamping cursor-up, (2) render throttle 16ms→200ms, (3) disable synchronized update mode. All three are needed — cursor-up clamping alone does not fix it because Windows Terminal exits scroll mode on ANY stdout write, and sync blocks batch writes into one viewport-resetting update. PowerShell apply/revert script included.

[cruzlauroiii]

v3 update: Previous fixes (cursor-up clamping, disabling sync update) did not work and caused flickering.

Root cause identified: Windows Terminal bug microsoft/terminal#14774 — SetConsoleCursorPosition always scrolls viewport to cursor, even when visible. Every Ink re-render triggers this. Cannot be fixed from within the process.

v3 patch: render throttle SK6=16 → SK6=1000 (1fps). Gives 1 second of uninterrupted reading between viewport resets. Trade-off: streaming text in ~1s chunks. No flickering.

PR #34798 updated. Real fix needs Microsoft (terminal#14774) or Anthropic (PTY proxy/append-only rendering).

[cruzlauroiii]

v5 update: Fundamentally different approach — buffer ALL Ink renders during active work, screen stays frozen (no viewport jumping). Flush only when (a) user types (at prompt/bottom, safe to update) or (b) 5s of no renders (Claude finished). Previous v1-v4 failed because WT bug microsoft/terminal#14774 triggers viewport scroll on ANY cursor positioning. v5 avoids this by not writing to stdout at all during active work. Trade-off: no spinner/progress visible during work. PR #34798 updated.

[cruzlauroiii]

v6: Buffer ALL renders, flush ONLY on user input (stdin). No timer. No auto-flush. Zero viewport jumping while not at bottom. Root cause: WT bug microsoft/terminal#14774. PR #34798.

[cruzlauroiii]

v7: Replay ALL buffered frames on flush (fixes v6 outdated screens). Keeps entire diff chain so screen content is always correct. Still zero viewport jumping — flush only on user input (stdin). PR #34798.