›_ Claude Code Issues
Claude Code Issues / #41965

v2.1.89 regression: flicker-free rendering destroys terminal scrollback by default

Resolved 💬 17 comments Opened Apr 1, 2026 by sstraus Closed Apr 17, 2026
💡 Likely answer: A maintainer (claude[bot], contributor) responded on this thread — see the highlighted reply below.

v2.1.89 regression: flicker-free rendering destroys terminal scrollback

v2.1.89 introduced "flicker-free alt-screen rendering with virtualized scrollback" (CLAUDE_CODE_NO_FLICKER=1), but this behavior appears to be enabled by default, causing terminal scrollback to be destroyed after ~2 pages of output.

Observed behavior

When Claude Code output exceeds the visible terminal height (~24 rows), the terminal is fully re-rendered — the startup banner and conversation are reprinted from scratch. This destroys existing scrollback content. The startup mascot/banner remains visible at the top because it's re-rendered each time, but intermediate content is lost.

Evidence

I ran identical tests across three configurations using PTY sessions (24 rows × 120 cols):

Test: Two consecutive prompts — "print numbers 1-100" then "print alphabet A-Z"

| Configuration | Result |
|---|---|
| v2.1.87 | Single banner, linear output: header → 1-100 → A-Z. Scrollback preserved. |
| v2.1.89 (default) | Banner appears 3 times in output. CC re-renders the entire conversation when content exceeds screen height. Scrollback destroyed on each re-render. |
| v2.1.89 + CLAUDE_CODE_NO_FLICKER=0 | Same as v2.1.87 — single banner, linear output, scrollback preserved. |

v2.1.89 default output (truncated for clarity)

▐▛███▜▌   Claude Code v2.1.89        ← 1st render
  11
  ...
  85
▐▛███▜▌   Claude Code v2.1.89        ← 2nd render (re-render, scrollback destroyed)
❯ print the numbers from 1 to 100...
  1
  ...
  83
▐▛███▜▌   Claude Code v2.1.89        ← 3rd render (re-render again)
  1
  ...
  100
❯ now print the alphabet...
  1. A
  ...
  26. Z

Reproduction

  1. Install Claude Code v2.1.89
  2. Open any terminal (iTerm2, xterm.js, etc.)
  3. Start a session and ask for output longer than the terminal height
  4. Scroll up — only ~2 pages of content are available

Workaround: Set CLAUDE_CODE_NO_FLICKER=0 in environment or Claude Code settings.

Environment

  • macOS (Darwin 25.4.0, arm64)
  • Claude Code v2.1.89
  • Tested in: iTerm2, xterm.js (via Tauri WebView)
  • Both terminals exhibit the same behavior

View original on GitHub ↗

17 Comments

seanmartinsmith · 3 months ago

can confirm CLAUDE_CODE_NO_FLICKER=0 does not fix this on windows 11 + windows terminal + bash. set it in ~/.claude/settings.json env block, restarted session, transcript still disappears mid-conversation at low context usage (~11%).

env:

  • claude code 2.1.89
  • windows 11 home (10.0.26200)
  • windows terminal
  • bash shell
  • opus 4.6 (1M context)

downgrading to 2.1.87 restores normal behavior per other reports

xbzzoo · 3 months ago

https://t.me/+t_ed3b95DqczNmU1

MatthewLaw1 · 3 months ago

Confirming that CLAUDE_CODE_NO_FLICKER=0 works as a fix for MacOS. Destruction of terminal scrollback is inconsistent, as usually it will preserve the entry prompt banner: "welcome back <user>" but will begin evicting old lines of conversation data only.

Claude Code v2.1.89
Terminal.app zsh
MacOS 26.4 (25E246)

vicenzomasat · 3 months ago

Workaround working for me, just like in 2.1.87.

My problem:
What Should Happen?
It should show the conversation as normal.

Error Messages/Logs
Steps to Reproduce

  1. Start conversation
  2. Make a plan
  3. All previous context gone, he remembered, but the text wasn't there, just the new plan

Claude Model
Opus

