Repository navigation
[Bug] Scroll position jumps when Claude streams output during upward scrolling #33367
Closed as duplicate
Description
Bug Description
you've introduce a bug with scrolling jitter when scrolling up through conversation history. while Claude is displaying new results, if I scroll up now my scroll position jumps around and I often get put to the top of the scroll buffer so I can never even read the recent output from Claude Code that has scrolled past the current screen
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.73
- Feedback ID: 30867ea8-0488-42c1-8e25-f9681c2cabe9
Reacted by Raj Siva-Rajah, Dallas Hall, rssprivacy-commits, Ian Stokes-Rees, brasil-pi, Abiud Cantu, David Hong, Jake Gordon, biofermin, Piefayth and 51 more
Activity
github-actions commentedon Mar 11, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
binaryfire commentedon Mar 12, 2026
Same. This bug was fixed, and now it's back.
ijstokes commentedon Mar 13, 2026
Oh this is so painful. Yes, it worked fine until at least 2.1.71 (earlier this week), and then somewhere between there and 2.1.74 if I've scrolled up even just a little to look at some output or comments and new output is produced "lower down" then my viewport jumps TO THE VERY BEGINNING. My Claude Code sessions go on for days. There are 10s of THOUSANDS of lines I then need to scroll back down through to get to the "right now", and in fact I don't even want to be at the "right now", I need to be reading the output from the current agent session which might be taking 3-5-10 minutes to complete, but I want to track and see what is happening so I can think about it, form next step questions, and exceptionally, if needed, stop it from proceeding. But can I do any of that right now? So far as I can tell: no. I have to scroll up quickly, get a glimpse of what is there on the screen from output I need to grok from the last few minutes (and sometimes for reference from earlier finished interactions & agent actions), before more output is produced which will kick me to the top of the terminal session. Ugh. Please fix. I can't believe more people haven't found this issue to upvote it.
jakeg commentedon Mar 13, 2026
This is really annoying and makes it impossible to read what Claude just said as I have to try to hold the scroll bar in a particular position then it jumps to somewhere else.
Unlike the op, I'm on Windows in PowerShell.
VoxCore84 commentedon Mar 14, 2026
We hit this too and collected working workarounds into a repo: claude-code-scroll-fix
Quick fix (Windows Terminal): Add
"snapOnOutput": falseto yourprofiles.defaultsinsettings.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.
snapOnOutputonly fixes output-triggered scrolling, not cursor repositioning — tmux fixes both.jaywonchung commentedon Mar 14, 2026
Getting this on Claude Code 2.1.76, MacOS 26.3, and Ghostty 1.3.0 as well.
FurbySoup commentedon Mar 15, 2026
This is the same root cause as #826 — Claude Code's full screen redraws reset scroll position.
https://github.com/FurbySoup/quell is a Windows proxy that fixes this by stripping the clear-screen from redraw sync blocks. quell claude and it just works.
Crazytieguy commentedon Mar 16, 2026
Hands down the most annoying bug in claude code history imo
ttibbetts commentedon Mar 17, 2026
Confirming the same behavior on Windows Terminal + PowerShell. When scrolled up to review conversation history while Claude is actively streaming a response, the viewport jumps to the very top of the session. This feels like a recent regression - I wasn't experiencing it consistently before.
Claude Code version: 2.1.76
OS: Windows 11 on ARM
Terminal: Windows Terminal + PowerShell
Noting that the same core symptom has been reported on Windows previously (#1486, #22988, #24790) but those were all bot-closed.
gamenerds commentedon Mar 17, 2026
guys I will lose my mind if you don't prioritize fixing this. THIS AFFECTS EVERYONE!!! Who gives a fk about your thinking indicator if it's causing this issue (assuming you can't have both the fix and thinking indicator). Dev QOL > everything.
synergy49 commentedon Mar 17, 2026
Confirming the same behavior on Windows Terminal + PowerShell.; IT IS SUPER ANNOYING.
synergy49 commentedon Mar 17, 2026
FIX THISSSSSS!!!!!!
15 remaining items
ethanyzhang commentedon Mar 24, 2026
It’s hard to believe this issue is stuck here for this long… don’t they use Claude code themselves and not experiencing the same annoying issue?
nullbio commentedon Mar 24, 2026
They probably don't read the code or the output. Explains the quality control.
synergy49 commentedon Mar 24, 2026
Definitely is a deal breaker, awful experience.
sstraus commentedon Mar 24, 2026
👍 We're experiencing the same issue embedding xterm.js 6.0.0 in a Tauri app. The scroll position jumps when Claude Code redraws its TUI while the user is scrolled up. Confirmed root cause: cursor-up sequences exceeding viewport height + ESC[2J/ESC[3J.
haikalpribadi commentedon Mar 25, 2026
I'm loosing my mind cause of this bug.
VoxCore84 commentedon Apr 1, 2026
Consolidated root-cause analysis across all 4 scrolling issues (#33367, #33814, #10835, #34242) plus related reports (#34400, #34052):
The root cause has been independently identified by multiple users. Credit to @doitallwrong (on #33814) for the most precise technical analysis:
Three specific functions in
cli.jsemit cursor-up ANSI sequences (\x1b[nA) wherenequals the previous render height — which can be hundreds or thousands of lines. Terminals follow the cursor to the new position (above the visible viewport), causing the viewport to jump to the top.HF7()— Ink renderer cleareraseLines— prompt rendererNone of these clamp
nto the viewport height. @doitallwrong provided a 3-linesedpatch that fixes the issue at the source by clamping the cursor-up sequences.An aggravating factor on Windows: microsoft/terminal#14774 causes
SetConsoleCursorPositionto scroll the viewport even inside synchronized update blocks.Workaround effectiveness ranking (from our testing + community reports):
sedpatch on cli.js (@doitallwrong)snapOnOutput: falsein Windows Terminalclaude-chillRust PTY proxyCurrent status:
The fix is known and small (clamp cursor-up to viewport height). The impact is massive (this is the most-reported UX bug in the repo by combined upvotes). The
sedpatch proves it's a ~3 line change.sstraus commentedon Apr 2, 2026
We've been fighting this exact issue in TUICommander (a terminal orchestrator for AI coding agents built on xterm.js) for about two weeks. Here's a summary of what we tried:
Failed approaches
Current mitigation (~85-90%)
New: cursor-up clamping (your approach)
Based on @doitallwrong's analysis, we've now added ESC[nA / ESC[nF clamping in the PTY data path before it reaches xterm.js. Each session tracks its viewport rows (updated on resize). Before emitting PTY output,
ESC[nAandESC[nFare clamped tomin(n, viewport_rows).This is a different approach from what we tried before — we previously targeted ESC[2J/3J (clear commands), not the cursor movement sequences themselves. Combined with the viewport lock (approaches 5-7) as defense-in-depth.
This will ship in TUICommander v0.9.9 nightly. We'll report back with results after testing with Claude Code, Codex, and Aider sessions.
The upstream fix (clamping in
cli.js) would still be the right long-term solution — terminal emulators shouldn't need to compensate for this.FurbySoup commentedon Apr 6, 2026
@VoxCore84's breakdown is the best root cause analysis I've seen on this — the three-sequence identification matches exactly what I found building a fix for this. Wanted to share where that ended up and genuinely curious whether it helps people's specific setups.
Quell is a Windows terminal built specifically for Claude Code. It intercepts VT output via ConPTY and strips the sequences responsible for the scroll-jumping before they ever reach the renderer.
What it fixes (as of v0.2.1):
All three root causes now handled:
ESC[3J— erase scrollback — stripped unconditionallyESC[2J— erase display — stripped outside DEC 2026 synchronized update blocks (allowed inside, where it's part of an atomic redraw)ESC[nA— cursor-up — stripped outside sync blocks (v0.2.1, shipped two days ago)The sync-block awareness matters for the latter two: Ink wraps its redraws in BSU/ESU markers, so we can distinguish "this is a legitimate UI repaint" from "this is orphaned cursor movement that will snap the viewport." The sed patch approach strips cursor-up unconditionally — which works, but also strips legitimate cursor movement. Our approach is more surgical.
Two ways to use it:
GUI (recommended — eliminates the problem entirely): A standalone terminal app — download the installer. Because we own the renderer (xterm.js), the cursor-up issue has nowhere to propagate to. This is the cleanest fix.
CLI proxy: For people who want to stay in their current terminal —
quell claudewraps Claude Code in the filter layer. Handles ESC[3J and ESC[2J completely. Cursor-up handling helps significantly, though in very long sessions you may still see minor drift from microsoft/terminal#14774 — that's an upstream terminal behaviour we can mitigate but not fully control from a proxy position.What I'd genuinely like to know:
Does this actually solve it for people's real sessions? The cases I'm most uncertain about are very long sessions (1000+ line scrollback) and heavy tool-use sequences where Ink redraws rapidly. If anyone tries it and finds cases where the jumping still occurs, I'd like to understand exactly what's happening — logs, repro steps, whatever's useful.
Also — now that Claude Code is 'open source', I'm looking at whether proposing that Ink adopt sync markers more consistently is viable. That would make the proxy approach essentially lossless for both CLI and GUI users. If anyone's interested in that angle, happy to discuss.
Windows only for now (ConPTY is the core of the fix). MIT licensed, no telemetry.
GuanglinDu commentedon Apr 8, 2026
@haikalpribadi , please try Qell as a workaround to solve this problem if you're on Windows. I succeeded this way on Windows 10 with PowerShell PSVersion 5.1.19041.3031.
parsakhaz commentedon Apr 10, 2026
hey. it's fixed at the terminal level here
greenfield-inc/Pane#120
open source, using xtermjs which is the same terminal as VS Code. feel free to copy this fix or download the latest release to run claude code on any operating system with the fix in place. i was so mad and frustrated at this that I had to fix it myself.
yeah i had to switch off cursor/vscode and build myself an ide that managed xtermjs (the library they both use) well enough for the complex TUIs to not break.
works great and i have a fix for the scroll jump i just implemented rn here
greenfield-inc/Pane#120
parsakhaz commentedon Apr 10, 2026
because its terminal level fix, it works with git bash, powershell, cmd, macs terminals on Pane. FYI.
claude commentedon Apr 26, 2026
This is a duplicate of #35403, which was fixed as of version 2.1.101.
github-actions commentedon May 7, 2026
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.