Skip to content

[BUG] SCROLL INTO-TOP ALWAYS ON CLAUDE-CODE CLI #34052

Closed as duplicate
Closed as duplicate

Description

@brasil-pi

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?

I do want to read live-preview of claude code answer-typing at linux-ubuntu, it keeps the terminal on top, i scroll bottom, it pushies to top. lol.

What Should Happen?

Terminal should always be on bottom (so i can read preview content as it is doing).

Error Messages/Logs

Steps to Reproduce

1- Open claude code.
2- Type wherever thing.
3- Scroll goes then to top instead of keeping at bottom.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Version: 2.1.74

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

Activity

  1. github-actions commented on Mar 13, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. [BUG] Forces scroll to top when outputting code (NOT just when scrolling) #33814
    2. [BUG] Console scrolling top of history when claude add text to the console #826
    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

  2. VoxCore84 commented on Mar 14, 2026

    @VoxCore84

    We hit this too and collected working workarounds into a repo: claude-code-scroll-fix

    Quick fix (Windows Terminal): Add "snapOnOutput": false to your profiles.defaults in settings.json. Reduces jumping ~60-70%.

    Complete fix: Run Claude inside tmux — it completely decouples your scroll position from Claude's cursor repositioning. The repo has a one-click installer that sets up WSL + tmux + a Windows Terminal profile.

    Root cause: Claude Code uses CSI escape sequences to rewrite the thinking spinner in-place, and terminals follow the cursor position back up. snapOnOutput only fixes output-triggered scrolling, not cursor repositioning — tmux fixes both.

  3. cruzlauroiii commented on Mar 16, 2026

    @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.

  4. cruzlauroiii commented on Mar 16, 2026

    @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.

  5. cruzlauroiii commented on Mar 16, 2026

    @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.

  6. cruzlauroiii commented on Mar 16, 2026

    @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).

  7. cruzlauroiii commented on Mar 16, 2026

    @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.

  8. cruzlauroiii commented on Mar 16, 2026

    @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.

  9. cruzlauroiii commented on Mar 16, 2026

    @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.

  10. cruzlauroiii commented on Mar 16, 2026

    @cruzlauroiii

    Final fix: Ctrl+6 freeze toggle. Press Ctrl+6 to freeze screen (buffer renders, scroll freely). Press again to unfreeze (replay + live output). Tab title shows [FROZEN]. Root cause is WT bug microsoft/terminal#14774 — cannot be detected/fixed automatically. PR #34798.

  11. self-assigned this
    on Mar 19, 2026
  12. claude commented on Apr 26, 2026

    @claude
    Contributor

    This is a duplicate of #35403, which was fixed as of version 2.1.101.

  13. github-actions commented on May 7, 2026

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  14. locked as resolved and limited conversation to collaborators on May 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:tuibugSomething isn't workingplatform:linuxIssue specifically occurs on Linux

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions