[BUG] "terminal scrolling infinite loop" or "uninterruptible high speed scrolling bug"

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/8983
2. https://github.com/anthropics/claude-code/issues/8312
3. https://github.com/anthropics/claude-code/issues/10619

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

👎

Yeah this issue is literally driving me insane lmao

Anthropic engineers, get this on your roadmap ASAP! Literally causing 50x + crashes daily! There's already multiple of these open, when will you fix??

sorunu çözdüm powershell sürümünü en sone getirin windowsta sorun çözülüyor malesef windows powershell default olarak 2016 dan kalma güncelledim 3 . gündeyim sorun ortadan kalktı !

this issue is there for months already.

this issue is there for months already.

Yeah and no indication that the team is picking this up. There are many duplicates of the same issue, no team reaction.

This bug has a regression with the built-in Simple Browser of the VSCode as well. When the infinite scrolling loop hits off, it will open the Simple Browser and continuously steal the focus of the TUI, when there are localhost URLs in the TUI output.

I'd really like a solution or even just a workaround for this. running on remote linux term on local window cmd is the same. it happens a lot when i use mcp that prints a lot of text.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Yes it is still occurring.

This might be a duplicate of #769. The OP reported (in Turkish) that they solved their problem by upgrading PowerShell, so in that sense this bug appears to be closable.

This is a bug that I experience also on linux/putty.

This happens on MAC, Windows, and Linux terminals.

Note that I had Claude Code make me another REPL for something else. Guess what. The REPL also has the same scrolling problem. The REPL library used was Ink in nodejs. So maybe a bug of the REPL framework that Claude Code uses?

This is a joke, right?
How is it that an issue that is plaguing every user on all platforms is not at the top of your priority list?
We are paying a good sum every month to use this tool, and yet the experience is complete garbage.
Random scroll to the top, infinite repaint and reposition make work really hard.
There are close to at least half a dozen open issues around the same bug.
Apologies for tagging some contributors, but I think the community needs some assurance that there is a fix or a new tool on the horizon.
@bcherny @ashwin-ant @claude

thats the reason we want to use open code

Yup, it seems it's the REPL framework Ink. Here's some comments posted by the Windows Terminal team about this issue.

https://github.com/microsoft/terminal/issues/19772

Fix this shit pls... its super annoying, latest version

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.

+1 — experiencing this on GNOME Terminal (same behavior as IntelliJ terminal). Cursor randomly scrolls up during streaming output.

Dang, this still isn't fixed, can we get this fixed? It is super annoying. Happens in WSL CLI (Linux Ubuntu) as well.

with the native installation of claude code and Windows Terminal with git bash (no WSL), it seems to be fixed. Just fyi in case that's helpful in troubleshooting what's the exact cause.

claude devs, just ask claude to fix this bug lmao
cannot be this hard, can it?

This thing is broken on MacOS native, in VSCode integrated Terminal and on Ubuntu...
200USD/month product... There are related Bug reports open for 3/4 of a year now... Zero maintainer attention
How is this not highest priority?

Additional data point: source-level root cause analysis + confirmed workaround

Environment: macOS (Darwin 25.4.0, arm64), tmux 3.6a, Claude Code v2.1.104, TERM=tmux-256color, mouse=on, alternate-screen=on, minimal ~/.tmux.conf

Root cause (source analysis)

Traced through the bundled Ink renderer in Claude Code. The scroll loop / content duplication is caused by render_v1's full-redraw path:

1. Tg0(prevFrame, currFrame) returns true whenever outputHeight >= terminalRows — which is virtually always in a non-trivial session.
2. This triggers getRenderOpsForAllOutput_CAUSES_FLICKER() (yes, the function is named that way) every render cycle (~32ms throttle).
3. That function emits:

• \x1B[2J (erase screen) + \x1B[3J (erase scrollback buffer) + \x1B[H (cursor home)
• Then re-outputs fullStaticOutput + current output from scratch.

1. The continuous scrollback-erase → rewrite cycle (every 32ms) conflicts with the terminal's scroll position tracking, causing the "infinite loop" / "content repeating at top" behavior.

Confirmed workaround

CLAUDE_CODE_NO_FLICKER=1 completely resolves the scroll duplication issue in my environment.

export CLAUDE_CODE_NO_FLICKER=1

This appears to bypass the render_v1 full-redraw path. render_v2 (ink2 mode) uses cell-level diffing and only calls clearTerminal on viewport resize, which avoids the problem.

Note

The \x1B[3J scrollback erase is the key offender — without it, terminals can maintain scroll position even through screen clears. Consider gating the [3J emission or making the ink2 renderer the default path.

Proposed fixes: two root-cause mechanisms behind scroll duplication

Building on the source-level analysis above, here are two concrete, actionable code changes that would resolve the scroll duplication for all users. These two mechanisms collectively explain at least 12 related issues (#769, #8312, #8983, #10619, #46834, and others).

---

Mechanism A — render_v1 full-redraw loop (32ms cycle)

What happens: Tg0(prevFrame, currFrame) returns true whenever outputHeight >= terminalRows, which is nearly always. This triggers getRenderOpsForAllOutput_CAUSES_FLICKER() every ~32ms, which emits \x1B[2J + \x1B[3J + \x1B[H and re-outputs the entire frame. The \x1B[3J (erase scrollback) is the key offender — it destroys the terminal's scroll position tracking, causing the "infinite scroll loop" behavior.

Proposed fix — make render_v2 (ink2) the default:

- const useInk2 = process.env.CLAUDE_CODE_NO_FLICKER === "1";
+ const useInk2 = process.env.CLAUDE_CODE_LEGACY_RENDER !== "1";

render_v2 uses cell-level diffing and only calls clearTerminal on viewport resize, which completely avoids the 32ms full-redraw cycle. This is already production-tested via CLAUDE_CODE_NO_FLICKER=1 and confirmed working across macOS, Linux, and Windows Terminal.

render_v1 would remain accessible via CLAUDE_CODE_LEGACY_RENDER=1 for any edge cases, but the default path would no longer destroy scrollback.

---

Mechanism B — SIGWINCH / relayout causes duplicate copies in scrollback

What happens: On terminal resize (SIGWINCH) or certain UI transitions (e.g. Shift+Tab), Ink/Yoga triggers a full relayout. The current code writes the re-rendered output to stdout, which appends to the primary scrollback buffer. Each resize event produces another full copy of the conversation history in scrollback. N resizes = N duplicate copies.

This is orthogonal to Mechanism A — it occurs even with CLAUDE_CODE_NO_FLICKER=1 / render_v2.

Proposed fix — constrain relayout to the alternate screen buffer:

On SIGWINCH, instead of writing the full re-rendered frame to stdout (which appends to scrollback), the relayout should:

1. Call resetFramesForAltScreen() to clear the alt-screen frame state
2. Perform repaint() within the alternate screen buffer only
3. Avoid any writes that escape to the primary scrollback

Conceptually:

// On SIGWINCH handler:
process.stdout.on('resize', () => {
  // Reset internal frame tracking for alt-screen
  resetFramesForAltScreen();
  // Repaint within alt-screen only — no scrollback side-effects
  repaint();
  // Do NOT re-output fullStaticOutput to stdout
});

The key invariant is: relayout must never write content to the primary scrollback buffer. All re-rendering should be confined to the alternate screen (\x1B[?1049h … \x1B[?1049l), which terminals treat as a separate, non-scrollable surface.

---

Impact

These two fixes would resolve the scroll duplication issue across all platforms and terminal emulators. The scope of impact is significant — this thread alone has reports from macOS, Linux, Windows Terminal, WSL, VSCode integrated terminal, IntelliJ terminal, GNOME Terminal, and PuTTY.

Related issues that would be resolved or significantly improved:

• #769 (flickering during streaming — Mechanism A)
• #8312, #8983, #10619 (scroll duplication — Mechanism A)
• #46834 (SIGWINCH duplicate copies — Mechanism B)
• Multiple unlisted duplicates referenced throughout these threads

Fix 1 (default to render_v2) is a one-line change with an existing escape hatch. Fix 2 (SIGWINCH relayout containment) is more involved but addresses the remaining cases that render_v2 alone doesn't cover.