Is this a regression?
Yes, this worked in a previous version

Last Working Version
2.1.87

Claude Code Version
2.1.89

Platform
Anthropic Max Account

Operating System
Ubuntu 24.04/Debian Linux

Terminal/Shell
Ghostty

ocombe · 3 months ago

Another issue from CLAUDE_CODE_NO_FLICKER is that shift+enter don't work anymore when it's set to 1, setting to 0 resolves the issue (shift + enter doesn't submit and creates a new line)

aa-dragosmocrii · 3 months ago

Can confirm. After 2.1.87, the messages would disappear randomly in the middle of a conversation. There is no way to scroll up to see past messages. It can happen multiple times in the same session.

nikhilsitaram · 3 months ago

Still an issue and very annoying.

undenuicap · 3 months ago

CLAUDE_CODE_NO_FLICKER=0 does NOT work for me in version 2.1.90.
This must be properly fixed !

pattobrien · 3 months ago

confirming CLAUDE_CODE_NO_FLICKER=0 worked for me in v2.1.91.

maksvet · 3 months ago

What happens:

After upgrading to v2.1.89+, terminal conversation history disappears mid-session. You can no longer scroll up to see earlier messages, tool outputs, or plan discussions. It's not context compaction — the text is visually gone from the terminal, even though Claude still remembers it.

This can happen multiple times in a single session. Sometimes the welcome banner survives but all conversation content above the latest response is wiped. There's no warning or indication it's about to happen.

Confirmed on:

  • Linux — GNOME Terminal, Ubuntu

CLAUDE_CODE_NO_FLICKER=0 is suggested as a workaround but is unreliable — confirmed broken on v2.1.90. Downgrading to v2.1.87 is the only consistent fix.

Why it matters:

Long sessions with plans, multi-step implementations, and debugging require scrolling back to reference earlier output. Losing that history mid-session forces you to re-ask questions or rely on memory. This is the single most disruptive regression since flicker-free rendering was introduced.

Related issues: #2479, #42076, #27242

dmeehl · 3 months ago

Confirmed on:

Linux - OpenSUSE Tumbleweed, KDE Plasma 6.5.5, Yakuake terminal

Downgrading to v2.1.87 is the only consistent fix for me too.

parsakhaz · 3 months ago
this is a huge issue. love claude code but this makes it really really hard to use

hey. it's fixed at the terminal level here

https://github.com/Dcouple-Inc/Pane/pull/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.

Not just a scrolling issue — also a rendering/layout problem in VS Code's side-by-side panel mode. When Claude Code runs in VS Code with the terminal on one side and the editor on the other, text formatting breaks in unpredictable ways. Options and multi-line output get weirdly split left-right, text wraps incorrectly, and the whole experience feels janky rather than fluid. Combined with the scroll-jumping, longer sessions in VS Code become genuinely hard to follow. This isn't just macOS standalone terminal — it's very much a VS Code integrated terminal issue too.

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

https://github.com/Dcouple-Inc/Pane/pull/120

dmeehl · 3 months ago

@parsakhaz This issue is not about "scroll jumps". It's about scrollback. With claude code >2.1.87 there basically is no scrollback (only 1-2 pages of scrollback exists at any time). Prior to v2.1.88, I can scroll back through ~17 pages (screens). One or two pages of scrollback is not enough to work with claude code, the system is unusable.

parsakhaz · 3 months ago
@parsakhaz This issue is not about "scroll jumps". It's about scrollback. With claude code >2.1.87 there basically is no scrollback (only 1-2 pages of scrollback exists at any time). Prior to v2.1.88, I can scroll back through ~17 pages (screens). One or two pages of scrollback is not enough to work with claude code, the system is unusable.

Isn't that the new "no flicker mode" that's configurabl? I'm on the newest version on windows with WSL and i have full scrollback + no scroll jumps. Maybe I misunderstood

Nvm, I'm on .87- sorry

claude[bot] contributor · 3 months ago

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

dmeehl · 2 months ago

Confirmed fix via v2.1.114

github-actions[bot] · 2 months ago

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.